Friction feedback loop
Your organization is highly focused on time-to-market. Burn rate is high and revenue is low. Proposals to spend time optimizing development processes are entertained on principle and swiftly discarded out-of-hand; every ounce of developer attention must be devoted directly to product development.
Yet developers are spending increasingly large portions of their time on tasks not directly related to product development. Hand-copying file revisions across release branches, rewriting functionality and interfaces to match violently flagellating specs, while still turning out heaps of code optimized for schedule rather than maintainability and reuse.
Heaps of hacky code makes for heaps of bugs. Specs change again and bugs continue to roll in. The workload continues to increase as time ticks away, the project’s air supply growing heavy and toxic. Management caves to pressure, granting a milestone slip and the team has a momentary breath of fresh air. The loop continues, only now behind schedule.
Development progress slips into the red as each day more bugs are reported than fixed. The release date approaches on the long crunch toward release. Eyes go bloodshot as nerves begin to fray. Weekend and vacation work become the norm. Then the big day.
Release! To a cheerful management with plenty of rewards and good-on-yas with cherries on top and glimpses of grand rewrites in the sky. Just another speed bump. Back to the grindstone as customers do their own QA, reporting blazing hot ultra-mega-high priority bugs with varying degrees of rage, elation and flippancy.
Your product is cool.
Your product is hot.
Your product sucks.
Your product is moot.
Your product is a dream come true.
But does your product make money?
If not, you’d better cancel that second honeymoon and gear up for what can only be described as war. Man Vs. Machine, developers hack through twisted wrecks of code leaning heavy on what-were-supposed-to-be-temporary structures that ought to be condemned. Days bleed into weeks and all semblance of a unified product direction is drowned by the cries of screaming souls.
What if we could do this better?
Do we need to release a fully-configurable decision making platform in order to start generating revenue for our organization? Is there something that we could create today and ship tomorrow that would generate more revenue from our customers than the 2 days it cost us to produce? What kind of feedback would we get from customers? Bug reports or feature requests? What would a grand rewrite cost at this stage? A day? How about a spec change? Hours? Could we turn that into minutes?
What can we do to front-load this most critical aspect of any software development project?
Comments(0)