When one of my early projects where I had programmed by co-incidence ended I was really happy to move on to other things in life. Then suddenly, I was told to support the same project for a few more months and then a few more and then a few more.
On one hand maintaining my own code that sucked, made my life miserable. On the other hand however, it taught me how to take ownership of my code early on in my development life.
It taught me to set things right, by ruthless refactoring slowly with time, rather than just giving up or running away. Much like a painter who draws something that he thinks is really beautiful and then sells it at a price, I’ve felt a tinge of sadness in transitioning code over to the client in every other project after the one where I programmed by co-incidence.
Every now and then in my development career I’ve been involved with projects in and outside work where the primary project was migrating from one technology to another.
Migration projects at times are exciting. In migration projects it is implied that you will be spending a lot of time reading code (a skill every developer should cultivate) that folks from all over the world, who you may or may not have ever met or talked to have written. All you end up knowing is that months ago the clients hired a team of consultants. They wrote some code, transitioned it and have now moved on.
Every now and then during my development career I’ve also met (and interviewed) a lot consultants. Of all the consultants that I’ve met, I’ve observed a particular kind very closely. Let’s call a consultant of this type – Fred.
Fred has the following peculiar characteristics:
- Fred usually works in short term billable projects.
- Fred gets very uncomfortable when he is asked to work in a project that will last for more than 5 months.
- Make Fred work in a long term Product that lasts for more than a couple of years that he would have to support and Fred becomes very nervous.
- Fred has a tendency to introduce Code Smell and writing snippets that qualify for “Daily WTF” every once-in-a-while.
Long story short, this type works under a philosophy that can be described in a line: Code, Hand over the code, Run and Don’t Look back!
As you dive deeper into Fred’s mentality you realize that there’s a little bit of Fred in all of us. Writing good code is all about getting rid of Fred! So what’s fundamentally wrong with Fred?
Fred is not really a bad programmer. Like all other good programmers Fred is struggling with the same issues we all struggle with: changing requirements, dead-lines, pressure from customer etc. What Fred lacks however is – ownership.
Fred Codes, Fred Codes More. Fred Hands over the code to the Client. Fred turns around and then Fred Runs as fast as he can, to another project. He doesn’t look back and he knows that he got away – Scot-Free! Year after year Fred continues to add “successfully transitioned” projects to his resume but doesn’t learn the art of Refactoring, the art of throwing away code and the art of elasticizing the iron triangle of software development . Big Design Up-front methodologies with no iterations help Fred tremendously in his Run-Away attitude.
An acquaintance in a 300 person process oriented CMM software consultancy house defends Fred - “but he successfully completed a project, right?”- Yeah. (I think I will not answer that question).
Actually, he doesn’t need to defend Fred because this discussion is not about criticizing Fred. Like I said, there’s a little bit of Fred in all of us. Do you have a little bit of Fred in you too?
The first step to getting rid of Fred is to cultivate a sense of code-ownership. Throw out a framework or a tool and commit to support it for at-least a few years. This could be a simple Accounting tool you write for your finance department or an open source project you start with a very small user base. The size of the project or lines of code aren’t important. Start by writing something that you are proud to support and maintain – for a very long time.
If you have posted articles / code out to the world, take time to support your code and content. Answer questions you get related to these. Don't abandon your content and code! Support it. If possible, Get involved in a longer project or product with support contracts.
In other words, learn to stand by your code, writing and words when they are released to the world. Learn to own and support them! Jumping from organization to another or jumping from one project to another, every few months, doesn’t take Fred anywhere in the long run.