< Continued from page 2

Programming
   The coding step. This is the one most people understand.

While you work on the design, you should look for functions that can be placed into their own code procedures. Look for things that seem like they are a black box. A black box is a function that can be completely described using only information about what goes in and what comes out. The only thing you care about is providing the input and getting the result.


Knowing how to recognize these is a golden skill in analysis.

An example of a black box might be a tax calculation in an accounting system. The government defines these calculations and they can and do change a lot. A system might use exactly the same tax calculation in a lot of different places. But since you only care about passing amounts into the calculation and getting the right result back, it's a black box. If a large system needs a tax calculation in fifty places and the government passes a new law, would you like to change the program in fifty places or just one?

If you've done everything perfectly up to this point in the project, this is where it starts to really pay off. In an ideal project, the designers can simply hand the specifications to talented programmers and the new system will roll out like a train down a track.

But the real world is seldom like that.

This does point to one big reason why companies are willing to pay a lot for very good analysis and design. There's a lot of incentive these days to have the programming done by teams of developers that might not even be in your part of the world.

Programming shops in Asia, South America and other parts of the world have specialized in building systems based on design specifications and they're good at it. Depending on where you are in the world, you might have different opinions about whether this is a good or bad thing, but the fact is that it's a growing trend and regardless of where you are, you should know and understand it.

If you have created your design documents correctly, you can program the system using a technique sometimes called top down structured programming. This name is out of fashion today, but I believe that OOP, or Object Oriented Programming, is a logical extension of these fundamental ideas. It was a great idea when it was first invented and it still is.

The basic idea is to code the "top" parts of the system - the overall interface and control functions first. The smaller "black box" objects are represented by program "stubs" that don't actually do anything. To use the earlier example of a tax calculation, a "stub" might just return a random value no matter what was passed to it. In this way, you can code and test the "top" functions first and perhaps even find problems in the overall design earlier when they can be fixed a lot more easily. The "bottom" functions then become the "objects" in your Object Oriented system.

Another reason for doing it this way is that as you code the "top" you often find more parts of the code that can be pushed down into objects. And that's a good thing!

Implementation
   The system is placed into production.

Maintenance
   Nothing works forever. Times change and so do software systems.

The real challenges of implementation are usually not technical. They usually have more to do with helping people understand and feel comfortable with the new system. The two things that will help you most here are first, that hero who got the system going in the first place: the system "owner" and second, great documentation. Great documentation doesn't have to be printed. Sometimes it's online tutorials or an automated help system, for example.

The most important thing to remember in implementation is, "Know your customer!" It doesn't matter how good your system really is. If your customer thinks it stinks, then it stinks. Your customer really is right. (Really!)

Maintenance is often left completely out of discussions about systems development and, quite frankly, that burns me up. In my view, software development has long had a totally unjustified view of maintenance programming as a place where you can stick junior programmers or ... ahem ... people with "lower skill levels".

I was a supervisor of maintenance programming before I became a new development project manager and I learned that maintenance is where the entire software development function lives or dies in most organizations. The people who fix it when it's broke are the ones who eventually understand a system best. They're the most reliable and knowledgeable even when it comes time to replace the system with a new one. They're the ones that you have to depend on when tons of money are being lost for every second the system is down.

And they often have to do their magic after being pulled out of bed at 3 in the morning.

In fact, the main reason new development sometimes has more prestige is that they get to play with all the new toys and they often get the biggest share of training. Sometimes, the world just ain't fair!

If I could wave a magic wand and change just one thing about the way programming is done, it would be to put maintenance programmers at the very top of the salary and prestige heap in programming shops.

But enough of talking about it. On the next page, we write code that takes the first step toward Object Oriented programming.