<commit_before>--- cson
title: "On bad code"
metaTitle: "On bad code"
description: "Is it ok to write bad code? Is it ok to rewrite a bad codebase?"
revised: "2012-08-11"
date: "2011-02-10"
tags: ["Quality","Notes","Rants"]
migrated: "true"
resource: "/bad-code"
summary: """
Is it ok to write bad code? 

Is it ok to rewrite a bad codebase?

The answer to these questions is harder than some developers think.
"""
---
There are plenty of software projects in the wild with low [quality][1] codebase and if you are a software developer you have written some and there is a good chance you are maintaining one.

Some of the main reasons projects end up with low quality code are: 

 - Skilled Developers knowingly write low quality code
 - Unskilled developers write low quality code

Well, there is a third reason which is not paying [technical debt][2]; but  technical debt is the result of writing bad code. 

##Skilled Developers knowingly writing low quality code
Uncle Bob [says][3]: "*No matter who. No matter what. No matter when. Short term. Long term. Any term. Writing good code is ALWAYS faster than writing bad code.*". I agree with him except for the "ALWAYS" part. In software there is no always there is no never. 

[Feasibility study][4] is (usually) undertaken by businesses before any project starts. As part of this practice the feasibility of the project is assessed against a variety of criteria and the result of this study tells the business whether they should go ahead with the project or not. Sometimes to pass the feasibility assessment some sacrifices have to be made.

Sometimes constraints, usually tight deadline and/or budget, drive you down undesirable paths. The following scenarios/exceptions are usually the reasons skilled developers knowingly write low quality software:

 - Time to market: There is an opportunity you have to seize quickly or it will be lost. Sometimes it is because the opportunity is there for a very limited time and sometimes because your competitors may saturate the market if you are not fast enough. This is where you are forced to write bad code to pass Schedule Feasibility.
 - Low budget: You have an idea that could get you a good customer base and some revenue but do not have enough financial backup to do a high quality job. You implement the software in a quick and dirty way so you can release it to market, generate some revenue and then later use some of that revenue to improve your codebase. If you do not do this you fail Financial Feasibility which if ignored results in project failure.
 - Usefulness/value uncertainty: You have a new idea and do not know if it is going to be useful or not. You have to put out your idea to assess its usefulness and receive some feedback and improve on it through [Observed Requirements][5] if it succeeds. It is as if you are releasing a working prototype into the wild to assess its Operational Feasibility!

What I would like to highlight about the above exceptions is that it make sense to write bad code in these cases only if the project is very small. For any non-trivial project I am with Uncle Bob even in the face of above constraints.

Bad code usually takes longer to write for any non-trivial task, and for a rather big task you are better off writing quality code from the start. In other words, for a non-trivial project sacrificing quality not only does not save you time or money but it also costs you more.

###Why is it ok to write bad code, and why knowingly?
You should know you are writing bad code and you should **be ready to pay the cost of writing bad code**. The cost is the interest you pay on your [technical debt][6]: "*doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice.*"

Writing bad code, if it costs less and helps gain a big benefit as explained above, is IMO worth it. It is like getting a loan to buy a house: sure you are going to pay interest on your mortgage; but perhaps if you do not get the loan and buy the house in the buyers' market, the house would cost you much more later. So yes, you lose money by getting a loan, but you make up for that loss by capital gain and make some money. "*The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline.*"

As mentioned above, though, you should know that you are writing bad code and you should try to improve it (when it makes sense). Unlike most financial debts that you have to pay as you go, technical debt payment can and unfortunately in a lot of cases is deferred, and this is a big problem: "*The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.*"

###Beware: there is a trap
How many times have you been asked to do something in much shorter time than your estimation? Usually the excuse is that there is not much time and we should get it out of the door ASAP. In my experience a lot of such rushes are not based on real business needs; but rather an irrational desire to have the product faster.

How many times have you put a quick and dirty application together as a PoC and you have maintained it in production for years!?<commit_msg>linking from bad-code to not-judging post<commit_after>--- cson
title: "On bad code"
metaTitle: "On bad code"
description: "Is it ok to write bad code? Is it ok to rewrite a bad codebase?"
revised: "2012-08-11"
date: "2011-02-10"
tags: ["Quality","Notes","Rants"]
migrated: "true"
resource: "/bad-code"
summary: """
Is it ok to write bad code? 

Is it ok to rewrite a bad codebase?

The answer to these questions is harder than some developers think.
"""
---
There are plenty of software projects in the wild with low [quality][1] codebase and if you are a software developer you have written some and there is a good chance you are maintaining one.

Some of the reasons projects end up with low quality code are: 

 - Skilled Developers knowingly write low quality code
 - Unskilled developers write low quality code

I have talked about some of the other reasons [here](/never-judge-a-programmer-by-their-commit-history).

##Skilled Developers knowingly writing low quality code
Uncle Bob [says][3]: "*No matter who. No matter what. No matter when. Short term. Long term. Any term. Writing good code is ALWAYS faster than writing bad code.*". I agree with him except for the "ALWAYS" part. In software there is no always there is no never. 

[Feasibility study][4] is (usually) undertaken by businesses before any project starts. As part of this practice the feasibility of the project is assessed against a variety of criteria and the result of this study tells the business whether they should go ahead with the project or not. Sometimes to pass the feasibility assessment some sacrifices have to be made.

Sometimes constraints, usually tight deadline and/or budget, drive you down undesirable paths. The following scenarios/exceptions are usually the reasons skilled developers knowingly write low quality software:

 - Time to market: There is an opportunity you have to seize quickly or it will be lost. Sometimes it is because the opportunity is there for a very limited time and sometimes because your competitors may saturate the market if you are not fast enough. This is where you are forced to write bad code to pass Schedule Feasibility.
 - Low budget: You have an idea that could get you a good customer base and some revenue but do not have enough financial backup to do a high quality job. You implement the software in a quick and dirty way so you can release it to market, generate some revenue and then later use some of that revenue to improve your codebase. If you do not do this you fail Financial Feasibility which if ignored results in project failure.
 - Usefulness/value uncertainty: You have a new idea and do not know if it is going to be useful or not. You have to put out your idea to assess its usefulness and receive some feedback and improve on it through [Observed Requirements][5] if it succeeds. It is as if you are releasing a working prototype into the wild to assess its Operational Feasibility!

What I would like to highlight about the above exceptions is that it make sense to write bad code in these cases only if the project is very small. For any non-trivial project I am with Uncle Bob even in the face of above constraints.

Bad code usually takes longer to write for any non-trivial task, and for a rather big task you are better off writing quality code from the start. In other words, for a non-trivial project sacrificing quality not only does not save you time or money but it also costs you more.

###Why is it ok to write bad code, and why knowingly?
You should know you are writing bad code and you should **be ready to pay the cost of writing bad code**. The cost is the interest you pay on your [technical debt][6]: "*doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice.*"

Writing bad code, if it costs less and helps gain a big benefit as explained above, is IMO worth it. It is like getting a loan to buy a house: sure you are going to pay interest on your mortgage; but perhaps if you do not get the loan and buy the house in the buyers' market, the house would cost you much more later. So yes, you lose money by getting a loan, but you make up for that loss by capital gain and make some money. "*The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline.*"

As mentioned above, though, you should know that you are writing bad code and you should try to improve it (when it makes sense). Unlike most financial debts that you have to pay as you go, technical debt payment can and unfortunately in a lot of cases is deferred, and this is a big problem: "*The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.*"

###Beware: there is a trap
How many times have you been asked to do something in much shorter time than your estimation? Usually the excuse is that there is not much time and we should get it out of the door ASAP. In my experience a lot of such rushes are not based on real business needs; but rather an irrational desire to have the product faster.

How many times have you put a quick and dirty application together as a PoC and you have maintained it in production for years!?
{'fraction_non_alphanumeric': 0.037456523677873894, 'fraction_numerical': 0.003834834567020423, 'mean_word_length': 4.194071329319129, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 4, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3863142', 'n_tokens_mistral': 2640, 'n_tokens_neox': 2534, 'n_words': 1955}