Bad code - a random thought

11 Mar 2017


last modified: 12-mar-2017 (11:24)


Recently, I was asked to handle a big enterprise app which was left orphan for few weeks. With enough curiosity, I started reviewing the code; it was all over with in few hours. Here is why (the code is written by developers how have degrees in CS and have minimum 1-4 years of particle experience)

public static boolean hasValue(String value) {
try {
    if (value != null && !value.toLowerCase().equalsIgnoreCase("null") && !value.equalsIgnoreCase("")) {
        return true;
    } else {
        return false;
} catch (Exception e) {
    return false;
String status = "some status"
if(code == 500) {
 }else {

Being an enterprise project I was expecting enterprise quality and why should I not?

I am like other thousands of programmers who code responsibly and spaghetti code is a nightmare for them.

I was in grief, sad and disappointed.

I have been thinking about it for days and wanted to figure out why someone would write such a code. Is this the developer who is responsible or management? These questions bother me whenever I need to patch that code. I have found a few reasons and now I am going to write about them. Before moving on, I want to share that these opinions are my own and may not be perfect or accurate at all. Anyone can disagree with them. Anything I write about software developers includes me too.

Bad selection process

Our selection process for software developers is really outdated and limited. Anyone who have memorized a few concepts is able to pass through it. In software industry we don’t need people who are limited to theory. We need developers who apply whatever they have learnt in an effective manner.

Look at the points I have mentioned in the beginning. You don’t need be Linus Torvalds to care about them, these are just normal practices that every developer should care about.

We have to select on the basis of how someone have applied concepts, not on how much they know or for how long they have been in the industry.

CV driven culture

Luckily, few days back, I got a chance to interview some experienced developers (4-5 years). All of them have written numerous skills and tools on their resumes. While interviewing, I asked them about those libraries or tools and believe me or not, all of them were unable to give satisfactory answers. Even the most basic questions about programming were not answered.

One of the developers had written git in his skills and I asked him to rate it out of 10. He replied 10/10.

There is nothing special in git. I know it all. Push for pushing code, pull for pulling code. Replied a 5 years experienced developer.

We learn to write it on resume and that’s it. We learn it only to answer an interviewer, without any interest in what we are learning.

We are good developers with poor mindset.

Personally, I believe if you know one language and know it well. It’s enough for your life (you can make a lot of money).

Lack of knowledge

It is deeply related to CV driven culture. Most of the time, developers start their career with reading tutorials and they stick to it for the rest of life. They learn one thing, know a little about it and apply them everywhere without knowing any concequences. They do not want to go deep and learn it well. This attitude can work well for small projects but for large scale projects it does not. They use ignorant use of concepts or don’t use concepts at all, resulting in a product that can never be stable until written from the scratch again.

With little knowledge, developers inherit unwanted complexities in the project from which they are unaware.

Just a job

Perhaps it is the most important factor. For most of the developers, it is just their job and they have no interest or curiosity.

A developer without passion is not worth hiring.

This job based thinking restricts the developers from growing. They become habitual to quick fixes and life hacks.

Non-technical managers (Perhaps)

I have been fixing issues which shouldn’t be there at all. Very common scenarios are not working properly. With little observation, I have found that code was written in panic.

If you ask a developer to fix an issue in 10 minutes and expect that he does handle it really well. You are wrong. Developer will do everything quickly without thinking about it, ultimately he/she will miss some scenarios that you will have to fix later by giving him/her more time.

A technical manager can understand it but for a non-technical manager these things do not make any sense, all he/she knows is do this thing in this time.

Keeping developers under pressure and in panic does not yield good results in long run. For short time, you will find yourself doing things quickly but in long run you will be wasting more time to fix the crap you have forced the developer to write in short time.