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.