Business software is Messy and Ugly
Posted by Uncle Bob on 12/13/2007
I was at a client recently. They are a successful startup who have gone through a huge growth spurt. Their software grew rapidly, through a significant hack-and-slash program. Now they have a mess, and it is slowing them way down. Defects are high. Unintended consequences of change are high. Productivity is low.
I spent two days advising them how to adopt TDD and Clean Code techniques to improve their code-base and their situation. We discussed strategies for gradual clean up, and the notion that big refactoring projects and big redesign projects have a high risk of failure. We talked about ways to clean things up over time, while incrementally insinuating tests into the existing code base.
During the sessions they told me of a software manager who is famed for having said:
“There’s a clean way to do this, and a quick-and-dirty way to do this. I want you to do it the quick-and-dirty way.”
The attitude engendered by this statement has spread throughout the company and has become a significant part of their culture. If hack-and-slash is what management wants, then that’s what they get! I spent a long time with these folks countering that attitude and trying to engender an attitude of craftsmanship and professionalism.
The developers responded to my message with enthusiasm. They want to do a good job (of course!) They just didn’t know they were authorized to do good work. They thought they had to make messes. But I told them that the only way to get things done quickly, and keep getting things done quickly, is to create the cleanest code they can, to work as well as possible, and keep the quality very high. I told them that quick-and-dirty is an oxymoron. Dirty always means slow.
On the last day of my visit the infamous manager (now the CTO) stopped into our conference room. We talked over the issues. He was constantly trying to find a quick way out. He was manipulative and cajoling. “What if we did this?” or “What if we did that?” He’d set up straw man after straw man, trying to convince his folks that there was a time and place for good code, but this was not it.
I wanted to hit him.
Then he made the dumbest, most profoundly irresponsible statement I’ve (all too often) heard come out of a CTOs mouth. He said:
“Business software is messy and ugly.”
No, it’s not! The rules can be complicated, arbitrary, and ad-hoc; but the code does not need to be messy and ugly. Indeed, the more arbitrary, complex, and ad-hoc the business rules are, the cleaner the code needs to be. You cannot manage the mess of the rules if they are contained by another mess! The only way to get a handle on the messy rules is to express them in the cleanest and clearest code you can.
In the end, he backed down. At least while I was there. But I have no doubt he’ll continue his manipulations. I hope the developers have the will to resist.
One of the developers asked the question point blank: “What do you do when your managers tell you to make a mess?” I responded: “You don’t take it. Behave like a doctor who’s hospital administrator has just told him that hand-washing is too expensive, and he should stop doing it.”
Comments
yachris2112 25 minutes later:
I wonder if turning the questioning around might work for someone like this. When he insists of quick-and-dirty, ask “Why?” He’ll say, “It’s faster!!!” So ask when it’s not faster… try to get him to remember (if he ever was a coder) when something horrible was hard to debug, fix or maintain.
It just seems like these kind of (bullies, frankly) can throw up infinite numbers of straw-man scenarios and the minute you say, “Well, I’m not sure about that one…” they pounce and say, “See? I win ALL THE PREVIOUS ARGUMENTS!!! You’re always wrong.” Put them in the position of proving their argument. As long as you don’t work there :-)
Ben Monro about 4 hours later:
Bob, I dont think the analogy of the Doctor in the Hospital could be any more spot on. Great post, all to real…
Roland Kaufmann about 5 hours later:
Some of these guys operate with an insane internal rate of return, which makes any short-term saving preferrable over long-term gain. Said another way: They code (or ask others to code) as if tomorrow never comes. Although it is myopically rational to prefer to exist today, it is usually not a good business proposition to choose a non-sustainable path.
Nirav Thaker about 5 hours later:
Sounds like the case of yet another Pointy haired boss. It’s sad how such people reach the place where they hold the say. I’m sure this CTO never even bothered to write the code himself.
Rachel about 7 hours later:
I hate to see people out in professional managerial positions behaving like this. Often they don’t even have a decent knowledge of how to develop applications.
Sadly though, many otherwise good programmers are just stuck in a bad situation because managers who insist on such bad practices often resorts to dismissing those who refuse to participate in their ridiculous anti-quality schemes.
The doctor analogy is great! Should be used wherever it can be.
Pete Wood about 21 hours later:
I’ve lost a job for not being quick and dirty, and for getting hot under the collar and resisting management. Dismissed for insubordination.
I’m currently reading ‘Difficult Conversations’ and intend to read ‘Fearless Change: patterns for introducing new ideas’. I’m not very good at dealing with these things.
‘Design Debt’ seems to connect quite well with management as it negatively connects money to dirtiness.
Ron Jefferies explanation of the four variables Resources, Quality, Timeliness and Scope (http://www.xprogramming.com/xpmag/kings_dinner.htm) can help but people still seem able to make irrational decisions in the face of all reason. I blame cognitive bias.
David Wright 1 day later:
Why does this CTO want everything done fast, without caring about the quality of the result? His success is being measured on amount of results delivered, and his bonus is probably directly dependent on the measurement. As I read elsewhere recently, “Be careful what you measure, because you will get it.”
If this truly the case, and I have seen it many times, no amount of cajoling or convincing is going to change his attitude, because doing so hits him directly in his own wallet.
So, I would want to know who is complaining about the defects, unintended consequences and low productivity; if it is another C-level manager, these problems must be hurting their bottom-line, and someone has to sort out the conflicting goals of management; this is a good time to bring an 3rd party, a consultant of some sort that works at that level and improves overall management.
However, if only the developers are aware of these problems and are in some amount of anguish about it, you better get over it, maybe look for a new job, because you can’t change this without risking Mr. Wood’s fate.
jim 2 days later:
Then he made the dumbest, most profoundly irresponsible statement I’ve (all too often) heard come out of a CTOs mouth. He said:
Say, isn’t that phrase carved into every MBA’s backside? Wonder if that has anything to do with the wonderful condition we find our economy in (compared to what it could have been if we were more focused on space exploration instead of protecting ourselves from some pseudo-religous nuts)? Or why many US companies are now in the hands of foreign owners who could care less about the quality of life in America given the miserable existence they have at home.
“Business software is messy and ugly.â€
Jon Limjap 4 days later:
Hah, I’m glad I was fired from this software company that always wanted things quick and dirty, and looked at OOP as “over-engineered” while proclaiming themselves “agile”.
Remembering that always gives me a chuckle.
drop 7 days later:
Make It Work Make It Right Make It Fast (make it clean?) This formulation of this statement has been attributed to KentBeckhttp://c2.com/cgi/wikiMakeItWorkMakeItRightMakeItFastsometimes (or all the times in some places ?) people forget to make it clean.
Tonetheman 12 days later:
Wow… I am not sure where you dudes are all working. The truth is most business software is messy and ugly. You might not want it to be that way but it is. And almost all marketing departments will force it that way in the long run, either with impossible schedules or with impossible business rules.
If you are living in a dream world then yes you can work on your business software for really long periods of time and your competitors who are doing it quick and dirty are beating you.
Sadly software for business is just that and nothing more. A tool to serve the business. It is not art just a way of making more money. If you are slowing the business down to make it perfect or beautiful, then you probably should not be working there in the first place.
Tero Parviainen 13 days later:
It sounds like this CTO might have actually played into your hands by throwing those straw dogs at you.
I just read Fearless Change, and one of the patterns in it is called Champion Skeptic. It’s about using the comments of a strong opinion leader, who is skeptical of your ideas, to improve your own argument.
Surely some of the opinions of this CTO were shared by the developers also, and it was beneficial to make them explicit so you were able to address them?
Shanti Braford 13 days later:
The CTO doesn’t sound like that great of a guy to work for, but I have to echo some of ‘Tonetheman’s sentiments as well.
I worked with one developer previously who was a sharp guy, but took the ‘code debt’ thing to the extreme. Always trying to get away with doing as little as possible and adding as few features as possible so as to avoid accruing a large codebase.
2+ developers got added to the team and quickly we started racking up more and more code. He would complain because we all of a sudden had to maintain so much code! (oh yeah, and our app had tons more features/etc)
Every 6 months, teams that are prone to ‘hackety hack’ style coding should go back and take a good honest look at things that can/should be cleaned up. If there’s honestly nothing to fix, but devs still complain about an unwieldy codebase, chances are its just the growing pains of complexity and not that there are too many hacks in the code.
Been There Done That 13 days later:
The hardest part of biz programming is sorting out the strange rules and making an elegant way of handling it.
Usually table driven methods work the best.
anna forss 19 days later:
And that the viewpoint quality first is to be implemented it is so important that the non developers stand by that viewpoint and make the developers feel that this is the actual viewpoint of the company. Just inspecting “surface” is an invitation to ugly code. For me, being a non coder and requirements analyst, it is too easy to view the result and just remark the things are obvious and not taking the time asking for how it’s implemented. But every time a complement something that looks good on the surface but is the result of messy code, I encourage messy code.
Peter J. Schoenster 23 days later:
Tonetheman and cohort seem to be missing the point.
Yes, a lot, a heckuva lot of biz code is spaghetti. Must it be? NO! That is the point.
Marketing does not tell me how to code. No one does. They should give me deadlines but I code as I choose.
What I have seen are some people in management positions who think they know how to program. I’ve seen management of programmers not manage standards, code reviews, unit tests, etc.. The results I’ve seen are crumbling barnyards of bug infested code. Some programmers find this normal. These same programmers often bask in the applause of the clueless after having wasted valuable time simply fixing a bug that should not have been there at all. They don’t question their process which allowed these bugs into production. It’s normal. That is the way code is. They live a self-fullfilling nightmare. But sadly their managers and their business too often expect no better. Too often they are praised for their cowboy heroics to fix what should never have been broken in the first place. Software solutions in such places end up delivering 10 times less 10 times slower than places which believe quality is possible and work towards it.
Keith Adeney 28 days later:
In our company we use the word ‘pragmatic’ to describe the balance between the “quick and dirty” and the “perfect and pristine” camps. In the iterative process of agile development it is nice to be able to go from the quick to the perfect, however only as long as the more perfect also has more business value. For me dirty and pristine are both bad news extremes. Dirty code translates to unmaintainable, bug-ridden, and hence expensive in my books (cleaning up such code is often how I earn my money!). And I can’t write beautiful simple pristine code because the business requirements that I have to code are often so full of exceptions, discontinuities, and keep changing (after going the extra mile of making something beautiful, only to have it obsoleted, you get more ‘pragmatic’). So that would make me an advocate of “quick and clean”.
Bubba 28 days later:
This is a great discussion about something near and dear to a lot of hearts (and wallets). I think Keith A hit the nail on the head about the balance between the quick-and-dirty and the pristine. You hae to be pragmatic to be successful.
In the very early days of a start-up, my favorite quote was “you can pay for it now or you can pay for it later” when discussing design and implementation items. The answer for the first year was always “pay for it later because we don’t have the money to pay for it now.” And this was true: we had the basic start of a product and had to get paying customers on as quick as possible (the model was SaaS with recurring subscription revenue). So the pragmatic approach involved several things closer to quick-and-dirty on the continuum.
As the company grew (in employees, customers, code base, and operational load) the culture of immediate returns was still pervasive. I call the mind set “how do I survive the next 8 hours.” It’s a perversion of several principles of Agile development most notably “Simplicity-the art of maximizing the amount of work not done-is essential” and “Deliver working software frequently.”
I compare it to buying things on a credit card figuring that you can make money now while only making the minimum payments. Eventually, this behavior leads to minimum payments that are too high to actually pay. With the mind set of just getting an immediate return or just surviving the immediate problem, you never pay attention to the mounting debt.
The key in all of this is having people that can look at a situation and find the right balance of paying now and paying later. That is, they have enough experience in developing software and systems (or even products) to anticipate the costs/benefits of choosing to do things in the quick-and-dirty realm or things up closer to the pristine. Those are the folks that really need a voice in the software development organization. Without them, and their voices, your organization just becomes the place where all of the developers learn the lessons they need for their next jpob
unclebob about 1 month later:
The key in all of this is having people that can look at a situation and find the right balance of paying now and paying later.
Another way to say this is, having people who can assess your net worth. As in real life, we want this number to be very positive. We don’t want to be “real estate millionares” who own millions in real estate, and have even higher debt.
Dean Wampler about 1 month later:
I think a great “Socratic Method” (or “Mental Kung Fu” – take your pick) approach to take with this CTO would be the 5 Why’s.
Basically, you ask “Why is business software messy and ugly” and then ask “Why …” for his answer and continue asking why until you get him to realize the root causes aren’t inherent in software itself, but they are leadership failures, etc.
Cory Adams about 1 month later:
It is sad but true that often CTOs are much like squirrels…. They are always after your nuts.
Seriously though why is a CTO concerned about how the code gets implemented at the developer level? But what seems strange is that Bob was asked to come in to help the company, hence one would assume that they knew they had a problem.
I’m confused. What did they think Bob was going to bring? A bottle with a magic genie?
Disagreement about 1 month later:
It is really easy to fix most business software:
1. Hire the best people you can pay. The most productive developers are 10 times more productive than the less productive developers. 2. Force them to use and create libraries to avoid code repetition. The best developers do this anyway, so you should just say it once and they should be doing it without much guidance.
Disagreement about 1 month later:
I almost forgot:
3. Give them a meaningful problem and ask them to use XP and Scrum for managing and reporting. This way they naturally will divide the problem into smaller problems that are maneageable while at the same time they will keep having a deliverable product.
4. Implement a dogfood mentality so that people in the company are forced to use the products made by the company. This way loosers will never try to be hired.
Tim Ottinger about 1 year later:
I was present in an all-hands meeting once where a development manager told all the programming staff to abandon all elegance and design and not think about what it means to the program. He asked for brute-force, least-thought hacks to get functionality in place.
It was in exceptionally bad circumstances caused by some poor policies on sales and sales staff compensation. Basically they made a few salespeople millionaires for selling more work than could be done. A lack of responsibility for delivery and a strong margin for sales, etc. In short, the manager was looking at the company folding and wanted to salvage as many contracts as possible before it happened.
I thought it was an exceptionally poor choice, even under the circumstances. It was a tough time. I’d like to never see it again.