Less talk, more code please

More stuff that pops into my head during triage meetings.


Oh, thars –

Data-driven, Top-Down, Structured, Procedural and Agile
Incremental, Bottom-up and Spiral (though it’s fragile)
Rational will suck you in and bleed you with a smile
TDD will get you there, though it will take a while

CMM will curl your spine and make you want to die
Pre-factoring and Waterfall will hang you out to dry
Patterns lead you down the path then rape you in the shrubs
Simple hacking ‘ud be great, except for all the bugs

Experience has shown you find success in just one way:
Implement it six times; throw five of them away…


I’ll scan in some of the cartoons I draw.  Maybe…

Author: landon

My mom thinks I'm in high tech.

12 thoughts on “Less talk, more code please”

  1. Also, a fair number of you may think I am kidding.

    I am utterly serious.

    About the fifth or sixth macro assembler I wrote was pretty good. Commercial quality, even. I’m not sure if this damns me as a slow learner or what, but I see this a lot in the industry: Somewhere around your fifth or sixth try at a system is the one you can walk away whistling from.

  2. The last one is not always the best. Sometimes you get carried away after a few redesigns and create real over-complicated messes.

  3. @Reed: Usually it’s the second one that’s all messed up (Fred Brooks’ famous “Second system syndrome”). Or the third. By the time you get to the fifth or sixth reimplementation the idea is that you’re *tired* of doing it wrong, tired of trying (and failing) to do it right, and that you just want to get the job done.

  4. As long as it’s not on an accordion. 🙂

    Seriously: No, I don’t mind. Even an accordion would be fine. I hereby place the above doggerel in some kind of mumble Creative Commons mumble. Do what you will.

  5. I so want to enter this poem as a backlog item (with a generic title “investigate module loading bug…” just to see how long it takes for someone on the team to discover it. Brilliant!

  6. I like it, although I don’t want to believe that I have to do it 6 times before it’s good. If it is true, though, it certainly supports the “keep is simple, stupid” practice; not just in terms of code, but of the number of features in the program, as well as of choosing the easiest, nicest language that will suit your project (e.g. don’t look down your nose at Basic, or better yet, Lisp, in favour of C++ and Java, if you don’t need them). And closely related is to avoid over/premature generalisation, as described in the deadly sins of programming (http://blogs.msdn.com/ericgu/archive/2006/08/03/687962.aspx).

Leave a Reply

Your email address will not be published. Required fields are marked *