In engineering, software or otherwise, whatever decision we make this month, we have to live with it from now on, or until someone invests additional time in reversing it.
If we cut corners to squeeze in a date, we have additional drag on our work from that day forward.
That hack is as permanent a part of the product as any well-considered change. It doesn't refresh with the next month, quarter, or planning period.
There is no end-of-period reset. Making new goals doesn't affect the baggage of old goals.
Do the other people have to live with January 2013 for the rest of their lives? Or is it only engineering that has to deal with every dirty hack since the beginning of the organization?
Some ongoing "sustaining" and "accelerating" work is needed to drive down the cost and drag of past decisions that didn't work. The "accelerating" work also sets up the product to scale and manage runtime costs. Ignoring those to chase an ambitious schedule is a long-term disaster.
I wonder if non-engineering parts of a company properly recognize this "code is forever" situation.
That doesn't mean we should never hurry or not be quick; we all want to produce a quick and meaningful effect, but if we get there by cutting corners and producing risky code, we need to productize it (to turn the working prototype into something that we expect people to trust in production).
It's good to borrow time from the future to capture a market opportunity, but we owe the future that time; we can't borrow freely forever as it costs us nothing.
I think incremental and iterative development is a good thing. I think it's reasonable that we adjust our product to keep up with changing market conditions if we can.
The problem is rushing weak code out the door frequently and often.
A continuous stream of hacks-we-must-live-with-forever will destroy our ability to produce quickly and may impact our ability to build and operate the system in a cost-effective way.
No comments:
Post a Comment