|HCS Consulting Group.|
|We make Complex Systems simple|
By Albert D. Kallal
Tuesday, January 08, 2002
Working Slower = More Work
I have noticed that if you let developers write code without regard to size, and execution speed then rate of development can really increase. In other words get it done and tweak it later. If the product becomes too slow and unwieldy then yes.......something must be done. Thus, the balance between how fast developers work and the size/bloat/efficiency must always be factored into the soup pot.
There is a lesson to be learned here.
There is a VERY FINE LINE between writing good software and bad software when developers are pushed too hard. In other words, that great developer team can be pushed hard and do amazing things. However, if the team is pushed beyond a certain level, then the quality of code written drops like a rock.
Since so much code is dependant on other routines, then those poorly written routines will cause the product as a whole to suffer. In other words, push the team too hard and the quality of the code they write suffers. Ok, now slow the team down and let them catch their breath,.......guess what? You still have that poor code in the product...and it will effect the overall quality of the product.
Now the team is writing quality code, but the product and rate of development will continue to suffer from the existing poor code base. Think of it like holding a long stick in your hands. A little movement at the wrist level causes a lot movement at the other end of the stick. The effect of poor or good code in a product is magnified much like the end of the stick as the project progresses. Small errors and omissions in the early stages can really bite towards the end of the project.
Good software design tends to be much smaller in size than poor software, and it actually runs faster. In other words really good code and design beats the pants off of poor code.
It follows that when you attempt to develop a product you must have the resources to do the job right. This is plain and simple. Thus, to complete a project you can drop features or perhaps allowing more time to complete some code. Much of scheduling and management of a software project is to manage and *restrict* resources. Fine, ok, you can restrict features, but those existing features that you keep must be well written and designed. Do not confuse the issue of cutting features with the idea of speeding up the writing of code. Donít try to speed up the writing of code. Whatever you keep, write it well!. Even more important is not to speed up the design process.
Last year I had a software project get into trouble. Deadlines etc. were slipping faster than a slippery slope. The company had a "season" and we missed the deadline for implementation of our software. Worse was that this software was mission critical and we had convinced them move over to this software *while* we continued to implement critical features. The business could not function without this application (it was a booking application for a ski tour company). We reached a point where it was clear that we could not meet the deadline.
Fortunately they still had the old computer system (sort of!). That system was now 10 years old (including the hardware!). The old system was a text based 8 user rs232 system. It was in pieces and this years data was now in the new system. The new system was a Windows based product. The old system was written when the Internet and things like email did not even exist. The new product was totally integrated with ms-office and had a lot email capability. At any rate, we had to move back to the old system. It took about 1 week to get the old system running again. That whole week, and what was accomplished is a great story.. ...but Iíll save that for another day. The staff simply re-keyed in all the bookings that had been done on the new system back into the old system.
* There are quite a few books that say removing deadlines in a software project actually makes developers work faster. Why is this so?