Deliver software better, not faster
Stop me if you’ve heard this one:
“A rabbit walks into a …” — wait, wrong opening.
Try this one instead: “We don’t have time to do it right.”
That’s usually followed a bit later with: “We know it’s wrong. We don’t have time to fix it.”
And that one is usually followed a few months down the line with a variant of several options:
“We stopped development for a while, because we had core issues and legal said we had to fix them.”
“We shut down the project because it had security holes that were exploited.”
“We rebuilt the project because some of our core dependencies were fundamentally broken and so was our product.”
“We thought we had a viable project, but nothing worked and it was too hard to keep going.”
Sometimes these are disguised by manager- or tech-speak. “We decided we needed to rewrite it in Go” basically means the project suffered from flaws in its original language that probably went too far.
So is this a management problem? Or is it the programmers’ problem?
Try this one instead: “We don’t have time to do it right.”
That’s usually followed a bit later with: “We know it’s wrong. We don’t have time to fix it.”
And that one is usually followed a few months down the line with a variant of several options:
“We stopped development for a while, because we had core issues and legal said we had to fix them.”
“We shut down the project because it had security holes that were exploited.”
“We rebuilt the project because some of our core dependencies were fundamentally broken and so was our product.”
“We thought we had a viable project, but nothing worked and it was too hard to keep going.”
Sometimes these are disguised by manager- or tech-speak. “We decided we needed to rewrite it in Go” basically means the project suffered from flaws in its original language that probably went too far.
So is this a management problem? Or is it the programmers’ problem?
The answer is: It’s both.
It’s a management problem because managers often prioritize and force speed. They overpromise feature completion, which means that a function that rightfully should have taken six weeks is expected in two.
And once it’s delivered “in time for the demo,” it’s already time to allocate effort to the next feature … that also should have taken six weeks but was only given two weeks to complete. The old feature “works,” so why allocate time to do it well?
At the same time, this is also a programmer problem because too many programmers are desperate or arrogant. Here’s an example of a not-uncommon conversation in a Monday morning software project update:
Manager: “How long will this feature take?”
Programmer: “It will take a week and a half.” [This was a pretty big change involving technology that was new to the project’s technology stack.]
Manager: “Can we have a demo by Thursday?”
Programmer: “No, because the feature will take a week and a half.”
Manager [nonplussed]: “How about a demo on Wednesday?”
Programmer: “No. It will take a week and a half. We might get lucky and get it faster… but it will take a week and a half.”
This programmer was absolutely correct to push back. The manager was creating massive risk to the project by promising a demo faster than the programmer estimated for implementation.
In fact, the manager should have given the programmer more time. What would happen if the demo took longer than expected? What if the programmer fell ill, or if the feature’s technology looked good on paper but wasn’t actually available in full?
I’ve seen this kind of feature acceleration far more than I should have. Programming takes time to get right.
It’s a management problem because managers often prioritize and force speed. They overpromise feature completion, which means that a function that rightfully should have taken six weeks is expected in two.
And once it’s delivered “in time for the demo,” it’s already time to allocate effort to the next feature … that also should have taken six weeks but was only given two weeks to complete. The old feature “works,” so why allocate time to do it well?
At the same time, this is also a programmer problem because too many programmers are desperate or arrogant. Here’s an example of a not-uncommon conversation in a Monday morning software project update:
Manager: “How long will this feature take?”
Programmer: “It will take a week and a half.” [This was a pretty big change involving technology that was new to the project’s technology stack.]
Manager: “Can we have a demo by Thursday?”
Programmer: “No, because the feature will take a week and a half.”
Manager [nonplussed]: “How about a demo on Wednesday?”
Programmer: “No. It will take a week and a half. We might get lucky and get it faster… but it will take a week and a half.”
This programmer was absolutely correct to push back. The manager was creating massive risk to the project by promising a demo faster than the programmer estimated for implementation.
In fact, the manager should have given the programmer more time. What would happen if the demo took longer than expected? What if the programmer fell ill, or if the feature’s technology looked good on paper but wasn’t actually available in full?
I’ve seen this kind of feature acceleration far more than I should have. Programming takes time to get right.
While there is certainly a balance between finding something that’s “workable” versus “the best,” most programmers and managers prioritize “time to implementation” over all other features.
This leads to unmaintainable, feature-poor code that performs badly and is difficult to fix.
Don’t be one of these people, either as a manager or as a programmer. Work out what you need to do, the features and metrics you must hit. Then do what you must to deliver them, in a way that you’re willing to show them to others as an example.
Take the time. In the end, you’ll be happier, and so will the people you’re delivering to — even if they don’t always recognize it at the time.