November 11, 2013 (updated November 21, 2017) Simple Design, Surviving Legacy Code, Not Just Coding
This reminds me of the concept of the conflict resolution diagram from the theory of constraints. You have a seemingly mutually exclusive conflict (more features vs. more refactoring), that can be broken by both parties realizing they have the same goal. Thank you for your well written article!
Great writeup. I've always been on the 'programmer' side of the fence and it's very easy to overlook the fact that business and the the programmers want the same thing in the end.
Nicely put. Great things happen when we listen to what others means rather than what they say, and then respond to that => Get a shared understanding of the problem and solutions will come by themselves.
Rather than talking about compromise/equilibrium of refactoring vs features, I use another reasoning to make the code base better aligned with business. The reasoning is short (and simplified) : For a given feature, a good programmer will produce better code in less time than a bad programmer (that will have to stabilise a more complex solution). A programmer is good mostly because he has trained. So if a company wants better code, then better create a training environment than invest loads of time for refactoring.
I've found much less resistance to this than other approaches I've tried. I also think that life would be easier if we were better at demonstrating the business value of good code/architecture/infrastructure etc. That's what I'm working on right now.
Merci, Johan, de tes commentaires.
Unfortunately, I only have a model and no hard evidence for the claim that refactoring reduces volatility in the cost of new features. Measuring this stuff creates all kinds of problems, because of the sheer number of confounding factors in the research. I also have only an intuition that the cost of refactoring doesn't dominate the costs due to unhealthy design. I think the difference shows up most in support costs, but you can't measure support costs that you don't incur. :) I've seen organisations spend 70% of their development budget fixing problems, and I think that we can design ourselves away from that problem, but I haven't got the permission to run a controled-ish study-ish with that hypothesis.
Not only that, but we have to be careful about measuring the learning curve, just one of the many confounding issues that makes researching this topic difficult.
Please, please, please share your results with us as you go.
Yes. Normally I use conflict resolution diagrams to look for obvious contradictions as a wedge to encourage people to change their behavior. In this case, we have unexpected alignment! I love it.
Nicely framed J.B. I think one dimension to this struggle is time and making the right overall decisions within a given time span. Within a frame of weeks or months the decisions lean towards the 'business position' and over years towards the 'developer position'. So, I think a dialog around is more constructive if is framed within a mutually agreed time span.
You're talking about evidence and measures. I guess you interpreted my last sentence as something of the sort "I'm working on a way of measuring value of good code/refactoring".
What I meant was that I'm working on sharing my "insights" on the value of it. Btw it was not measures that convinced me so there are other ways. Together with Remy Sanlaville we've developed a 20 min code demonstration for business users. It's still a bit crude but worked great on a few beta testers. I'm dying to share more details about it to get some feedback, but right now I really have to get back to preparing a workshop for tomorrow :)
Aha. Well, whatever we can do to make this concept clearer interests me. When you have energy, please share.
Indeed. I think that a perceived difference of goals and objectives lies at the heart of this pendulum swing. We agree on pretty fundamental things; let's use that to our mutual advantage.
I don't think we need to measure the cost of refactoring, so much as the cost of *not* refactoring.
Nicely put!
>> The Programmers need to agree that the Business has a legitimate need to deliver more features, that everyone’s livelihood depends on this, and that trying to ask for more than the Programmers can deliver forms part of the Business’s “job”, as it were.
My key lesson: Business and Programmers are in the same boat.
Do they share a common goal? (Do they really want the same thing?)
In this one aspect, yes: the Programmers want to deliver a steadier stream of valuable features, although they probably focus on the value of "it works"; the Business wants to receive a steadier stream of valuable features, although they probably focus on the value of "it excites the customers".
In my opinion the article translates to is bureaucracy makes life harder for the programmers.....
What (which part) is a bureaucracy to make life harder for programmers?
“If only you’d stop with this refactoring nonsense! The economy has to grow. We have to grow. The board of directors yells at the vice presidents, who yell at the third-line managers, who yell at the second-line managers, who yell at us. More features! More features! They only want more features! Not only can they not afford for you Programmers to slow down, but they need you to speed up! I need you to speed up! What do you go faster?!”
- This part basically means Business does not understand(maybe does not want to) the needs and concerns of the programmer. But a programmer only wants what is better for the business, often business takes this negatively thinking programmers want to slow down become a parasite for the business.
Programming as a profession isn't a like manual labour. 9 women can't produce 1 baby in a month. This is were the upper management of the programmers should come in try to fix the gap as you say. This rarely happens quite like that in the real world. The communication becomes bureaucratic nightmare and eventually programmers give in to what the business want NOW.
I don't see clearly what you're criticising here. I think you're criticising something, but your initial comment sounded like you wanted to criticise me or the article, but now I just don't know. :)
The Business's job is to ask for too much. The Technicians' job is to deliver as much as possible. If we agree that we're planning for 3 months, then we don't have to refactor, but then we have to throw everything away after 3 months. Often, the Business doesn't get this. But also, if we agree that we're planning for a 3 months, then we don't have to refactor. Often, the Programmers don't get this. They misunderstand each other; they disagree on the effects of refactoring or not refactoring.
Both sides get it wrong at different times.
As you say, though, when the Business "gets it wrong", they win the game, because ultimately the Programmers want their money -- except, of course, that the Programmers might be able to find another Business with whom they align better, and can ask for *their* money.
I still don't see the bureaucracy. If the Business and the Technicians won't talk about this situation, then it never gets better, but I don't see a bureaucracy.
I live in the real world, by the way.
I don't really like neither craftsman nor artisans. We're engineers. Well, not all of them, but I am. The root cause here is that we are often directed to problem with aggressive randomness, pretending agile is a way to skip requirement gathering, specification writing and all testing but a little ui testing here and there.
If you need creativity to program, then of course features can take anywhere from zero to years to complete. With proper analysis, you usually find yourself in a position where adhering to requirements constrain you so much that there is only one obvious implementation to follow.
"A well posed problem contains the seed of its own solution" - cit. I can't remember from whom, which is doubly true in software engineering, because 99% of the time we are not conducting research in new fields, just using off the shelf components.
Now the question is, why we don't push back to proper engineering practices? Of course business love to use journeyman, as it cut costs, and that waters down the voice of us engineers when we scream that we are not psychic and agile doesn't mean interactively guessing business requirements.
Most of the time it is not the creative crafting that kills deadlines, it has more to do with the fact that deadlines are set arbitrarily, without having any idea of how many guesses we have to deploy before matching the unknown business requirements.
On my first leadership role, I got a six month development plan down and it was completed within a two day error margin. It took two weeks to write, because it came with cutting and assembly instructions. Because we designed the interface properly between components before developing them, having more upfront design and analysis and zero integration costs afterwards.
Wake up, developers! Push back the urge of pretending our job is fuzzy in nature! Some of it might be, but most of uncertainty in today development world is generated by the managers themselves, forcing fuzziness upon us and pretending clear cut software in return.
We are not apprentices, journeyman and masters. We are engineers, mathematicians, scientists.
"First, the Business can easily justify their position: they need profit, and profit comes from sales, and sales come from features, and features come from, among other people, the Programmers. Without more profit, nobody keeps a job. Clearly, the Business has this one right."
Can you explain this? As written, it seems wrong to me. Unless the business just took a bunch of external funding and is operating in the red temporarily, why do we need *more* profit just for us to *keep* our jobs? The reason business generally wants more features is because they want to *grow* into new markets, and new markets require new features. If we already have paying customers, they will continue to pay (and in my experience, get even happier!) if we do nothing other than fix bugs and improve performance and reliability.
(I've had managers try to justify feature-chasing by telling me that customers expect new features, but I've never heard of any customer leaving because of this. We've definitely had customers leave because of stupid bugs, or because we didn't fix some basic performance issues, though.)
This is the fundamental schism I've always seen between business and programmers. Programmers want to take something good(-but-sloppy) and make it great. Business wants to take something good(-but-sloppy) and get it in the hands of a lot more people. This is frustrating to programmers because nothing can ever be truly finished. Imagine the programmers asking the business people to abandon leads that are 90% of the way through the sales pipeline because they think that's good enough. Even if it weren't a financial loser, it would surely feel very professionally unfulfilling.
I think he's referring to the game of telephone that happens between (in your stated scenario) VP > 3rd-line manager > 2nd-line manager > business person > programmer.
The hierarchy of management and the distance between "decision-makers" and "do-ers" is the bureaucracy that's being referred to.
The fact that the decision-makers and the do-ers don't have a direct line of communication makes any sort of arbitration difficult.
This, specifically, makes life more difficult for the programmer because of the balance of power - the VP can always fire a programmer but the reverse is not true. So a programmer simply has to do what he/she's told and is typically unable to even argue his/her case to the decision-maker (they can complain to the middle manager, but the middle manager has very little incentive to escalate the complaints).
At least, this is how I read initial statement.
So I don't think the initial statement was a criticism of yourself or the article, but rather the typical business case where decision-makers and do-ers do not have direct communication and the power is balanced almost entirely in the hands of the decision-maker.