How to write bad software (source code)

When it comes to software development there are many ways to write software, luckily there are many well designed and documented framework and/or patterns that help professional software developers to write “good software”, however everybody knows that we don’t live in a perfect world, there is a reason for the existence of such patterns or frameworks, or the fact that there is a profession  for software development.  Not every body can write “good” software and I have been thinking a lot about dumping my thoughts  in a blog post about how to write “good” software, but it would be more appropriate to  first have a good introduction about “bad” software and how to write bad software and why people still write “bad” software.

First of all, let me be clear, for the context of this blog post I’ll be talking about software purely looking at source code and how it is organized and structured, as opposed to what is the final product or what things does it enable the end user to do. Thinking in terms of source code not features/experiences for end users. In other words I’ll be referring to software from the developer’s mind, purely source code, in a way is more like how to write “bad source code” instead of “good source code”

I’ve worked in quite a few companies, and my most fun experiences have been while being a consultant mainly because when you are a consultant you work a project for a short of somewhat finite amount of time, you learn a lot, meet all kinds of interest people and move on to the next project to do it all over again, to gain new knowledge and improve your skills, becoming more valuable and experienced with every project you complete, while keeping your skills fresh and diverse.

Throughout the years I have notice people in the software development industry can definitely recognize “bad” code when they see it, which is about 95% of the software development community (I am being optimistic) and once they see it, recognize it and acknowledge it is because they have enough proof to explain you what is wrong with the code, they know exactly after they see it or analyze it why is wrong and/or why the particular code is “bad”, this might vary by developer, some developers would be more pragmatic and neutral, some will dissect the source code to the last drop and tell you what is a piece of crap. The idea here is that most software developers can and will raise their opinion why a particular piece of code is “bad” or “good”. Most people will raise the bad part more often than the good part because it is easier to see.

Well it turns out that stating that a piece of code is “bad” or “good” is a very subjective topic. By looking at source code along and how it is architected can lead to very subjecting opinions for any one person looking at the code, and that is very easy to do. Most people when criticizing a piece of software a “bad” they are probably doing so because they had to look at the code, which in most cases is because they inherited and need to change or add something or perhaps just consume it.

But it is unfair to deem something as “bad” before looking into all the possible sources of context around the piece of code, for example documentation, design documents, specification documents, budged, scheduling and resources, etc. All these piece help put the together the puzzle of how this source code came to be and giving developers better information about why the code might have been structured that way.

I mention earlier that most developers will say that a particular source code is “bad” and in my experience is for the following reasons ordered by the most frequent

  1. The source code is hard to read and understand
  2. The source code makes it difficult to modify or add functionality (hard to maintain)
  3. The source code ignores many common patterns/practices used in the professional industry of software development.

Some people might argue that just because #1 exists by itself, does not means the code is “bad” however I argue that good code should be easy to read and understand (self explanatory) otherwise is bad.

Now that we have seen the most common reason why a source code can be doomed as “bad” lets look at possible causes:

  • Problem: The source code is hard to read and understand
    • Causes:
      • Over engineering
      • Bad design, wrong design
      • Lack of knowledge about problem domain
  • Problem: The source code makes it difficult to modify or add functionality
    • Causes:
      • Tight coupling
      • Forgetting to design for extensibility
  • Problem: The source code ignores many common patterns/practices used in the professional industry of software development
    • Causes:
      • Inexperienced developers
      • Very tight deadlines can lead to “shortcuts”

You most always remember that when writing code, code reviews will be very subjective and very likely your peers won’t label it as “bad” software even if they think it is, so if you want to find out if the code you write is “bad” the best measurement is to give it to another developers (preferable not on your team) and ask them to review it, they might tell you if indeed is bad or not, but this can only cover factors 1 and 3 since the person very likely will not be modifying or maintaining the code, so the best measurement to see if you code is actually good is to give it to someone that will be maintaining the code and then asking for they opinion.

I’ve enumerated the 3 most common factors of why software (source code) can be classified as “bad” as well as some of most common causes that contribute to creating a “bad” piece of source code. This information can you give a hint about future topics I’ll be discussing around writing “good” source code, and the qualities that make a source code, “good”.

It helps to know how bad/ugly/unmaintainable code gets written and why, in order to understand what it takes to write good source code, there are some developers who have actually learned how to write really good source code, but it came with years of practice in the software development industry. You can speed up your “good source code” writing skills by learning a very basic principle that should be applied correctly when designing software but I’ll leave that for the next blog post.

How do you know when software (source code) is bad?

Next Post »