Make It Work, Make It Clean?
Posted by Davy Brion on September 1st, 2008
A friend asked me if i wanted to have a look at the code he wrote for one of his projects at work. We’ve had some really interesting discussions on writing code in the past so i figured this would be an interesting experience as well. I didn’t know anything about this project, so i asked him if he could tell me what it was about. His explanation wasn’t really clear at first, so i figured: no problem, i’ll just look over the code and it’ll tell me what it does.
So i start looking at the code, and i just couldn’t figure it out. There was a lot of dealing with XML and XPath and some database stuff as well, but as to what the actual meaning of it all was, from a functionality point of view, i couldn’t deduce it from reading the code. Well, if i had spent a couple of hours on it then i probably would have, but from a ‘quick read’ it wasn’t clear to me at all. He did have tests, so he told me to look at those first. They weren’t that easy to read either because each test was testing a lot of stuff at once. But they did verify that everything worked the way he intended it to work.
I showed him a piece of code that i wrote, to illustrate the differences in readability. He then showed me some code in his project that i had missed in my quick review. From a readability perspective, it indeed looked very similar to how i write my code. I then asked him why he didn’t write the other code i had seen earlier in that way. He said “Well i haven’t refactored that code yet, the stuff you just saw has been refactored already”.
That was really weird to me. Personally, i try to write my code in a clean and readable manner from the start. Obviously, you can’t do everything as clean and readable as you’d like it to be while you’re writing it the first time, so in those cases you’d usually start refactoring once the tests of that part of the code all pass. His approach was different. He wrote a lot of code just to make it all work, and he had the necessary tests in place to verify that it worked. He knew that a lot of parts of the code were pretty bad, but he also knew that he could easily refactor the whole thing into clean code because he had all of his tests.
I told him that i think it’s a lot easier if you either try to write it clean from the start, or start the refactoring much sooner. Preferably, right after the tests of the part you’re working on pass. He said that he can’t write it in a clean way from the start, and that he wanted to make the whole thing work before he’d start the refactoring. When i asked him why that would be a good approach, he said it allowed him to put it in production much faster than if he were to write it all in in a clean way from the start.
And that was actually a very interesting statement. If we would both write the same system in the same time frame, our final solutions would probably be pretty similar in terms of readability and comprehensibility. But with his “make it work, make it clean” approach, he would be able to start delivering immediate value to his customer much sooner than i would. It only works because he has the discipline to actually clean up the code after he’s put a working version in production.
To avoid any confusion: it’s not an approach that i would recommend. But i guess that for some people, there’s nothing wrong with it. If you have the discipline to clean up the code afterward, and you’re able to deliver value to your customer very rapidly, can you really say something bad about it? Also, don’t think that this guy is a bad programmer because his first ‘draft’ of the code isn’t all that good. He knows more about clean code and valuable tests than most of the developers i’ve ever met. He actually introduced me to TDD and Refactoring a few years back. The way we use those techniques differs, but the final result will be pretty similar. But his customers will probably enjoy the value of his projects sooner than mine.
As i had suspected, this experience did turn out to be very interesting 
September 2nd, 2008 at 2:58 am
It actually makes the whole process more agile - the customer will be able to change their mind sooner which has a follow on effect that the programmer doesn’t have to go through the process of refactoring code unnecessarily.
September 2nd, 2008 at 9:08 am
The risk is that as soon as the application is in production the customer wants you to work on somethng else and you don’t get the time to refactor. This has nothing to do with discipline.
September 2nd, 2008 at 9:14 am
it depends i guess… you need buy-in from the customer/management that the application needs refactoring _after_ it’s been delivered AND you need to have the discipline to actually clean it up _after_ it’s been delivered
they’re both probably equally important
but again, it’s an approach that definitely wouldn’t be good for me but it might be good for some people
September 2nd, 2008 at 10:00 am
I agree with Peter. This approach would only work if you have a customer / management that recognise the value of refactoring and a clean codebase… and I mean really understand it rather than pay lip-service to it. Unfortunately, I think work on refactoring always comes a poor second to delivering functionality and developers resort to padding time estimates to give them time to clean up aspects of the code.
From my experience, most developers would love the opportunity to clean up the code after they have delivered the functionality. You learn so much from the development process that you know you can produce better, more readable, maintainable code the second time around.
One thing that I have found is that users are not very willing to do acceptance testing when there is no new functionality for them to look at. Or where they do it, it’s very superficial. Hence, you really need your unit tests to give you the confidence to refactor. Where it gets a bit hairy is where you are refactoring your tests as well…
September 2nd, 2008 at 3:55 pm
I’m the guy behind the reason why this code ever got written that you reviewed.
By the way… thanks for that.
What I want to add to your remarks is that basically…
You can sell this idea of ‘refactoring after delivery’ to your management if you work in a product based company like we do. I think it’s a little more difficult to sell this to a customer who actually has to go and pay for the extra month. Moreover, when I would be the ’stupid user’, my first question would be then: why didn’t it get written well in the first place.
I’m a developer… I know why, but I’m afraid it is more black and white for a customer then reality forces us into.
On the other hand, I believe that it should be a mission in life for every individual developer to continuously strive for improved quality in your own code and that involves being first happy and two seconds later critical when you wrote and delivered something. And in that, my friends, you see the difference between those that were born as developers and between those that read a book and copy/pasted some sample code together. Not so long ago, there used to be a time that you had job functions like ‘programmer’ and ‘analist/programmer’. These days, everybody is called a developer. What a pitty.
Greetz,
September 2nd, 2008 at 5:49 pm
@Jurgen:
you’re welcome
oh, and don’t get me started on job titles
September 3rd, 2008 at 1:28 am
Things change once you start working on a team…
September 3rd, 2008 at 6:01 am
@Davy
Please get started on titles. I have a feeling I would quite enjoy that…
September 3rd, 2008 at 7:36 am
@Matt
good point!
@Brian
you’ll have to wait until i’m more inspired to write about it
September 3rd, 2008 at 10:36 pm
[...] Make It Work, Make It Clean? - Davy Brion Davy talks on trade offs to make when we write our new code: with the end result in mind from the start, or just start out writing what comes to mind, refactor later, but be able to show working code faster. Interesting question to think about a bit more… [...]
September 20th, 2008 at 12:21 am
There is always time to refactor.
———————————
One thing unit tests have done for me is to relieve me of the stress of having to keep the entire codebase in my head at all times. Stress which exponentially increases with the size of the project. Thus instead of having to unwind and chill out whenever I have the opportunity (surfing the internet, having lots of coffee breaks with co-workers, … ), in order to avoid burn-out, I can remain productive and refactor. Again the unit tests make this refactoring a stress free experience. I went into production this week with part of the above mentioned application and while I was waiting for the customer to analyze the results, I spend my time refactoring parts of the code. I updated the release without the customer even noticing and making me quite the happy camper. There is no need for management to know what you’re doing. You wouldn’t be able to go faster anyway if you did it the other way, and now you end up with code that smells a lot better, allowing the next requirement to be put into the model much faster, which will make management happy in the long run. I even was able to add some new features to the program when they came back with their analysis, which required a serious overhaul of the core of the thing, without breaking existing functionality, thanks to the tests and this in turn made the customer happy.
Just look around an office, that doesn’t unit test, after a crunch and tell me who’s actually working. There all recovering, torrenting, streaming the olympic games, instant messaging, etc… A team that has a good test suite doesn’t need to recover and can get straight back to bussiness. Even more, they actually enjoy doing so.
But I also agree with Matt. The parts that were refactored first, was the code that needed to be used by other developers. And when I finish this thing, I hope all the code will be in the same healthy state. Therefore abiding to my Prime Directive : a good developer makes himself redundant.
Note : I don’t think I have ever used the word happy as many times in one day, as I did in this post
Use the Source Luke !