[nSLUG] Lamport on "software culture"
nibor.yarrum at gmail.com
Sun Mar 23 14:07:09 ADT 2014
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nSLUG