I don’t think I could do justice to this post by summarizing it so I won’t.

If you have a few minutes to read this post I really encourage you to do so. Also post your comments here about the article, I would love to hear everyones take on this.

I’m off to read a bit on “complex adaptive systems theory” and “Evolutionary Stable Strategies”.

http://www.noop.nl/2009/02/the-decline-and-fall-of-agilists.html

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.

Fix it or rewrite it

We have all had to face this dilemma at one point in out development careers, do we take that old crappy broken piece of software that we have been patching and re-patching and scrap it for a brand spanking new rewrite that will solve all of out issues, or do we take the time to properly fix what we have and evolve it into the application that we wished it was.

I have been struggling with this with one of the applications that I have maintained for years, is it worthy of scrapping for a full rewrite or should we just take the time and effort to fix it once and for all. There is no need to say its name we all know what it is (plus I wouldn’t want it to find out I am bad mouthing it, more things might go wrong).

I see both sides of the coin here:

On the Heads Side:

The developer in me wants to scrap it and be able to work on that pretty, clean, all mine application that will not have all the headaches and stigma that the original application has. I will be able to design it from the ground up and it will be prefect. The perfection of green field projects:

In a green field you don’t have to deal with the mess that’s accumulated over the years. In a green field you can be clean. In a green field you can build the perfect system. All would be well if only we could start over with a green field.

We will be able to use that new technology, remove some of the constraints that are ingrained in the old venison learn from all our pains and make this new fancy 2.0 version that we all dream of.

On the Tails Side:

But wait, what about all the years of evolving that the original application had gone through, how do I get that in this green field application? Can I extract all the correct requirements and business logic that is all ready included? What about new requirements, do I stop maintaining the old application and only add these new requirements to version 2.0.

Remember Xeno’s Paradox? Achilles and a tortoise are in a race. The tortoise has a head start. Every time Achilles gets to where the tortoise was, the tortoise has moved to a new point ahead of Achilles. Therefore Achilles can never catch the tortoise.

Fortunately the law of limits allows us to escape this paradox in a mathematical sense. But in software the paradox sill holds. The Tiger Team can never catch up to the old system. Every time they get to where the old system was, the old system has added new features

I don’t know what part of me this is coming from but I do think that the best solution would be to take this ailing, almost dying application and revive it, give it the million dollar man makeover. We can make it better. I know we can. This might be a little bit of my ego saying I can fix anything but more realistically there is to much inherent knowledge inside the existing application that take years to duplicate, heck it took us years to get it in there in the first place.

Taking the existing structure of the application and improving upon piece by piece will help keep this knowledge in the system but as we slowly evolve the existing application. We can address the most painful points first and take it one step at a time. This doesn’t have to mean that we are going to stop maintaining and fixing issues as they arise, we just have to make some due diligence and fix them properly with an eye to the future. This may mean no more 1-2 day turn around time, instead more like 1-2 week turn around time (or longer depending on the underlying issue). But over time we will see a new and improved application break free from the cocoon of crappy code.

It may be easier in the short term to scrap the old application but unless we face the reasons why the old application became that way we are destine to repeat them. If we step up and face the fact that we contributed to this crap, promise to fix it, and deal with the decisions we have made we can learn and evolve just as our application has to and not repeat history be it on new projects or on the same one.

Now I could just keep going on and on about this but instead here is a few more articles from people that you might respect a bit more (or might not) that echo my opinion:

Things You Should Never Do, Part I – Joel Spolsky

The Big Rewrite Series – Chad Folwer

This is a huge list and maybe you don’t agree with all these books as a “best ever” but it will give you some books to keep in mind as a start to increase you knowledge. Also he posted a follow up to this post here. Enjoy.

 photo credit: blu_blue