Home Executing Integration Procedures for Professional Software Engineers
US FTC Compliance
Yes, all these ads are some kind of affiliate link and I get paid a commission if you click or buy.
Not enough to quit my day job, but it keeps the site alive.
- Jeb Riordan, Editor, PROJECTmagazine
Procedures for Professional Software Engineers Print
Every profession has standard techniques. Surgeons, police officers, and auto mechanics all follow procedures in their work. These procedures are usually learned on the job. They represent accumulated experience.

 

Software development procedures also exist, though they're not as widely used as they should be.
Using them makes project management far easier.

The marketing people become your best friends. Schedule is something you enjoy talking about. Programmers work harder and are much happier. Software is produced predictably and on schedule. Project Managers spend their time where they can deliver the most value, attacking issues of long-term productivity and long range steering.

These procedures include proper use of configuration management, effective code reviews, and frequent testing, among other things.
A list of the best practices is provided below.

These practices comprise professional software engineering.

Who Uses These Procedures

It's easy to spot the teams that use these techniques. They're the ones leaving at 4:30 on Friday, with the confident smiles. They know that they are on schedule, with a product that works well.

Microsoft uses all of these (and more). So do the writers of Linux. This is how professional software engineers work.

How about your team?

There are still plenty of teams which rely on the haphazard software development model of the 70's and 80's.
In the Darwinian world of project management, managers of these teams are doomed to extinction.

What Procedures Constitute Professional Software Engineering

In approximate order of use in the development process, here are the most important standard practices in software.

 

  1. Useful Requirements Process
  2. Effective Use of Version Control Software
  3. Use of UML and/or Other Design Tools
  4. Agile Planning and Short Release Cycle
  5. Code Review
  6. Weekly Build/Test Cycle
  7. Bug Tracking
  8. Independent Testing by Professional Testers
  9. Professional Staff for Customer Support and Training

 

How To Put Procedures in Place

If you need to put some procedures in place, pick whichever one looks easiest to start with. Then start the learning process. Each of these procedures has inspired its own body of experience. You'll have to dive in to get the full benefit.

Don't try to put two new procedures in place at once. Give each one the focus and concentration it deserves.

Make sure your gains are certain, that any territory gained is not lost. Don't start using version control and then slip back into the old sloppy way of doing things. That is fatal for programmer morale.

Any procedure you put in place should rapidly gain unanimous approval from all the senior developers. If not, ask them what's wrong with it. Tailor it to their needs and work style. Each procedure can produce benefits for the programmers. Ensure that they realize and notice them.

Some of us Look to the Stars

Senior developers and managers often try and jump too far ahead when implementing these prodedures. They envision a perfect paper-trail, useful statistics, and fancy reports.

All those nice things are possible in time, but first concentrate on getting the process in place.

Once in place, marvelous ideas can be tried out.

I had a colleague who became very excited about some statistics. I'll call him Bill (since that's his name).

Bill developed some graphs showing the number of bugs reported, fixed, and outstanding. These were presented in a simple graph, automatically displayed by the bug tracking system.

Bill pointed out that these numbers gave a very clear indication of the status of a product. No matter what the schedule said, if there are lots of bugs still be reported its not ready.

On the other hand, when several weeks go by with a steadily decreasing number of bugs, you know you're just about ready for release.

Bill's charts were used by everyone on the project. Managers quickly adopted a tool which gave them some hard facts to go on. With this information they could be proactive.

None of that would have been possible without the version control and the bug tracking systems. They collected the data. The procedures for using them were so well established that over 200 programmers used them on a daily basis.

Who Can Do It

Some of these practices can be implemented by a senior developer acting alone, but to get the real value, they need to become the way that everyone does things. That requires management push.

Each procedure requires extra time when a new procedure comes on line. Developers need to be able to take some time to play with it. They may need to configure tools, or read manuals, or they may make a costly mistake. All this must be taken in stride by the project manager.

Why Bother

There's really only one reason to implement any or all of these procedures: to produce a software product.

These procedures have been shown again and again to be more efficient, more trustworthy, and more predictable than the freewheeling state of software engineering which proceeded their introduction.

Do it for the same reason you use double-entry bookkeeping. The same reason that your human resources department follows interviewing guidelines. Using the proper procedure make sense and saves money.

2003 © Ed Hartnett

Ed Hartnett has managed projects on two continents.
He is a consultant in Colorado.
Please see http://www.telestoconsulting.com/ for more information.
He welcomes comments and questions at
This e-mail address is being protected from spambots. You need JavaScript enabled to view it

Share/Save/Bookmark
Comments (0)Add Comment

Write comment
bold italicize underline strike url image quote Smile Wink Laugh Grin Angry Sad Shocked Cool Tongue Kiss Cry
smaller | bigger

busy
 
Copyright © PROJECTmagazine (c) 1998 - 2019 for practical project management information. All rights reserved.