The Eternal Struggle Between Business and Programmers

Part of the problem here is that developers don't do a good job of creating a culture that values refactoring as a key part of the overall process. The underlying issues are not, at a general level, unique to software. It's not like the business folks at GE aren't asking for more features faster. However, other engineering fields have done a much better job at making things like, e.g. testing, a core part of the culture. GE doesn't ship a refrigerator without incredibly extensive testing, not just because of the threat of lawsuits (another thing software developers don't really face), but because the relevant engineering bodies have made testing a non-negotiable part of the process.

From a manager's point of view, there's a big difference between having to say "our engineers would like some time for refactoring" and being able to say "refactoring is just part of the process--any other engineer would tell you the same thing."

It's worth noting that all three parties (devs, business, board/management) are acting out of fear. It's little wonder that the outcome is poor.

* Management needs to get over itself and have a true vision beyond, "omg competitors are making money...more features!" that it conveys to everyone.

* The businesspeople need to absorb some of management's anxiety (and their own) on behalf of devs, and communicate with customers to ensure the vision aligns with what they want.

* The developers need to stop whining, up their game and go a bit slower so they don't get themselves in these situations to begin with. Give them what they need (quality code) not what they want ("anything that works NOW!!").

The business world seems rife with people who are purely reactionary, and yet still have the gall to wonder why they cannot innovate: "We don't have money for R&D!" OK, you don't have money for growth then.

This is a vague discussion that stays at a high level... I'm not sure how valuable this kind of generalization is.

The "programmer" side of this discussion certainly does not always have a grasp of the needs of the business in mind, and it doesn't help that estimations of effort for new features (or refactoring efforts, even minor ones) are notoriously difficult. Some programmers are business-savvy, but most really aren't -- not necessarily due to ignorance or inexperience! It takes significant effort & time to keep a finger on the pulse of a business, to really know how much this contract matters in the grand scheme, what's really required to land it, and when.

So it comes down to communication, and different people figuring out what actually needs to be communicated, but that's so relevant to everything it's almost useless to say.

Case studies would be more interesting -- real ones, inasmuch as that's possible without making real people look bad. The author seems to consult on this sort of thing for a living, so that's probably possible.

One major problem with this: Business lies.

Not maliciously, it's just the way they do things. They think they're negotiating instead of cooperating. If they really need feature X in 6 weeks time, they will tell the Programmers they need it in 4 weeks.

Programmers however will be honest, and worse, optimistic. When they say it can be done in 8 weeks, 10 weeks is probably more realistic.

That huge difference removes all the room for coming to a mutually satisfactory compromise.

Even if both sides agree on a compromise, the Programmers will be fucked. They only difference is that they've fucked themselves, but since in the end it will come out Business "lied" (we all know it, the moment we delivered just in time, and nobody cares for weeks), they will still blame Business.

Business and Programmers need an interpreter that doesn't take sides, but hey, we just figured out management is useless, right?

One thing not to forget is that if you unleash refactoring on a grand scale you'll end up with second version syndrome.

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?

I've always wondered why, in a company that loves 6 sigma and other process improvements, we never really got behind refactoring code. I mean, cleaning the flow of books and nuts through the line is praised, but the flow of an array through logic is not. I think it has to do with the former being easily seen - physical and the latter being abstract. It could also have to do with easily proving repeatability... It is easy to see that the bolts will be installed 500 time in a week; less so about the logic. In fact, I think if we could show measurable velocity improvements from refactored code; it would show business how investing in refactoring pays off. Kinds like a Toyota production system for c++.

> The Business needs to agree that the Programmers have heretofore gone more quickly than they really can, that they cannot sustain this pace, and that to do so merely hastens the ultimate decline of the entire product line, and perhaps the company.

Yes the business agrees, but then continues to demand new features. Nothing changes until the people change, code is tossed out, and the whole thing starts over again.

My most heartening point of this post and story, is that there are only 21 comments as of this post (22 after I hit 'enter'). So, while I sourly identify with this piece and want to post it outside of my cube wall... this isn't garnering nearly the crowd of other universal HN siren songs.

Phew.

The timing of this post is great! So tented to send it to my boss who apparently has no clue in software engineer. Great article! Recommend it!

This is a pretty shallow analysis, and I don't find it useful.

"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).