Two weeks ago I had the opportunity to introduce the topic @S/W for Domain Experts 5 – Models before Code Conference in Athens and, this is a small write up from my notes.

Lust a.k.a. Over-engineering

Modern programming languages tend to add features as they mature, piling layer after layer of abstraction, with new keywords and structures designed to aid code readability and reusability under the assumption that whoever is using them will take the time to learn how to use them properly.

Unfortunately, what looks good on paper doesn’t always work in practice, and just because you can do something doesn’t mean you should do it in the first place.

Gluttony a.k.a. Failing to refactor

As a S/W engineer there is nothing more gratifying as an accomplishment than shipping software and once the working product has been released the temptation is really strong to begin planning the next iteration of the product, especially what new features should it have? However, it’s easy to forget that code seldom leaves the door in perfect shape. Then, as features accumulate with successive rounds of development, S/W engineers tend to compound mistakes of the past, resulting in a bloated, fragile code base that’s too tangled to maintain effectively.

Therefore, you need to evaluate your existing code for quality and maintainability and make code refactoring a line item in your S/W development budget for each new iteration.

Greed a.k.a Competing across Teams

An excessive desire for wealth and power is the only way to explain the motives of S/W engineers who compete with their own coworkers. Competition and rivalry usually starts when different teams are left off e-mail lists and then escalates into closed-door meetings.  Next thing you know, one engineering team has written a library that re-implements more than half of the functionality already coded by another one.  Engineering teams lacking clearly defined objectives, can easily hold onto responsibilities broader than necessary.

One of the top priorities in managing any S/W development project should be to make sure each team knows what the other teams are doing, and that everyone is working toward the common goal.

Sloth a.k.a. Not Validating Inputs

The list of basic S/W engineering mistakes is long, but the sin of failing to validate inputs is so huge that it bears special consideration, since this amateur error still emerges in code written by experienced S/W engineers and many commonplace security vulnerabilities, from buffer overruns to SQL injection attacks, can be traced directly to code that operates on user input without validating it. Modern programming languages provide many tools to help S/W engineers keep this from happening, but they have to be used properly.

Therefore, input validation should be built into the core of your product, not sprinkled on-top of it in the UI.

Wrath a.k.a. Not Commenting on your Code

There is no bigger act of hostility to your fellow S/W engineer than failing to comment on your code. In principle well-written code is its own best documentation, however the lines of code you wrote at 3:00am last Sunday morning weren’t exactly very well-written. It’s easy for S/W engineers to forget that the code they write today will live on long after they’ve left the job.

So do not forget that, code is its own best documentation of what it does; and comments are there to explain the why.

Envy a.k.a. Not Using Version Control

It’s hard to believe but there are still companies managing S/W development projects today, that exist as a directory tree on a file server, guarded by a single gate keeper. As a result scattered around the company are duplicates of this tree on individual S/W  engineers workstations, each one of them slightly different, though no one knows exactly how different.

There is no reason today, not to start a code repository as first step in any project, even small ones with so many free tools available.

Pride a.k.a. Not Unit Testing

It’s often tempting to pat oneself on the back for a job well done. But do you really know if it’s well done? What are your metrics? Unless you have validated your code against specific test cases, you have no idea whether it works as advertised and is completely free of bugs.  By the time the defective code arrives in the client’s hands, it’s too late to undo the mistake.

The more you plan for unit testing before your code ships, the more damage control you can avoid after release.

Want to learn more on how-to-do, drop us an email and we will be happy to share our knowledge and insights with you!

For Hippocampus.io,

Christos Lytras – Managing Partner