That dreaded moment comes in every software project development cycle. The plans are too ambitious, the time too short. After an exciting start, the groove descends into the valley of just plugging away, day after day, while trying hard to keep to an impossible schedule.
It comes every time, on every project (if it doesn’t please, please let me know where you work :-)
I’ve witnessed over and over is that this moment pushes programmers
into speeding up their pace. They convince themselves that what’s needed
-- what would make it better -- is more code. So off they go, coding
faster and faster, cutting more and more corners.
But that sense of panic is working against them. And against their goal of getting the software released.
an abstract sense, one can view software development as the act of
‘thinking’ about how to solve problems in a robust manner. The code
itself is just a by-product of that thinking. The work is problem
solving, but the final output is code.
you speed up programming, it comes at the cost of reducing thinking.
The programmers just fall back into writing the most basic rudimentary
splat of code that appears to run. Because of the rush, that code is
inherently fragile; the little niceties and less obvious corner-cases
are always the first casualties. Spaghetti is a real possibility.
worse ‘code re-use’ goes completely out the window. So now the system
is rapidly getting filled with redundant code that is fragile,
inconsistent and most likely convoluted.
this first wave results in a mounting bug list, it gets plowed under by
even more waves, each one going faster; each one with a deeper sense of
urgency. But each one causing more damage. The bug list explodes, the
specs change and the technical debt swells to some epic proportion,
often ending the project or at very least, resulting in an unstable
release that is a nightmare to use or upgrade.
And thus speeding up the coding is a recipe for failure.
does need to happen is to either speed up the thinking (if that is even
possible) or start slashing the goals. Deep, but well-thought-out cuts
(to avoid painting oneself into a corner) can push the excess work into
later cycles. So long as enough thought about the future is applied,
the added technical debt can be minimized. Meanwhile the development
pace should be maintained. Evenly.
it’s scary, but with experience this point in the process can be
anticipated and even managed properly. A code panic, on the other hand is
most likely to lead to ruins.