Business software is Messy and Ugly. 76
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.”
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 :-)
Bob, I dont think the analogy of the Doctor in the Hospital could be any more spot on. Great post, all to real…
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.
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.
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.
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.
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.
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.
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.
Make It Work Make It Right Make It Fast (make it clean?) This formulation of this statement has been attributed to KentBeck http://c2.com/cgi/wikiMakeItWorkMakeItRightMakeItFast sometimes (or all the times in some places ?) people forget to make it clean.
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.
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?
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.
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.
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.
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.
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”.
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
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.
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.
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?
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.
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.
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.
This is great post, and I’m glad to see you sharing it with your readers.
ir 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. W
Thanks for appealing your thoughts and experiences so we can learn from them. They were so nicely put. Please continue with the work you do as it is truly enjoyed.
has just told him that hand-washing is too expensive, and he should stop doing it.”
I love iphone 4 white, and i will keep focus on it. But when will it really release, hmm let’s see.
i will keep focus on it. But when will it really release, hmm let’s see.
wow…this one is a very good source information..
Thanks for shareing! I agree with you. The artical improve me so much! I will come here frequently. iPad to Mac Transfer lets you transfer music, movie, photo, ePub, PDF, Audiobook, Podcast and TV Show from iPad to Mac or iPad to iTunes.
Indeed, the more arbitrary, complex, and ad-hoc the business rules are, the cleaner the code needs to be.
I agree with your idea, but it is not always right.
leastwise the flocks can have alternative content materials to feed thier dying minds. Perhaps its greatest off, the common men and women arn’t very sensible at any rate.
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.
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 job.
understand why the manager would think like this, and make sure s/he knows you understand don’t be too militant about it – make suggestions but don’t insist suggest a compromise – e.g. “if we hit this milestone deadline can I spend a few days over the following week refactoring such-and-such module?” get some articles on the idea of technical debt (Steve McConnell’s work is probably the best on this) and sit down with your manager – be clear that technical debt is NOT necessarily a bad thing, it’s just that a balance has to be maintained. Discuss with your boss where the right balance is. BR, Sarah Shuck, Job Consultant from resignation letter format
Unfortunately you have a single option. Resign and work somewhere else.
I realize it’s a bit simplistic. However if the whole business model of your company puts speed to market and lowest cost, over quality, it’s just the wrong sort of company for someone who takes pride in the quality of their work. BR, Sarah Shuck, Job Consultant from resignation letter format
I worked for a company in Indiana who had a similar issue, it was a coding havoc, the best thing to do is convince them to do a redesign—THE RIGHT WAY, in the long run it will pay off. If they say no, wait til it crumbles, then say “I told you so.” ;)
Buy $10 Replica Designer Sunglasses with 3-day FREE SHIPPING
interesting thanks for sharing. Social Network
Hi, I found your post really helpful. Thanks for posting such informative content. Keep posting.
good idea …
internette görüntülü olarak okey oyunu oyna, gerçek kisilerle tanis, turnuva heyecanini yasa.
Your blogs is so interesting I will read all of your article. thank you :-)
Your blogs is so interesting I will read all of your article. thank you :-)
Your blogs is so interesting I will read all of your article. thank you :-)
Your blogs is so interesting I will read all of your article. thank you :-)
gerçek kisilerle tanis, turnuva heyecanini yasa.high quality headphones new design headphones
Yes, architecture enables flexibility, maintainability, and reusability; but test suites enable architecture. Architecture is a second order effect.
Hi, I found your post really helpful. Thanks for posting such informative content. i like this post.
uk export companies
Your blogs is so interesting I will read all of your article.
Online Buyers and sellers | Online Export Import trade leads | Online importers
Cloudsourcing combines on-demand business process outsourcing (BPO) with crowdsourcing technologies to enable companies to purchase quality BPO services on-demand through a pay-per-use model.
Hello, I found your post really helpful. Thanks for posting such informative content. Keep posting.
global export import agent
global trading company
When I at first left a comment I clicked the “Notify me when new comments are added” checkbox and now each time a comment is added I get three notification emails with the same comment. Is there any way you can take away people from that service? Thanks a lot!
The essential motivation for business software is to increase profits by cutting costs or speeding the productive cycle.
The essential motivation for business software is to increase profits by cutting costs or speeding the productive cycle.
bus today, make them Cheap Beats By Dremiserable. One said: “I ??am really unlucky it! I was packed Beats By Dre Studioin the car to flow production.” One said: “I ??called Beats By Dre Soloit bad luck! In I was packed car are pregnant.Beats By Dre Pro Classic joke: I TVU A university studentbeats by dr dre caught by the enemy, the enemy tied him at the poles,just beats solo headphones purple and then asked him: say, where are you? You do not say it electrocuted! Scheap dr.dre beats studio headphones balck/yellowtudents back to the enemy a word, the result was electrocuted, he said: I am TVU.Hot sale beats by dr dre pro headphones
Very good, I like your article, continue to work hard, I will often come to pay attention!
good
@
@!!!!!Faites de votre maison un foyer avec salon de jardin, parcourir la boutique en ligne et acheter maintenant !
India Export Import Agents Success Stories: If you are looking for export of Indian imports, import export companies of goods from anywhere in the world, is a lucrative business. To be clear, there are success stories from around the world of the Indian import and export, import and export agents in Asia, USA, Australia, Europe in fact, the name of the country and is an example of success, but before entering blind in this business, you should know what to do and how to do it.
good news dude. keep it up.
bengal cats
It is true that if we want to make a great improve in programing. we need do understant the exactly mean of each conception. And we need do practice. so, why not think about doing it now.
interesting thanks for sharing
During the sessions they told me of a software manager who is famed for having said:
Thanks for the information, I’ll visit the site again to get update information action figures
Great Work. Recently i am seeking for a dofollow blog list. Thanks for sharing.
Business software is Messy and Ugly. 68 hoo,good article!!I like the post!57
Business software is Messy and Ugly. 69 good post156
Try wearing a pair of rainboots Christian Louboutin platform heels to have fashion fun with your Christian Louboutin clutch feet. There are plenty of great Christian Louboutin Ron Ron styles available and are practical Christian Louboutin peep toe too. Read on to learn more…..
When you are buying some good looking bags for yourself, one of the things that you will be watching out would be whether or not you are getting good value for your money?
yeah, sorry for my mistake for post the comment here. http://www.nfljerseyoutlet.us/
if you like the high shoes, i think you will interest this outlet. http://www.christianlouboutincher.com/
http://www.outfitscosplay.com/cosplay-accessories/haruhi-suzumiya-accessories Deluxe Haruhi Suzumiya Accessories for Sale.Find your favorite characters and cosplay outfits from all the popular anime and games.
i am really satisfied the great info. it is a very nice blog.i am agree with you for this post
This is a great post and thank you for sharing this nice blog
Wellies refer to Wellington boots which was created and made popular by the Duke of Wellington during the the late 18th and early 19th century. It was a modified christian louboutin Very Prive form of the Hessian boots worn by the cavalry soldiers as well as the public. The first wellingtons were made from calfskin leather without the trims found on louboutin christian shoes the original Hessian boots. The heels were a standard one inch and it was mid-calf high. The boots were also fitted closer to the leg than the Hessian style.