Seven habits of highly ineffective software engineers

I have come across many instances of engineers develop these habits over the years without realising the negative effects.

1. Design? What design?

Let me just bang the code out in a few hours, and we shall see what happens. I don’t need a whiteboard. I don’t need a design spec. I can visualise it all in my head. I am a genius.

Effect:

What usually ends up happening is that folks need to continuously rework the code because they missed a major detail somewhere, thus increasing the overall development and test duration.

Solution:

Writing or drawing out a basic design for a fairly large problem and having it vetted by peers goes a long way in ensuring that one spends their coding time effectively.

2. Over optimistic => Over promise => Over deadline

I do not foresee any problems coming my way when I implement the 5 features I plan to work on this month. Nothing comes in my way. I am an optimist.

Effect:

You run into dead ends with a particular feature, and you need to get help from a colleague in a different time zone, resulting in adding X number of hours into the schedule. And then you scramble and roll out crappy code, or simply miss the deadline.

Solution:

Scoping is one of the more harder skills of being a software engineer, so better to be safe than sorry. If you finish what you said you would, then roll out a couple more items. Under-promise and over-deliver!

3. Reinvent the wheel

I am not going to waste my googling to check if someone has already implemented a library. Why waste time when I can write code. Isn’t that what I am paid to do?

Effect:

Spend a few hours writing code, when you could have spent a few minutes using a standard library or a suggestion by someone on stackoverflow.com.

Solution:

If it seems like something that someone might have come across, there must be a way to handle it, without starting from scratch.

4. I don’t need to run tests

I am only changing a few lines of code in ‘my’ class and ‘my’ function. Why would anybody else be affected. The tests will definitely pass. I am a rockstar.

Effect:

Expecting the code to run correctly without running tests is suicidal. Just makes for more work when the breakage is detected and panic sets in a day before the release.

Solution:

Have your tests ready before your code, and run your tests even if you believe your code is not going to break another parts of the system. If all tests were assumed to pass, why have them in the first place?

5. Naming Variables i, ii, iii

I know what the variables denote. I don’t care if its not obvious to others. I am a (wo)man of few words (or letters in this case).

Effect:

People reading your code have no idea what the variables denote thus making it harder to understand it. And if there are no comments, it only makes things worse.

Solution:

Use descriptive variables names as far as possible.

6. Complex is better than simple

I am so good that I will make the code complex. People who read it will not get it, and think highly of me. I am a champion.

Effect:

Sorry, people will be pissed off. Simple is beautiful.

Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.
— Anonymous

Solution:

Make it only as complex as it needs to be. Choose simplicity whenever possible. It just makes everyone’s life easier. And there will be many opportunities to develop a solution for a complex problem.

Programming can be fun, so can cryptography; however they should not be combined.
— Kreitzberg and Shneiderman

7. Ctrl-C + Ctrl-V

Let me just copy this code and use it where I want. Who cares about duplication. I am lazy.

Effect:

Duplication. Double updates. Multiple copies of mostly similar looking code adding to the maintenance nightmare.

Solution:

Factor out common parts into a more generic function. Re-factor now rather than later. Run tests to make sure everything still works.

This happens more often than one would like. A little more big-picture thinking on part of developers would help matters. But I strongly believe the following to be true:

One principle problem of educating software engineers is that they will not use a new method until they believe it works and, more importantly, that they will not believe the method will work until they see it for themselves.
–Humphrey, W.S., “The Personal Software Process”

Originally published at shlsh.wordpress.com on January 19, 2014.