Clean Development Series: Part 1, Dirty Code (cause/effect)

Lately I have been talking about clean application development, and how developers can do a better job of it.  Due to the strong focus on this I decided to write some content from my latest talks into a series of blog posts.  Enabling everyone to reap the benefits of the subject matter, and allow attendees of my talks to refresh the content covered at one of the events I spoke at.

Whether we’re experienced developers or newcomers, we’ve all seen code that could/should have been done better.  Many times it’s even code we ourselves wrote and revisited later for one reason or another.  I, for one, have seen my share of code written by a “past me” and wondered what on earth I was thinking when I wrote that.  Of course there has also been times I was hired to fix another developers code, and it can be scary too.

Side effects of dirty code

• Time waster – The more dirty code we have, the longer it takes us to code.  Have you ever noticed that most of our time coding is spent reading code in other parts of our application?  This means that if we spend extra time sifting through dirty code, it takes us longer to actually write new code.
• Breeds more dirty code – Also, we tend to care less about our code if we know there is already dirty code in the application.  This causes us to write more dirty code, because who will notice in any way?
• Causes bugs – It’s a fact that dirty code causes bugs. (See a future section “How to spot dirty code” for more clarity.)  When we lose track of what our application is doing, and have trouble spotting problems, it simply leads to more problems.
• Excessive debugging – I often ask my audience if they are good at debugging, and usually end up with a strong showing of hands from developers who feel they are good at debugging.  But if they wrote clean code doesn’t it make sense that they would need less debugging experience, and therefore would NOT be good at it?
• Procrastination – We all do it.  We dread working with dirty code so much that we avoid it.  We make excuses to tell our customers, and we find other “more important” things that need to be done first.  I have even witnessed developers actually hiding from customers and taking on other projects to avoid a really bad codebase.
• Technical debt – This is the most dangerous effect of dirty code. Think of this as buying things on credit.  As you buy more and more the credit line grows and grows.  At some point a choice needs to be made.  Either you need to pay it off, or you go bankrupt.  With applications this means you either fix the dirty code, or go through the added expense of a rewrite.
• Financial loss – If your application has even a little bit of technical debt it causes development to slow down more and more over time.  If development slows down it can lead to your competition developing new features and applications faster than you can.  This is especially true if your application becomes stagnant and others continue to build.  A customer base can be very fickle and will leave surprisingly fast.
• Company killer – In today’s lightning fast market place it is not hard to see how the above events can quickly kill a company.  Remember when MySpace was big?  I am sure we can all think of others.

Causes of dirty code (the perfect storm)

• Too easy – Although it is easier in the long run to write clean code, we have all fallen into temptation to write dirty code to get something done quickly.  It is very easy to be drawn in.
• Short deadlines – Customers are often a developers worst enemy.  They are demanding, and salespeople have been known to over-promise on new functionality and short time-lines to meet that demand.  This places a development staff under tremendous pressure to meet those promises, and it is usually the code that suffers.
• Laziness – Yes, unfortunately there are times when we all get lazy. (Some more than others.)  I won’t dwell here.
• Lack of “how-to” – A brief look at code we’ve written in the past is a great way to see how far we have advanced.  As a consultant I often receive requests from customers to enhance applications I have built in the past, and I get plenty of opportunities to marvel at past coding methods I used when I didn’t know any better.  No matter how far I come, or how much I learn, this still holds true on a regular basis.
• Coupling – Many will recognize the term “coupling” and realize we are talking about OOP.  This is a method of helping use stay DRY (don’t repeat yourself) and making code reusable.  So, why is it bad?  That question is far too large to cover in this post, so I will make a note to cover it more later, but tight coupling is bad and loose coupling is good.  Feel free to search on your own to see what I mean.
• Impatient boss – It never fails, even if we still have plenty of time left on our project deadlines we still hear the dreaded “Is it done yet?” from business. It’s their job to ask, so don’t let it burn into you.  The faster they get it, the faster they can sell it.  But it leads to dirty code as developers strive to please.
• Bored of same ol’ app – Most large applications take 6 months or longer to build, and this can lead to some long periods of working on the same module or functionality.  Eventually developers can tend to get bored, and will try to get things finished quickly for an opportunity to work on something new and exciting.
• Intend to return for clean-up later – While in a rush to meet deadlines or to move on to more exciting tasks it is common for developers to complete things in a dirty manner with the intention of returning in the future to clean up and refactor.  Usually this never happens due to new projects and more deadlines, causing the old mess to be forgotten.

As you can see from this first post in the series, dirty code is dangerously easy to create and can carry disastrous outcomes.  I hope this post helps some to spot these pitfalls a bit easier, and make it easier to avoid them.  Please return for future installments as I attempt to highlight more areas to help us all perform clean development, and write better applications.