SLUG Mailing List Archives
Re: [SLUG] great code to learn from - request
- To: Rajnish <rtiwari@xxxxxxxxxxx>
- Subject: Re: [SLUG] great code to learn from - request
- From: Rick Welykochy <rick@xxxxxxxxxxxxx>
- Date: Wed, 21 Sep 2005 16:22:02 +1000
- Cc: slug@xxxxxxxxxxx
- User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041217
I recall reading something similar in a M$ publication a long time ago.
One has to go through
many iterations bad code/design before one recognises one that is good
(great ?). I guess that means
So I think in the tradiation of anti-partterns, it is best to ask,
which code sucks and why, and then try to avoid doing that.
learning from others' and your own mistakes & experiences.
Hasn't made me a better developer yet, though.
My rule of thumb is that three iterations result in a reasonable
low-bug high-reliablity product. (Of course, provided you and/or your
team are competent! MS programmers need not apply)
First iteration: really just a prototype that reflects the first design
often developed with RAD tools with scant regard for optimisations
Second iteration: this is probably an alpha version, that moves to
beta status and is inflicted upon your users/public
Third iteration: this is the chance we'd all like to have, and sometimes
do get: redesign and recode the parts of the product you now know
are sucky due to feedback from the Real World (TM)
These iterations are not 'releases', but major major redesigns and recodings.
I consider myself lucky if I can get time/funding/resources to get to the
Third Iter, but usually, the "enterprise" stops at the Second. For a brand
new idea, I think that only a fool would eschew iters First and Second.
Rick Welykochy || Praxis Services
Failure is not an option, it comes bundled with every Microsoft product.