28 August 2007
Think before you code
Posted by Mikhail Esteves under: General .
In the past ten days, I haven’t written a single line of code for tarsnap. And I’m proud of it.
There has been a trend lately, particularly where internet startups are concerned, to measure success by the number of lines of code written. People talk about the all-important “first-mover advantage” and about things moving at “internet speed”, while Paul Graham — co-founder of Viaweb and of the Y Combinator startup incubator — lists “Release Early” as #1 on his list of lessons for startups to learn.
In a recent article about Y Combinator, Paul Graham pointed to the fact that two people had written 40,000 lines of code in three months as a sign that they were doing something right; he went on to point out that “you never see that in a big company”. To me this number is, if anything, a sign that things are going horribly wrong: Anyone who is consistenly writing more than 5,000 lines of code per month is either (a) not working on a problem which is difficult enough to be interesting (any half-competent programmer can write binary searches, quicksorts, and depth-first graph traversals at a rate of thousands of lines of code per day); (b) utterly incompetent (we’ve all seen people who can replace ten lines of working code with a thousand lines of buggy code); or© going to have to throw out and rewrite most of their code once they realize that it doesn’t solve the problem which they needed to solve — with this realization most likely coming after their first release.
Of these three scenarios, I think it is the third which is the most dangerous, and — with apologies to Fred Brooks — I’m going to call it the “zeroth-system effect”. In his book “The Mythical Man-Month”, Fred Brooks notes that after a first system which works but has very few features typically comes a second system which is bloated with all the features which were considered but not included in the first system (and as a result of this, the second system invariably takes longer and is more expensive than expected). The zeroth system is what comes before the first system: Not only does it have very few features, but it doesn’t work.
One Comment so far...
shane Says:
29 September 2007 at 3:34 am.
Thanks for your article “Think before you code”. I come from a background of coding in a number of disciplines. Recently was working for a large Govt organisation that had a waterfall development cycle (think before you code). In it we were expected to trap every use case, then plan it, then model it then write it – ie less code lines, more planning. However this also failed on a regular basis as no one can capture all use cases and the process became self serving and the code came last.
Many of its critics were saying the XP extreme programming style of code first, code lots would be best. However this leads to many dead ends and traps unless you have a very experienced programmer at the helm. Even then it tends to produce less than efficient code.
Lots of code does not mean success. Getting a product out the door first is important if you want to gain market advantage and the ‘moral’ superioirty of being the field leader and expert. However, as a coder you need to remember that is good for the marketers and bad for the customer. Vista (and no, I’m not on an anti-M$ rant here) is an excellent example of code released way to early to gain market advantage (or $)
Fro me I now sit somewhere in the middle of XP and Watefall Life Cycle Dev methodolgies. i have a few simple rules which help.
1 – Write a program once. Then throw it away and write it again having learnt from all the mistakes you made the first time.
2 – Test early Test often.
3 – Test with the end user as coder assumptions are the mother of all foul ups.
4 – Write in small chunks, then do 2 and 3 above.
5 – As long as it is pretty the end user will love it. No matter how good the code is, do not present it without a ‘pretty interface’. Good code is often rejected owing to a plain or basic interface as first impressions last.
6 – Visit the toilet, water fountain, stair case, coffee house or what ever at least once every 90 minutes. Visit these places if you are stuck – The keyboard stops you thinking. Walking the body lets the mind rove free and find the solution that is already there.
7 Don’t be afraid to back out of a coding corner. (See rule 1)
8 – Code until completion – Then refactor in pieces. A slow programe is not a bad programme. It is just slow. At least it is working. A slow programme can be sped up in pieces. see rule 1.
The XP style (lots of code quickly) does let you throw away code more easily and re-write as it has the least initial cost over head of any development style. A waterfall dev cycle is very unlikely to let you throw away code as the powers that be have too many $$ in it to let you throw away code. However it does teach you one valuable lesson – think before you code.
90% of good development is in the thought process and planning. very little is in the typing and ‘number of lines’ of code. A good coder does more in their head than on their keyboard. When the hands are busy, the mind is not set free to think. Even a monkey can type but only a good coder can think.
