I used to work as a Java-developer a couple of years ago. At the time for this story, I was very new to Java, and relied completely on the experience of my co-workers.
The task at hand was writing a search engine using our own search engine building blocks. It was a fairly standard thing for the company, we did about ten of these every year. To get us started, somebody else in the company sent us their last source files for a similar job. The idea was that we should use it as a template, and just change what needed to be changed in order to get the job done.
The job was assigned to me, and one other person. Let’s call him John. John has done this once before, so he got us started. The templates where kind of big, and had lots of unused code and out-commented code (and, not a single unit test, of course). Since the job was considered easy, we didn’t use any time or effort in trying to understand the big picture – we just changed here, and added there, tweaked this and deleted that until things started to look right. Naturally, we now had an even bigger mess than what we started with, and our understanding of the code was still hovering barely over the zero-level.
After two weeks, we showed the client what we had done, and some changes where asked for. Those changes took some time, because we had no feeling for where the change should be done. Again, we started poking stuff until it did what we wanted it to. We delivered after another week of work. The source was even more unintelligeble than when we started, but hey – the compiled result did what was expected of it. Case closed.
Just a couple of weeks after, Chris was asked to do a similar job. Since we where the last ones working on something like this, we sent our code to Chris, and he started working on it. Now and then he’d ask me or John about something, but we couldn’t really help him. Our understanding was little when we where working on the code, and now, a couple of weeks later, we knew as much as he did. Here is where the magic started. Chris started ripping stuff out. Everything that wasn’t used was stripped away without mercy. He broke down methods into smaller ones. He split logic into separate classes, and simplified the XML-format. After just one week, he was done. He had cleaned up the code, and delivered the functionality asked for. The client still wanted a few changes, but this time Chris could make the changes in just a day.
At this time, neither I or Chris where familiar with XP, TDD and Agile. But it still stuck in my head how me and John, wanting to save time didn’t clean up, and that meant that everything took a lot longer, even in the short run. Chris on the other hand ended up with nice and tidy source, and delivered faster than me and John could. But the biggest gain in my eyes was that by the end of my work, I still didn’t understand the code. Chris on the other hand, understood his code very well. That gain was unmeasurable, but critical in my eyes. I was frustrated most of the time while working on the code, since I didn’t understand what I was doing. I’m not sure Chris had a blast all the time, but he didn’t seem as frustrated.
The moral of the story is that even on a very short project, you’ll probably gain speed and happiness by tidying as you work.
[...] Hedgate: I have worked with Chris on and off for the last seven years. I have learned from him all along, and I still do. Chris has changed so much during these years that it is not [...]
Left by Consulting jiujitsu » Blog Archive » Thank you guys on April 27th, 2009