I am sure you all know this issue: There are situations where you have to implement something in a quick & dirty manner. You know that this way of implementation is wrong. And you be afraid of or maybe know for sure that this quick & dirty implementation will never be refactored and will life forever. But why do we have this issue in so many projects? Of course there is no easy answer to this question. But one of the reasons may be a lack of understanding of the consequences and costs of quick & dirty implementations. Within this article I want to open your mind for this topic and show you a way to communicate this issue in a proper way to your project owner.

What is Quick & Dirty?

At first we have to understand the term “quick & dirty”. So let’s look at an example:

A Release date is near but some features are still not finished and cannot be finished within the given timeline. This can be a planned release which gets late and it is not possible to change timelines because this will create huge costs (penalty or customers get lost to competitors). Or it may be an unplanned release for example to immediately fix a critical bug.

If a release cannot be done as planned you always have different criteria’s to change. Typically these are:

• Timeline
• Effort (Manpower)
• Features
• Quality

In case of quick & dirty releases we speak about forthcoming releases which are planned in near future and cannot be shifted. Therefore the criteria “Timeline” is fixed. Furthermore the criteria “Effort (Manpower)” is also fixed. You cannot add more people. Please remember the well-known maxim: „Put people in a late project will make it even later.“ You can also not change the “Feature” criteria. In our example we need the features to go to the market or in the bugfix example we have to implement the fixes (features).

Therefore we can change the criteria “Quality” only. Quality, in this case, does not mean testing. See the following article for an explanation why. Quality from user point of view means: reliability, usability and efficiency. And quality from product owner point of view means: changeability, transferability, maintenance, flexibility. In most cases the product owner is not willing to reduce the quality on user level. And therefore the only remaining criteria is quality on product owner level. And that means: code quality.

In summary, if we speak about a “quick & dirty” release we speak about a reduction of code quality.

Why is it difficult to see the consequences?

Let’s come back to our initial question: Why is it so difficult to understand the consequences and costs of quick & dirty implementations? I think there are two main issues: technical speech and lack of concrete numbers.

A typical attempt of a software developer to explain the disadvantages of a quick & dirty release to a manager will be something like this: “If we do the quick & dirty implementation we will reduce the code quality. Therefore we have to refactor the source code in future”.

Within this statement, there are two main issues. At first, management will not know what the technical term “Refactoring” means. And second, management needs numbers to see the benefits and costs.

What will management decide?

If the software developer describes the meaning and consequences of the quick & dirty release like shown above, the manager will get the following information:

• It is possible to implement the release within the given timeline
• We do not need any additional manpower
• All features will be implemented
• Code quality will be reduced
• Refactoring is necessary in future

In summary the management will see the concrete benefit (the software release). This benefit is measurable. And the management will hear about some vague disadvantages which are not measurable. And in this case the decision is very easy: The quick & dirty release has to be done and such vague things like refactoring will be ignored. As a result, if you have to implement the next release and tell the management you need more time than normal because of the refactoring, you may risk that everyone is surprised and you cannot get additional time. A loop of some quick & dirty releases will start and topics like refactoring will be pushed further and further into the future.

How to escape from the quick & dirty path?

If you want to prevent such a very frustrating sequence of several quick & dirty releases, you have to show the consequences in a measurable manner. So at first, management needs to understand what it means to reduce code quality and what it means to do refactoring. And at second, you have to show the management concrete numbers. You have to show the costs of the refactoring and therefore the cost increase for the next release. And most important: You have to show the cost increase of the next release in case the refactoring will not be done. That’s the most important part because (in my opinion) refactoring is often refused as management will not see any benefit as result of this refactoring.

Explain what it means to reduce code quality

Sometimes it is helpful to illustrate a technical topic by an example based on daily life situations. If your project owner or some managers will not understand such technical terms like code quality or refactoring you have to use another way to explain this topic.

You may compare this topic to borrowing money. The current available time to implement the release is not sufficient. So you have to get additional time for feature development. A reduction of the code quality will allow you to borrow this time. You borrow it from yourself as it must be paid back somewhere in the future in a next release. Therefore, implementing a quick & dirty release is like taking a credit. The credit will help you to pay the actual bills. But in future your financial situation will get even worse. In the next period you also have to pay the bills and additional you have to pay the tax for the credit. And of course somewhere in the future you have to pay back the credits itself. Maybe you have to take a second or third credit. In the worst case you will go bankrupt with this procedure.

A quick & dirty release has the same consequences. You will borrow implementation time. Within the next release you have to pay the tax, so the effort to spend for the next release will get higher. Maybe this can be compensated by a next quick & dirty release. At some point in the future you may not be able to work off the accumulated time liabilities and your project will die.

Show concrete numbers

As explained previously you have to replace the abstract concept of refactoring and code quality by concrete numbers. A quick & dirty release will influence the costs of the actual release and the next release(s). Therefore you have to respect these costs in both effort estimations.

Let’s say we start with a good code quality and therefore we do not have open refactoring needs. In this case you will create a standard effort estimation for the release and show it to the product owner. For example the release will cost 50 days of effort. With the actual available resources it may not be possible to spend this effort in the given timeline. So the product owner asks if it is possible to create a quick & dirty release and whether this will save enough time to keep the timelines.

In this case you have to adapt your effort estimation. At first you have to estimate the time reduction for the feature implementation. Let’s say we will save 10 days of effort. At second, you have to estimate the consequences for the next release. And unfortunately this step is not done in most project estimations and will create the trouble in projects with quick & dirty releases.

To reduce this possible trouble, your estimation shall already contain the future consequences. Therefore you have to add the following two values: the costs to repair the code and a cost factor if new features have to be implemented on the bad code base. The first value may be easy to estimate. For example the quick & dirty way has saved 10 days of implementation but a lot of workarounds where implemented. To remove this workarounds and implement the features in a proper way it may be necessary to spend 15 days effort. So the costs to repair the code are 15 days. The second value, the cost increase factor, shall be shown as percentage. This value isn’t easy to estimate. But you have the same issue with the standard effort estimation which is not easy too. The quality of effort estimations depends on experiences. The quality of the estimation of the cost increase factor also depends on experiences and may be more or less accurate. But this factor contains a very important message for the product owner. For example in our case we estimated a cost increase factor of 10%. That means, as a result of the quick & dirty release we have a bad code quality and therefore all future features will need 10% additional effort for implementation.

In summary our example estimation will show the following information.

• The features can be implemented with 50 days of effort
• Effort can be reduced by 10 days if we do a quick & dirty implementation
• To repair the quick & dirty implementation in future will cost 15 days of effort
• If we do not repair the quick & dirty implementation all future implementations will need 10% more effort

Based on these numbers the product owner is now able to compare the cost of a late release to the cost of an in time but quick & dirty release.

As mentioned at the beginning of this paragraph you also have to adapt the time estimation of the next release(s). Let’s say we have implemented our quick & dirty release shown above. And now it is time for the next release. You will start as usual and do a time estimation for the implementation of the features. This time estimation must now be done based on a normal code quality. So do not pay attention to the bad code quality created within the previous release. Do the estimation with respect to a good code quality.

For example you will estimate an effort of 100 days. Now you have to transfer the number from the last estimation to the actual one. So you have to increase the total effort by the cost increase factor. This factor of 10% will now put additional effort to the estimation. And of course you have to show the costs to repair the code base, which was 15 days. Furthermore you have to think whether the two numbers will be changed if the new features were implemented based on the bad code base. This may result in a higher cost increase factor and higher cost to repair the code base. In our example the new features are strongly connected with the bad code base and could also not be implemented in a clean way. By implementing the new features we well add new bad code. So we estimate a new cost increase factor of 15% and the cost to repair the code base will increase to 20 days.

In summary the estimation will contain the following information.

• The normal effort to implement the features is 100 days
• The bad code quality will increase the effort by 10% (10 days)
• If we repair the code we have to spend 15 days
• If we repair the code the cost increase factor for the actual release and the next release will be decreased to 0% and so it will be removed
• If we do not repair the quick & dirty implementation the cost increase factor of future releases is increased to 15% and the costs to repair the code will grow to 20 days

Based on this estimation the product owner is able to see the pros and cons of the different possibilities. As this information is shown based on concreate numbers he is able to calculate the benefits and costs of the different possibilities and select the one with the highest business value.

Summary

As developer or project leader you don’t like quick & dirty releases. But they will happen. If they are rarely than the consequences are small. But unfortunately in some projects there are regularly quick & dirty releases. And in these projects the problems and unhappiness will noticeable increase over time. A root cause of this issue may be that the project owner does not know the consequences of quick & dirty releases. Therefore it is very important to show these consequences before you start with the implementation. This can be done within the time estimation. The time estimation should show the consequences of the quick & dirty release in concrete numbers. This will allow the project owner to compare the benefits and costs of quick & dirty releases. As a result they may be done rarely as the product owner will now see how expensive they are.