[nSLUG] Lamport on "software culture"

Chris R. Thompson chris.thompson at solutioninc.com
Mon Mar 24 08:37:41 ADT 2014


I think the problem here is much simpler than what is being purposed by many... It follows this line of thinking --> http://youtu.be/vKA4w2O61Xo
it's a problem within QA, within Dev, within software development, within the industry. Everyone should own this, not one group of people.... sure it shouldn't have happened, especially within apple, however when you take into account the business and managerial style of Mr. Jobs I'm not surprised that much was missed due to "process"... or lack thereof.

Christopher



On 14-03-23 10:37 PM, Oliver Doepner wrote:


	I agree, simplicity is hard, especially when adding features incrementally. But it is always very gratifying to strive for it and achieve it.
	
	
	I have developed a principle: When adding to or changing an existing codebase is very hard, then it must have a complexity surplus and I try hard to implement the enhancement through simplification. It doesn't always work and time constraints can make it impossible, but when it works it feels like christmas.
	
	
	Especially hard is code that matches the "Big ball of mud" [1] pattern and has been developed by several generations of "just tack on one more thing" developers who treat "copy, paste, obfuscate" as an engineering practice. :o)
	

	Cheers
	
	Oliver
	

	[1] http://laputan.org/mud/
	
	
	On Sun, Mar 23, 2014 at 2:07 PM, Robin Murray <nibor.yarrum at gmail.com> wrote:
	

		As an aside...

		I don't know if some academic has expressed this more eloquently elsewhere, but over the years I've noticed the same pattern with any software I write - it follows a bell curve of complexity. You start out with a fairly simple solution, thinking you have it all pretty much wrapped up in a nice neat bow, and then you start real honest testing, and throwing real world examples at it. At that point you become alarmed as you find that you didn't allow for edge cases, didn't fully understand a particular part, completely dropped the here and there. As you scramble to solve all these oversights, the complexity increases and your code starts to resemble spaghetti, and you begin to feel overwhelmed, and your confidence wanes. But, if you keep persevering, you suddenly begin to see the "real" solution buried in the spaghetti, and it starts to unravel - your routines become more robust and generic and renamed for better clarity, code gets relocated to proper areas etc. Soon after it begins to "just work". You have a clear understanding at that point of what the solution really is, and you feel confident that your code will no longer give you any major headaches. I've followed this pattern countless times. 

		I believe that many people are unaware of this pattern and fail to keep pushing through to the simplicity at the other end, assuming when they are caught up in the spaghetti, that it's spaghetti because it's a complex problem requiring a spaghetti solution. No no no! It's spaghetti because they've not continued to push through the fog to the simplification underneath it all. So code gets left in a unfinished state, a real mess for everyone to live with from there on out.







		--
		Robin Murray
		Hatchet Lake,
		Nova Scotia
		Canada


		On Sun, Mar 23, 2014 at 12:28 PM, Robin Murray <nibor.yarrum at gmail.com> wrote:
		

			I think this guy is living in an ivory tower. It's an art as to how much planning you do vs sitting down and blasting out code straight away, and you have to be very flexible and dynamic with the balance you strike. The goal is to write a concise, easily understood solution to a problem, in the least amount of time possible. Insisting on planning everything out, to make a "blueprint" first, often doesn't work, it presupposes that you can gain all the knowledge you need to solve the problem with a piece of paper and a pencil. While that approach can be useful, often you will learn just as much or more by blasting out prototypes to explore the solutions via code. If you follow the blueprint approach exclusively, you may find that you've got it all worked out nicely on paper only to find huge gaps in your knowledge as you begin to translate that in to code, gaps that would have been flushed out with a couple of throw away prototypes. On the other hand, if you find yourself spinning your wheels writing code, constantly rewriting things while in a fog, it's time to set aside the keyboard and break out the paper and pencil for a while. It goes back and forth. 



			--
			Robin Murray
			Hatchet Lake,
			Nova Scotia
			Canada


			On Sun, Mar 23, 2014 at 12:07 PM, George N. White III <gnwiii at gmail.com> wrote:
			

				In view of the recent discussion of shoddy coding practices shown by Apple, many commentators mentions the famous "Goto considered harmful".  Here is another 
				
				"academic" perspective that rings true:
				

				In an interview, 2013 ACM A.M. Turing Award winner Leslie Lamport was asked:
				
				

				More recently, you have worked on ways to improve how software is built. What's wrong with how it's done now?

				People seem to equate programming with coding, and that's a problem. Before you code, you should understand what you're doing. If you don't write down what you're doing, you don't know whether you understand it, and you probably don't if the first thing you write down is code. If you're trying to build a bridge or house without a blueprint <http://research.microsoft.com/en-us/um/people/lamport/pubs/pubs.html#wired> -what we call a specification-it's not going to be very pretty or reliable. That's how most code is written. Every time you've cursed your computer, you're cursing someone who wrote a program without thinking about it in advance.

				There's something about the culture of software that has impeded the use of specification. We have a wonderful way of describing things precisely that's been developed over the last couple of millennia, called mathematics. I think that's what we should be using as a way of thinking about what we build.

				<http://www.technologyreview.com/news/525621/three-questions-for-leslie-lamport-winner-of-computings-top-prize/>
				
				-- 
				George N. White III <aa056 at chebucto.ns.ca>
				Head of St. Margarets Bay, Nova Scotia 

				_______________________________________________
				nSLUG mailing list
				nSLUG at nslug.ns.ca
				http://nslug.ns.ca/mailman/listinfo/nslug
				
				




		_______________________________________________
		nSLUG mailing list
		nSLUG at nslug.ns.ca
		http://nslug.ns.ca/mailman/listinfo/nslug
		
		




	-- 
	Oliver Doepner
	http://doepner.net/ 


-- 


Christopher Thompson | Client Care | SolutionInc Limited
Office: +1.902.420-0077 | Fax: +1.902.420.0233

Email: chris.thompson at solutioninc.com
Website: www.solutioninc.com <http://www.solutioninc.com/> 

SolutionInc Limited - Simplifying Internet Access

SolutionInc Limited - Simplifying Internet Access With operations in more than 45 countries worldwide, SolutionInc is an established global leader in 
Internet, centralized hotspot connectivity, billing and management solutions. SolutionInc provides software and services to the hospitality and 
telecommunications industries through its award-winning, patented technology software products: SolutionIP(tm) and SolutionIP(tm) Enterprise. 
Through 700,000+ touch points, SolutionIP(tm) allows people to easily and securely connect to the Internet from locations such as hotel rooms, convention
 centres, universities, restaurants and airports. Patent Information <http://www.solutioninc.com/patents/>  

If you have received this e-mail in error, please notify me immediately at 902 420 0077 or reply by e-mail to the sender and destroy the original communication.

 Thank you.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nslug.ns.ca/pipermail/nslug/attachments/20140324/710ba56d/attachment-0001.html>


More information about the nSLUG mailing list