Thoughts on clean code

Back in high school I was taught Pascal. It was a really nice way of learning concepts, basics, programming structures in general. As time went by, I discovered Delphi. Now, Delphi (for those who don’t know) is an object oriented language, based on a Pascal-like syntax. And I was like “wow, I can write applications for Windows, but I’m still doing Pascal”.

So I started writing an application which would be capable of managing a rather small sized library. It had pretty good support for registering books, users, borrowing and returning books, everything you’d expect from an app of this kind. It was good enough that my high school actually started using it on a day-by-day basis. However, and you might have guessed by now, I had no idea of object orientation at that time. For me, Delphi was some sort of Pascal with these strange class and public keywords (I did not care about encapsulation and other good stuff, of course) where my applications were running in a cool window. All the logic was coded inside forms. All the forms had one or two event handling methods with all the business logic in them. Not a future proof design, after all.

It wasn’t long until I had some change requests from our librarian. Those requests really gave me hell. Although I had written all the code, I was struggling when I had to change something. Once I got this request that the system should support databases… The whole app was based on files – users, books, borrowed books; every little functionality was about manipulating text files. I failed to change it, due to the huge amount of spaghetti code I’ve created.

When I first learned about clean code, the story above instantly came into my mind. Back than, I thought this was the difference maker between little kids messing around with programming and real engineers. By now, I’ve realized how wrong I was.

Usually there are only two cases: you either create applications for the enterprise or consumer market.

In the first case, it does NOT matter whether you do all these cool things like TDD, clean code, nice development processes etc. It does not matter, because the end users don’t use the product because they want to use it. They use it because two CTOs play golf together and they decide it would be a nice cooperation between the two companies. In this case it doesn’t matter how ugly spaghetti-code you write. The contract is signed, it will stay signed usually for 5-10 years. You keep coding awful bugs? It does not matter how long it takes to fix them, because of the safety of the agreement. The release of a new version takes awfully much time? No problem, there are only 2-4 releases per year anyways.  Of course you can (and should) do all these best practices (after all it is good for the soul) but you are not “required” to do it; as it just does not make any difference in terms of product success. Therefore one should not be angry with anyone who’s not producing code of good quality.

For consumer applications, however, the thing is the other way around. People vote for applications with their visits, time and/or wallet. If you create disgusting spaghetti code, that will take its toll over time. Bugs will take more time to get fixed, release cycle will get longer and longer and that is the point when people start using another application, service or game. Because they simply can. In my opinion, this is the only place where one’s clean code can make any sort of difference.

Advertisements

Author: tamasgyorfi

Senior software engineer, certified enterprise architect and certified Scrum master. Feel free to connect on Twitter: @tamasgyorfi

3 thoughts on “Thoughts on clean code”

  1. The difference you mentinoned lies in the trackability of the consequences. When the consequences of unmaintainable implementation can be tracked (and transformed into billable manhours of work) those guys in the golf club will have a topic to speak about 😛

    The question is: how to track such things? Maybe a post could cover this 😉

  2. The best I can come up with now is to track ‘rewrite component X from scratch’ and ‘It took Y days to understand what the code does before I dared to write/delete 1 (10, 100) line(s) of code’ tasks. Note that there is no excuse for the latter even when a newbie solves a task if that newbie is already counted as a member of the team in planning.
    Any hours spent on rewriting a component after throwing it out completely and all hours spent on ‘learning’ unreadable code’s behavior can be counted as study instead of development. So one can learn how much a team ‘studies’ instead of ‘produce’ from such tracking. And these ‘study costs’ cumulate bottom-up in a large R&D unit making it interesting for golf club members too.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s