Photoquarium Blog

During one of my many discussions with James, he brought up the question “What makes a good developer?” I didn’t have any really good answers but, as most things, someone else had encountered a similar question that has given me a bit of insight. Davey Brion wrote a post on his blog ElegantCode on Ethics In Software Development:Pragmatism Over Dogmatism where he describes what he thinks is the primary goal of a developer and how writing crappy code (or maintainingcrappy code over fixing it) is counterintuitive to the goals of a developer.

A software developer’s primary goal should be to create value for the users of a system. Value can mean a lot of things here. First and foremost, it should be about things that users actually experience. Features, ease of use, performance, etc. You can get all of those with crappy code, but that leads to a situation where you won’t be able to sustain that value in the long term. A system can be very useful to its users, but if the code is in such bad shape that it can’t easily be maintained and extended with new features over time, the value of the system will slowly reduce. New features will introduce new bugs. Bug fixes will introduce new bugs. Eventually, the system starts to collapse under its own rot and the dreaded rewrite commences. Nobody really wants this, do they? If you write good, clean code from the beginning, you can usually avoid these problems.

This is a great standard to develop by and a great answer to Jame’s question. If we create good code that is clean and easily maintainable the system will not only satisfy our users but also our bosses. The users will have that system that is fast, user friendly and issues can be dealt with quickly and confidently, while the bosses will like the fact that it is not a land mine of issues that always have to be circumvented whenever something needs to be fixed and you won’t cringe every time you have to step into the code base to fix something. Good clean code is a great measurement of a good developer but how is it ultimately measured? I will leave that question for you guys to help answer in the comments.

But how do we keep the code base clean and maintainable, every issues potential fix has risk to be weighted and sometimes “fixing it the right way” has to much potential of breaking other stuff so you opt for the simpler “hacky” solution. This hacky solution is not wrong it is just what needed to be done at the moment to alleviate the risk. But you have to be discipline enough to fix it when the time permits, maybe during your next iteration or release cycle. You should be adding a case to your bug tracking software right away on the correct fix so it can be put into your backlog and at least it is visible and can be prioritized accordingly. If you don’t have this visibility I will guarantee you that the right fix will be lost and never implemented and you will eventually end up with crappy code.

As you can see having crappy code and leaving it will just keep the technical debt rising and eventually the system will become of no value to the customer/user since any change or bug that needs to be implemented has more potential of harm then good. So how do we fix this application that is already in such a craptastic state? I would suggest that we take a parallel road that we did to get it here in the first place. Slow and steady.

As in my other article Fix it or rewrite it, I would not go suggest rewriting the whole application. Instead we should take a slow road that will chip away at all the technical debt we have incurred by being undisciplined. There might have to be some big leaps in the code, and also some that may not be visible to the customer but eventually everything will be visible since they will get a better product and better support.

I hope you have caught on that I believe a good developer is a discipline developer, I don’t think that you can say a good developer always fixes or codes something “the right way”, since each situation is unique and “the right way” changes all the time. I would say a good developer does the job that needs to be done but has the discipline to know when a solution is just a stop gap and makes it visible enough that the correct solution can be implemented when time and resources permit. Also a good developer should never allow the application they are working on get to that craptastic state they should always bring the technical debt to the surface and making it visible and helping improve the application are working on. Even if it isn’t something that they haven’t done themselves. Ok enough of my preaching.

ps. That cute kid is James Birchall’s son from his flickr account.