Comments on: Think before you code http://www.thejackol.com/2007/08/28/think-before-you-code/ 01100010 01101100 01100101 01101000 Tue, 07 Feb 2012 21:10:47 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: shane http://www.thejackol.com/2007/08/28/think-before-you-code/comment-page-1/#comment-78762 shane Fri, 28 Sep 2007 22:16:40 +0000 http://www.thejackol.com/2007/08/28/think-before-you-code/#comment-78762 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. 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.

]]>