Is your code demanding Euthanasia?

Been a while on the blog... I am spending some of my time reviewing the styles and mistakes developers do while coding. The blog post was awaited, but the only reason I write it over today is the movie I saw 2 weeks ago. The topic revolved around Euthanasia - Mercy Killing . No I don't advocate it nor I have any reason to promote it. The only reason I write the blog post is the reason defined above... During my review of the code and coding standards and general mistakes programmers do while writing the code, i found places (bunch of them) where thoughts limited to today and tomorrow are aligned. This unfortunately is true for some really popular open source frameworks too. With all this in action I am forced to say that their code sooner or later would demand a Euthanasia...Though I want to say that every single line of code needs to evolve... there is a huge difference between refactoring and re-writing.

Many of the products undergo re-writes, many of them between 2-5 years of the first line written... I remember of one that happened 3 years ago[I don't want to discuss it in this forum]. When these products undergo the process, they are simply killed, there is no scope of donations of working organs too. When you speak to people whose code may be on a verge of death, they may well stand to defend it, there will be several excuses and arguments but the reality is... in the fast paced product development we are building a baby who years down is going to ask for Euthanasia. So what really determines your code needs that? What makes you realize it is moving towards that? How to stop it? How not to add to its troubles?

So many questions... here are a few of my cents, for the coders, product owners, stake holders, technologists

Your code will demand Euthanasia if :

1. You are writing your code for today or a feature limited to today.

2. You are a coder and you only see the SRS document and nothing beyond..

3. If you do not follow coding standards, just so you can deliver in time..

4. You are not re-visiting some legacy code in pieces once every few weeks or months at the least.

5. You believe in quick development and no code reviews

6. You only talk about code quality, but when it comes to writing it... you are arguing about the if's and then's...

7. You think

Email.from = "support@XXX.com";

is what you think a good way of writing code.

8. The elements of your program are requirement document and hard work only.

9. You have not evolved it more than once over a period of time. Be it days, months, weeks, years.

10. You think scalability is only adding servers, robustness is writing interfaces doing same things, re-usability is copy and paste.

Many many more , small but such things... lead your code to Euthanasia.. today or tomorrow.

So what should you do to help your code?

1. When you write it, make sure you see the future of it and past of it

2. Make sure you review it yourself, and then get it reviewed by at least one another eye

3. Make sure you create robustness by checking boundaries

4. Make sure you evolve, refactor

5. Make sure you sandwich it in multiple test scenarios and unit tests.

6. Make sure you document it, so when some one discovers your dinosaur age code, he wont run away from your company.

7. Make sure you have applied the best possible standards.

8. Make sure you own it. Re-visit it some times just to see if you can improvise it, even if it is not most required.

Well We all are responsible to save our code from asking for a Mercy killing... our hard earned credits to best performing features deserve a long lasting code too...