articles Home

Simple Software Engineering Guidelines

This article has some SIMPLE POINTS to organizing a system to run or develop software. It is aimed at people with no experience so forgive the obvious points. However, as a consultant with wide experience in private industry and government I see the lack of basics as the rule rather than the exception and many project managers are experts in the business domain and not the software engineering needed to implement a successful software project.

What basic software engineering methods and techniques can be used to make good successful systems?

Get Familiar With Some Software Engineering References

READ A BOOK or five and talk to people who successfully develop code or run systems. If you only read one book I recommend Brooks classic, "The Mythical Man Month", short, to the point, and people will recognize the author. You are an instant learned authority just by quoting the title. If you read past the title you may even learn something.

SEARCH OUT and talk to locals who develop successful software and have actually implemented a successful software project. Occasionally in the field things actually turn out OK, find out how people did it, check out what they have done. Another good place is to follow any famous open source or GPL projects that are actually moving forward and successful. See how they are organized, what they do for configuration management, tools, bug tracking, version releasing, etc. Naturally, do not bombard the development teams with questions, they are doing real work; there should be enough for you to do by reading documentation and the project communication tools to find out what is happening, the project team members are not your personal tutors.

Specific Software Engineering Practices

Separate Development and Test From Production Systems

Yeah, basic, but many inexperienced software project managers do not do this at all. Probably the most basic move to stability and a successful software project of any type.

Use Configuration Management

Use source code control and methods of packaging and moving code from development and test systems to the production systems. Whether you develop software or buy it somehow a new version has to get installed tested and moved to production or released in an ordered method.

Use a Change Control Group

If your system is large and affects many people you will need a method to review and publish changes in the systems to the rest of your organization. This keeps people aware that changes may affect others in ways that are not seen by the people doing a change.

Review and Test

Many times this is never done or overlooked. Specific techniques for database projects are easily figured out, check the schemas, optimizers, SQL tracing, resource contention, indexing, etc. Review code by others, do not have any developer without an outside review, test the code by others, not only the person who wrote the code. This does not apply only to development but to system configuration changes and new versions of purchased software, check what has changed, test the new versions before putting the new version into production.

Testing and review is not squeezed in at the end of some process, it should be an ongoing part of the whole project. Every stage of a project should be reviewed and tested in some way.

Fire the Idiots

And encourage your good people. Many people think they are above such mundane techniques described above and think they are too special and talented to be "constrained" by configuration management or reviews and testing. They usually leave broken systems and cost overruns in their wake. Fire them now before you get fired for failing. Your project will only succeed if your team knows and understands the basics, there are no shortcuts.