Programmer’s Bad Habits

“Good habits are formed; bad habits we fall into.”

There are much literature that has been written on habits or misconceptions that gets acquired by human beings and how it become hard to leave, especially if those habits or concepts are considered as bad. Bad habits as we all know, seems easy and “quick” solutions that are acquired, mostly unconsciously. But good habits are hard to acquire but gives long lasting benefits to us.

As a developers/programmers or architects, we also acquire habits/misconceptions in our work that consciously or unconsciously imposed seems “quick and easy” solutions to our programming problems. I wanted to throw some light on such bad habits of us-developers…I had also gone through some of these bad habits but thankfully dropped them in my journey to become good dev. Some people may also term them as “anti patterns”, but I am not very comfortable about the word ‘anti-pattern” ;maybe I explain my reasons of terminology in some other post, but now let’s focus on these bad habits or misconceptions.

1. Ignore the warnings, while compilation since they are not causing any problems.

I had seen this many times and I hate this. Some colleague of mine calls me up says that s/he couldn’t find the bug in their program and even after spending a couple of hours and tried all the things s/he can do…

First thing I would try is, I rebuild codebase and see if they had any compilation errors or warnings…and here we go..many warnings yelling for attention!! When questioned about the warnings, the usual answer I hear is “oh! They are not causing any problem so we just ignored them”…and when I see the warnings..Most of the unfound reasons of the bugs are lying in warnings that are in front of the programmers but they can’t see it.

I am not suggesting that you convert all those warning messages into error messages, but warnings are generally-the sign of future or runtime error places and signaling towards inefficiencies in code ;so treat them like errors and work on those.

2. If code is compiling, it is working code.

If you give some junior any requirement and say them that “ok, you need to code this feature/use case etc.” and just watch them. They just start writing the code at the blink of the eye and eager to show their worthiness. But the unfortunate part is next, and that is when they say I am done with the feature/s after their code is getting compiled. Hey Guys! Wake up… writing a compiling code is just a first step and hell…you are not done…Your code has not even passed those unit tests and how you dare to say that your are done.

3. Code once written and running should never be touched.

I generally deal with legacy not in C/C++ terms but have reengineered systems those are in VB 6, .NET 1.1, and likes.

In my opinion, legacy should be termed as “system with inefficiencies even it’s written with latest and greatest likes of .Net 3.5.” Unfortunately that is not the de-facto definition.

Most of the developers and even sometimes project managers have this nausea that if the code has written and that is running that should never be touched.

They say, hey! That is running and as per specifications, why you want to change it or make it better [they see as, this idiot is fooling us by wasting hours on thing that is already done!!] What they miss out is; it is like rusting of the iron. If the code can be improved even a bit by any means, it should be done. It is like you see a piece of rusting iron in your vehicle and still you do not do anything and run your vehicle until any accident occurs.

Damn, that kind of code can carry any characteristic like rigid to requirement changes , fragile like showing strange behavior like fixing bug in one part of code throws the strange error in some other part of the code which is not even related with first. So, the point here is ,we need to remove the inefficiencies.

4. New features can only be floated out by writing tons of new code.

This is really hard to realize that we had picked up such misconception and even harder to come out of this!!

For example, during one re-engineering project, I realized that our architecture is giving ability to product that the client can sell different modules/subsystems to the end users as on need basis and we communicated this to product owner and he liked that idea and which in turn given the product the new revenue stream.We have delivered a feature that is making a strong business sense for product owner without adding extra code!!

All this becomes possible not because we have added some more code for such business feature but cleverly re-architecting the system.

Oh! This post is somewhat getting bigger,I am sorry to break the continuum but just like ‘short methods’ is a good idiom to follow in code, I am keeping this post small and write it in chunks as a true agile developer 🙂

Till then Happy Thinking!

Hope to see you next time…

 

Share this post :