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

I think we are all (or at least I hope we are all) battling between doing what we know is going to give us the best product possible and just getting the product out. So basically battling between being a craftsmen and a just a producer.

Anyway I listened to one of the teleseminars and it was great, a bunch of authors getting together to discuss their works and expanding on their ideas. Basically a coffe shop discusion on their ideals. So judge for yourselves and check it out. If you want full access to the mp3’s then just sign up to Elizabeth Marshall’s website and it will send you a password to access the library. 

Enjoy

So on our path toward SMWDA or Stable Modular Well Documented API’s, I have some across this article on the MSDN site. Now don’t let the fact that it is in MSDN Magazine and written by someone that develops on Microsoft’s platform deter you from reading it, it is a good read. It will also give you a little bit of an insight on the direction our code bases should be going.

Open Closed Principle

I was going to give a quick summary but the article isn’t that long and it does a better job than I can.

Where, you ask, does this confessional come from? Well I read this blog post by Brian Auer on Epic Edits, My Weakest Area of Photography. This post was exactly what the title says, his weakest points in his photography and how he is going about to improve on them. This got me thinking about my weakest point in photography and life but that is to deep for this blog and we will stick with photography.

Post Processing

I would say this is one of my most inconsistent parts of my photo process. I go out and take hundreds of photo’s and instead of taking them off the camera right away and starting the sorting, processing and ratign of my photo’s I let them sit there and forget about them for a while. This is bringing me to a mountain of images that I either forget I have or get overwelmed with when I try to start the actual process.

How I am going to fix it

Organize – Getting To grips with image management

Organize – Getting to grips with image management 2

Organize – See it through

Printing Photo’s

This on is along the same lines as the previous in that it is a procrastination issue as well. I am alway saying that I need to print my photo’s be it as a framed photo for my wall or as a photobook that I can put on my coffe table for myseld and others to enjoy.

How I am going to fix this

Posting online

I have my photoblog on photoquarium that I post to in spurts but not consistent enough. Also I need to post to my flickr account as well as othere sites like vazaar. I need to get my photo’s more exposure and critisism, I am not sure how I can progress and get better if I don’t get opinions on my work. Maybe I should spend more time in places like photophlow where I can chat with people and get my photo’s critiqued there.

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

I am hopefully going to rectify that and start disceplening myself more to publish post on a more regular basis. To my defense though, I have been posting on my companies internal blog and I just realized why try and post to two blogs when I can just take these internal articles and post them here. I will however sanitize them so that if there happens to be any sensitive data  (names, numbers, project specifics, etc) will be generalized orr take out. 

So starting tomorrow I am going to be publishing the these posts ( I don’t think I can them articles) and hopefully this will get me in the habbit of posting one article a week. 

One article (actually it’s a video) called Features Don’t Exits (Only Benefits), Max Pool goes on a little rant about a styrofoam drink container that has a feature labeled on it. He basically goes on saying that the feature is irrelevant and the company would have been better served to list one on the benefits of using a styrofoam container and then starts to relate this stance onto software.

Whether we list the features or benefits of the product, I feel that this is like most things in software development, we should look at each case and decide whether a feature will convey the most and best information to the user or will listing it in a benefit manner be more effective.

There was a follow up post by Jurgen Appello where he disagrees with this notion of benefits and expands more on the questions, who is deciding that this is actually a  benefit, the end users or the company, or what is a benefit. Here is a good quote from the article.

When you create a product, it is often necessary to anticipate what your customers want. You have to imagine needs and benefits, and design your product accordingly. But once your product is out in the open, being used by your customer, you must stop acting on imagined needs and benefits. You must accept whatever it is the customer is doing with your product. Don’t tell your customer how many suitcases the trunk in a car can hold. Just tell the customer what its dimensions and volume are. Whether your customers want to translate that to “number of suitcases”, “number of sheep” or “number of dead bodies”, is up to them

I have seen this situation on a few projects I have worked on where we are thinking that we are adding a benefit to the system by changing the way it works. In out minds this makes no sense the way it is working now and logically we are probably right.
But after the change is deployed to the field we find out that the users are using the product in a way that we can’t understand why. It could be because they have gotten use to it working this way or that they see the system in a totally different way then we do. Either way the benefit is actually a hindrance to the end user and complaints come rolling in. A few times we have even rolled back the changes.

So do we try and predict what the users want or let them fully drive the future enhancements and benefits. I believe its a fine balancing act that takes a bit from each side but pushing features and benefits onto a client can really hurt you. I have a firm belief that the user should be involved (or at least consulted) in all the steps of development. This can save from some long and expensive failures since it should be caught early on that this isn’t wanted or needed by the clients.

What is your opinion, features or benifits, who knows best?