Persuading the business that fundamental design flaws are worth fixing

Question

This is the second project I've worked on where an incorrect assumption has been made in the design of the software. In both cases it has resulted in a solution that is:

• More likely to get bugs related to the flaw
• More messy to work with as workarounds are implemented to get around it
• Harder to understand as the assumption does not match reality

Every time I run into these flaws, a little piece of me quietly dies. However as both projects have been built upon this foundation, it would be time consuming to fix so that the software behaves the same yet doesn't cause this pain.

As far as the business is concerned, they wouldn't see a change in functionality. In fact, if this was fixed there would no doubt be new bugs introduced initially. The payoff of a less error-prone product that is quicker to develop for with happier people working on it wouldn't be until the longer term.

Does anyone have advice on how best to proceed?

Answer 1

Unless you can show it will save them money, or earn them more you don't have a business case.

Show them (in financial terms of shorter-lead times, reduced complexity, increased stablity) what the positive implications of the fixes are, and you have a business case to argue. If it is a wise investment and they don't go for it ... their business, their decision.

You can also argue:

1. Increased efficiency
2. Better 'fit' between development and other business components
3. Increase in competitive position
4. Increase in overall value

Persuasion in numbers is needed I reckon!

Answer 2

Live with it until some new feature-requests that could be better served by a better design come around, and lobby hard to include the redesign as part of work on those new features.

Or, just live with it realizing that almost every system has such design flaws (though some are worse than others!)

Answer 3

Every time I run into these flaws, a little piece of me quietly dies

the longer you program, the more of this you will see. Pick your battles, you can't fix everything, life is too short. Pushing for this could drastically alter your career at that employer. Make sure that you are not complaining about the poor design to the guy (your boss) that wrote that code!

Answer 4

A good solution to this would be to introduce process BEFORE the design stage - if possible, create a new "technical solution appraisal" stage (or any other suitably high brow projspeak style name!) which sits after requirements and ensures multiple sets of eyes review the technical solution's feasibility before any design or implementation.

Answer 5

Martin Fowler on Technical Debt is at least slightly related, and googling that term gets you an amount of material which should be useful.

I think the key idea is that you have to be able to express what you see as the facts in either actual monetary terms, or at least use monetary analogies / metaphors, in order to get business-types to buy in.

Answer 6

You need to illustrate to the "higher ups" that the ROI is significantly decreased (or in the negative).

There are a number of options you have to illustrate this:

1. Track the technical debt in terms of hours. The next time you are required to go back into the system and fix something because of the issues you've described, track how much time it took you to accomplish the task. Also, track any testing time spent, QA time spent, design time, etc. It's not enough to only track your involvement, you have to track hours from everyone involved.
2. Estimate the effort that would be saved by doing it the correct way. This goes hand in hand with tracking your technical debt, since you should be able to compare the two metrics to calculate your ROI.
3. For defects that make it into production, calculate the cost to the company that the defect had on the system. This can be a little complicated, since there are fuzzy factors involved with this (reputation, integrity, consumer confidence, etc). However, a complete loss of a client should be shown as a complete revenue loss, in addition to time spent with the client to resolve the defect from all parties involved. Once you have a general formula for calculating production defects, you'll find that production defects are by far the most costly to the company. Preventing such defects should be a high priority, so if the concerns you listed above are a cause for defects getting into production, that helps your case.

Once you have all your metrics in terms of hours, you can easily convert them into $$$ figures for them if they can't do that work themselves. The point here is that you've now quantified your statement. You've given them something concrete that they can work with.

Answer 7

You need to prove that your assumptions regarding the software's scalability / maintainability will convert into actual costs for the business, and that you aren't talking about a best practice / perfect product from a perfectionist programming perspective. The "bottom-line" is everything; if you can show that your improvements will save the business money (most likely by reducing wasted man-hours combating a hacky piece of software) then your bosses will have a hard time disagreeing. A few points;

• More likely to get bugs related to the flaw

More likely to or will actually happen? If it's only more likely to, then who cares? No-one will lose money on a potential situation that doesn't happen. Prove that it's more of a probabilty than a possibility though, and you've got a case.

• More messy to work with as workarounds are implemented to get around it

Have workarounds actually been necessary? Again, if we're only talking "possible" not "probable", it's a moot point. If so, how long have they taken? How much have these hacks reduced the scalability and maintainability of the product?

• Harder to understand as the assumption does not match reality

Not sure what is meant here.

Also, try pointing your bosses towards Joel Spolsky's blog; http://www.joelonsoftware.com/ He often discusses issues like this.

Answer 8

A few more links about Technical Debt that may help in your argument for fixing the design:

• Refinance Your Technical Debt Just Like Your Mortgage
• Accounting for Technical Debt
• Technical Debt - 10x Software Development

Answer 9

I think you really only have two choices:

1. Provide experience based, empirical evidence that enhancement or maintenance of the system is significantly longer and more expensive, than if these fundamental problems are addressed. You will then need to project the long-term cost of maintenance of the current implementation vs. if you address what you consider fundamental design flaws. This can be a very challenging route, because it's often hard to convince management that your estimates for the work in a future design will really be less. Before you decide to place your credibility on the line, you should really do the due diligence to convince yourself that there will actually be a net benefit to the business by refactoring/rewriting a system that does work - even if it is not the most elegant in the world. Keep in mind that management generally think in terms of a dollar cost and benefit. You have to be able to communicate with them in their language, not yours. Management does not, generally, have a technical background and technical arguments are unlikely to sway them. You can certainly try using metaphors like Technical Debt, but you are still going to have to provide credible evidence that there will be a real, net benefit in terms of cost (or opportunity cost) to the business.

2. During the course of normal maintenance, gradually refactor the existing implementation, piecemeal, towards the better architecture. This is a much slower route, and may ultimately take longer and consume more effort than a "big bang" refactoring. However, it has the benefit that there's less justification that you need to make, you don't run the risk of a big project getting canceled, and you leave the system in an acceptable state with each iteration. It may also be more practical for the business because each refactoring cycle also deliver business value to the users of your system.

If you plan to go with the first option, here are some examples of "evidence" you may want to try to collect and incorporate into your business case for refactoring the system:

• Based on existing projections, maintenance cost for the system over five years will be $XXX dollars. After expending $YYY dollars to resolve fundamental system issues, we project that the five-year maintenance cost will be reduced to $ZZZ.
• Implementing feature X is currently planned to take QQQ man months and estimated to cost $YYY. After refactoring the same functionality is estimated to take PPP months and cost $ZZZ.
• The system currently requires X full time staff to provide baseline support (e.g. keep the lights on), after refactoring we expect to be able to operate with Y staff, resulting in a savings of $ZZZ over 5 years.

Answer 10

There are really two issues here: convincing those who make the decisions that the fix needs to be made and constructing an environment in which continual improvement without regression is actually possible. If you have an environment using unit testing, integration testing, continuous integration, etc. then the convincing part takes less effort. At least you can have more assurance that you won't be introducing new bugs by refactoring the design, overcoming that argument against making the change. Often such an environment goes hand-in-hand with an expectation of continually refactoring the design to improve it.

While the concept of Technical Debt can be very useful in explaining why continual design improvement is actually good for the company, it won't be sufficient to argue for a particular refactoring. For a specific refactoring I, too, think that you'll need to marshal your arguments with some numbers or, at least, technical reasons why the design needs to be improved. Keep track of the difficulties introduced by the design as you encounter them: bugs, workarounds, etc. If your evidence is speculation or anecdotal, you'll need to have it recognized as a general problem by a large part of the team. It might also be easier if you can suggest an incremental strategy to making the design improvement so that it doesn't bring new development to a halt.

Good luck.

Answer 11

"Every time I run into these flaws, a little piece of me quietly dies."

Look, you need to just grow up. I'm a hiring manager who hires programmers, and I tend to shy away from people who get emotional about these things, regardless of how good they are. They just tend to be a pain in my butt, griping all the time about "bad" design and wanting to spend my limited budget going down rat holes. Every piece of software has design flaws, we would all go broke if we spent our time and money always chasing the "perfect" design.

The bottom line is this - if the software is currently functioning reasonably well, the only way you're going to get the bosses to agree to pay for modernization of the software is to add new features that are useful to the customer base. It's a very tough sell to say "make a significant investment now and that might provide O&M savings down the line." Sorry, that's just the way it is.

Answer 12

I'm interested to know why people expect perfect systems all the time.

Systems evolve through lots of changes over a period of time.

The more evolutions you have, the better.

You only have to look at the mobile phone market to see that companies who realised their design flaws, fixed them, then moved on are still contenders.

Why should the business care about what's under the hood. Do you honestly worry about whether the engineers went with widget X instead of widget Y when you're driving round? So why should they care?

Unless the 'flaw' might cause a system failure leading to loss of revenue, then the business will not be interested. They are always too short sighted to see 'time gained', but they will always notice 'revenue lost'.