The Eternal Struggle Between Business and Programmers(blog.thecodewhisperer.com)
blog.thecodewhisperer.com
The Eternal Struggle Between Business and Programmers
http://blog.thecodewhisperer.com/2013/11/11/the-eternal-struggle-between-business-and-programmers/
10 comments
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++.
I'm agreeing with you. It has to do with code not being visible to management. That is intentional, management doesn't want to see or think about code. They want to push that entire concern to the technical team and never see it. Which is reasonable enough.
Then they have a time demand or feature demands (which amount to the same thing) and suddenly the technical team doesn't see a lot of breathing space to work on code quality. If management trusts a credible view expressed by the technical team or the technical team can irrefutably prove that the added time will improve some metric of business interest then this can change.
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!
As a mostly business guy, I kind this post said it best. It is about velocity and when to tractor/automate. It came across HN a couple weeks ago, but I'm not great at searching HN.
http://blog.hut8labs.com/speeding-up-your-eng-org-part-i.htm...
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.
* 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.
I think a big part of the problem is that nobody ever teaches developers how to estimate and they are almost always wrong. A typical scenario is; PM describes a feature, asks for an estimate, and the developer gives it to him, right then and there. What's wrong with that? The developer hasn't done any research or exploration into the problem at all, and has no idea what he's talking about.
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.
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.
I applaud the thought, but then they have to have an estimate of how long the estimate will take... which often ends-up wrong.
That's true :) But at least the absolute amount wrong will be hours or days, instead of weeks or months. Also, you can leave it a bit more vague and just say "I need to explore the problem space a bit before giving an estimate".
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.
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.
I read the article to be a light approach toward the question of 'What do managers even do?' because it seems managers spend much of their time balancing those two demands (features / technical debt).
> 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.
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.
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."
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."
> 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.
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).
"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).
Well said.
> 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 . . .
I'm at the "disengage" point. The higher ups aren't heeding my warnings that what we are doing is not sustainable. Eventually the system will enter a permanent broken state and I just don't care anymore.
> 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 . . .
I'm at the "disengage" point. The higher ups aren't heeding my warnings that what we are doing is not sustainable. Eventually the system will enter a permanent broken state and I just don't care anymore.
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?
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?
Isn't the solution to allow very regular (daily?) refactoring, instead of pilling new stuff for weeks and months and then having a big refactoring party?
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?
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?
Phew.