[nSLUG] Lamport on "software culture"
odoepner at gmail.com
Sun Mar 23 22:37:26 ADT 2014
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"  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.
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
> 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
>> 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
>>> *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
>>> 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.
>>> George N. White III <aa056 at chebucto.ns.ca>
>>> Head of St. Margarets Bay, Nova Scotia
>>> nSLUG mailing list
>>> nSLUG at nslug.ns.ca
> nSLUG mailing list
> nSLUG at nslug.ns.ca
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nSLUG