The Eternal Struggle Between Business and Programmers

"The Business" is mostly full of non-technical people who, while they might not be analytical or even as smart, but who understand politics well and know how to solve the local optimization of seeking their own careers and power. They don't want "more features! now!" Their motivations are things like (a) making their mark, (b) concentrating a power base, and (c) tying their names to an obvious, low-risk opportunity for visible gain. The reason they want "features" is that everyone who gets power needs to use it to make some kind of mark in order to retain that power. Programmers tend to underestimate "business idiots" while refusing to acknowledge that those "idiots" being in charge means that they're good at something.

Programmers don't want "more refactoring!" out of some knee-jerk defensiveness. The good ones want technical excellence, which dies in deadline culture. They want to build things they can be proud of. And there are careerist reasons for them to feel this way, because tech gets shit on as soon as things go bad, no matter who's really at fault. If you build a system that generates $50 million per year, then make a mistake that causes 4 hours of downtime ($23,000 loss) of that system, you'll typically be mortally embarrassed and possibly fired. So, programmers have solid,m career-oriented reasons to push back when asked to do something in a quick, sloppy way. They (and not the managers who ordered them to cut corners) will be the ones to suffer when things fall apart.

The hard and painful truth is that business-oriented programming is underappreciated by business and unattractive to talented programmers, and so almost a complete non-starter. The good people tend to fight for a while (for more refactoring, more autonomy) but eventually disengage or go elsewhere (e.g. consulting, where there's an outside chance of getting what they're actually worth). The bad programmers don't care about "refactoring" per se but have learned how to parrot the good ones. Thus far, VCs have tried to overcome this problem (the complete non-viability of business-oriented programming) with the smoke-and-mirrors show of startups and paper millionaires, but the wiser people are starting to figure that one out, too.

For the record, there isn't a huge mismatch between "The Business" and "The Programmers". Great programmers are perfectly happy working for the business, if compensated appropriately (see: quant traders at hedge funds) or if they own it. They just don't like working for the business as a subordinate, because it leads to spending a lot of time implementing stupid features that obviously don't make sense or deliver value to the company, but that meet the parochial needs of a specific ambitious executive (who won't protect them in return for their service).

Thus, management has a problem. To allow refactoring, they need to believe there's a technical person in charge that is able to keep the refactoring in check. But, as a manager, how would you asses that?

When you think of a time estimate, you're going to come up with a time assuming that the problem can be solved in the most obvious way, and that's because we can't possibly know about the problems we don't know about. It's not a terrible crime to not know things you don't know, but it is bad to make time estimates on things we don't know.

The correct answer is "give me a few hours to a day to look into the problem and I'll let you know how long I think it will take". The amount of time it takes for discovery depends on how big the feature is of course, but the point is you need to get your feet wet to determine what unknowns there might be, and you shouldn't give an estimate until you have done that.