Vin D'Amico

Software development often seems simpler than other types of engineering because nothing needs to be physically constructed. Many a manager has fallen into the trap of believing that.

Like any engineering discipline, software is complex. Software engineers do not need assistance from manufacturing shops or licensed tradesmen to complete their work. They can do it all themselves. That is precisely where the problems begin.

For example, consider an electrical or mechanical engineer. They design an object and build a prototype or scale model. When they are ready to produce the final product, they will enlist the aid of people who are experts at building things.

Software developers operate differently. They often design and build solutions either single-handedly or in small groups. Their independence makes a difficult job look easy.

Many managers are not in a position to review the work of their software engineers and verify that proper discipline was applied. However, there are a few key areas that warrant extra attention. Being aware of what to ask and what to look out for may result in fewer customer problems.

The first area where software engineers may be lax is including comments in the code. Some will maintain that the software needs no internal comments because it is “self-documenting.” Do not believe it.

If you know how to read the language used to write the software, you will be able to read the code and understand what it does and how it does it. However, the really important question is — “Why?” Why is the code doing what it does? Why was the code implemented this way?

It is also important to note that software is not always written well. It is amazing how often a software engineer will go back and look at something he wrote six months ago and have trouble understanding what he did and why he did it. The comments should provide a roadmap.

Another key area is inputs and outputs. All software either receives information, sends information or, more commonly, a combination of the two. Many problems result from information errors such as dates formatted as dd/mm/yy instead of mm/dd/yy or “name” referring to a person’s entire name not just their first or last name.

Software engineers must clearly specify what they expect as input and what they provide as output. Then, they must validate all external inputs to protect against math errors, missing data errors and worst of all, malicious attacks. Such basic rules are often ignored.

Version control is the next area to address. All software undergoes changes over time. Features are added and defects are resolved. It is common to have customers running different versions of the software as some may be slower to upgrade than others.

A Closer Look A few key areas warrant extra attention in software development. These include: Comments in the code Inputs and outputs Version control A change history Testing Developers reiventing the wheel Using open-source software Over-engineering

There needs to be change history for every module that goes into the software. The history should capture what was changed, why, who changed it, and when. There are free software tools available for this. Simply keeping a set of folders on a file server is not sufficient.

Testing is another area often shorted. There are several reasons for it. Some developers are over confident — they are convinced that their code works. Others find testing boring. They would rather get started on the next module. Still others think that testing is someone else’s job.

Unit testing and system testing are important. Unit testing is done by the developer, module by module. System testing may be done by the developer or by a separate quality assurance team.

Whichever approach you take, do not rely on your end users to do the testing. They do not have the time, patience or training to adequately test software.

Next, watch out for developers trying to reinvent the wheel. Large companies have file servers full of software source code that could be reused or repurposed. The key to effective reuse is constant communication and collaboration among software development teams coupled with good version control.

There is also a wealth of open-source software on the Internet. Exercise caution when using code that is freely available for the taking. Be sure to test it and carefully read the software license to be certain your intended use is acceptable to the author.

The last area to watch out for is over-engineering. Some software engineers will strive for perfection. They will write, re-write, refactor, rework and redo, ad nauseum until they cannot make the software any better.

Perfection is a noble goal but shipping software is nobler. There should be a steady stream of work products coming from your software team — documents, code modules, test cases, working software, etc. If someone gets bogged down, find out why.

Good software development is not simple but following these guidelines can make it easier and faster. The end result will be higher quality software and fewer customer problems.