How can you maintain the balance between the two forces. Clean coding and quick and dirty coding. These two terms seem to not be friends at all. In experience it is either the task gets done or its gets done clean eventually. Is there an actually balance? If there was, how would you know it. In this article I attempt to outline the difference between clean and done coding and argue that a balance can be struct however there are caveats. Lets begin!
Clean implies dirty
In order for your code to get clean it means it must have been dirty at some point. Lets be honest. No matter how good you think you are we all most likely started with some very dirty scripts. Or maybe its just me. While I have a lot of experience in programming I am still pretty new to it. Some of my earliest examples of coding – not counting primary school Q Basic of course – is with android programming. I really enjoyed programming in android. It was like I was a creator creating my own little world where I dictate all the rules. Is that how all programmers feel? The android application wasn’t even a game it was a simple utility (generous) app. For some reason I’ve never been able to build games I truly admire developers than can do this however. Its probably too creative for me to deal with and has an extremely steep learning curve. Back to my utility app that I was so proud of and showed to all of my friends. I think I still have screen shots. Don’t laugh this is my first time. I treasure it.
So this was my first app that I was so proud of for some reason. The idea behind it is completely ridiculous. Igest as it was named allows users to suggest ideas. That’s it. A cross between Ideas and Suggestions. Isn’t that funny. That’s the entire premise of the application. I thought this would net me millions because it was such a uniquely presented idea. My school instructor problem concluded I was crazy. I digress.
I don’t have the source code for this application but the application I built after was called iQuote. The premise was to share quotes to users. Another basic idea but I thought it had tremendous potential. Frankly it was a pretty cool app, eventually after many iterations. I do have the code for this and if I recall it was an absolute mess. When I returned to building android applications natively I was quite surprised how much structure Android has. Well, because I didn’t know what I was doing before but the messy application worked and worked very well. Very few errors and bugs and since security wasn’t a real issue it was all fine.
This is really the problem. If you could do something with minimal structure and it works fine why change at all. If it ain’t broke don’t fix it. Admittedly this is extremely true. In a perfect world you would never need to worry about clean coding. You can focus on just getting the job done and then you can go home or wherever.
Changes are a constant
That attitude works well for school projects and personal projects. For school getting it done is all that really matters. For personal projects you set you’re own deadlines and so things are prefect. Where does it all go wrong then.
That first application you built for your supervisor, boss, manager and colleagues. You did it with little supervision based on the requirements suggested to you and built on how you interpreted them. You do a Power Point presentation to explain the basics and then you enter the demo and everything falls apart. The first screen a hand goes up.
Why don’t you do it like this?
You politely explain and you head to the next screen. Another hand goes up this time “suggesting” how it should be done differently. For a noob this is sort of a disaster. Its like asking God to make a lion into a dolphin. You’re thinking I spent hours upon hours designing this perfect world how dare you criticize even an inch of it. You non-technical suit who have no understanding of my world how dare you give your suggestion. A typical technical persons response to all these questions is saying it can’t be done any other way but any good manager knows this so they will not take the word can’t too seriously from the technical folk. They assume that we are often overthinking and to be fair this is often quite true.
Anyway this scenario keeps happening. Over and over again. Changes for evermore. Eventually if you are as smart as you think you are you realize this method of working is incorrect and inefficient. Project managers might cry foul because these changes are out of scope but I think software development requires some leeway in this regard.
How then do you solve this problem so as to benefit both the developers, the suits and end users kinda. One solution is to get management to see software development from a programmers perspective but I think it might be easier to win the lottery than this occurring. Another solution is to stick very strictly to a scope and project requirements documentation. This tends to leave you with very unhappy end users but management is usually happy with this solution and most developers would tolerate this outcome. End users are never happy right? Another solution and the one I suggest is structure. Structure is what coding cleanly is mostly about to me. This will soothe most parties and you the developer could be proud of our own work as well.
A structured house is easy to clean
When you’re code has structure you laugh at changes.
Can this be done. Sure?
I would like to make this change? No problem.
In an effort to enjoy programming again I had to figure out how to deal with the insane amount of changes that are often thrown at you. I’ve heard programmers should learn to say no but I’m sure you wouldn’t like to hear that word from your mechanic. Not unless you are about to blow up the car. If its feasible get it done is how I see it. No is too easy. Takes no effort. Just pace yourself that is important.
I’m not sure I have the skill to explain structured programming since one, programming in itself is already structured so it might seem ridiculous that more structure is required. The way I view it however is that I rarely get too close to the real details. I never build exact to specifications because that leaves no room for change. So I would say you need to practice your birds eye view first. Can you see the bigger picture in what you doing? You never attempt to solve a specific problem. You build around the problem which automatically solves that problem but also allows you to solve other problems if you wanted to. An simple example is if you are tasked to create a little dogie.
Above we have a dogie. We will give him the name Rover. If you were given the task to create Rover you might ask how many ears should Rover have? How many legs should Rover have? How many eyes should Rover have? All these are great questions but think bigger. If you are asked to create Rover would you need to create Tim.
Who is Tim. Tim is the cat above. We don’t like Tim. Tim is rude but if we were tasked to create Rover we might eventually have to create Tim. Rover and Tim have similar features so we wouldn’t want to start from scratch to build Tim. However if we built Rover to specification we would need to change the head size, fur features and colors specifically. Everything that is different about Tim would need to be changed from the Rover code. That’s hard work. If only we had a template to work from.
From the above example you can see my point hopefully. Somewhere between my attempt to be funny and sense. What we are actually building is an animal. We don’t need to view it from that high level as yet but maybe just a four legged animal. We create a template for that first and then we can build as many Rovers and Tim’s as required.
To clarify you cannot achieve this without coding structured in a clean fashion. It is simply not possible. I would also like to point out I’m not referring to object oriented programming however viewing your applications as objects will definitely help in building the correct structure.
Become Code Skywalker
How do you then strike the balance. Unfortunately I don’t think this can be taught in the traditional sense at least. This comes with experience. At first you will probably truly over engineer your code but eventually when you get a proper feel for one your environment and what is generally expected you will be able to adjust accordingly. So what is the the conclusion to the matter. If you are not there yet you will get there. Don’t worry. However you do need to be trying to get there. It doesn’t work if you are not trying. Then you can become the Code Skywalker balancing the force between dirty and clean code.