A few weeks ago I worked with some people in my organization on a system problem. They had built a functioning system, but they then made a change that broke it. The solution to the problem was a return to fundamentals - something we seem to forget.
The original system had two parts. One part - the monitor - monitored an environment and transmitted data from the environment back to the second part - the processor. The processor processed the data for the users. The processor also served as a remote control for the monitor.
The trouble began when our system engineer and the users added a third part - a mobile controller. This acted as a second remote control. The mobile controller allowed the user to control the monitor while moving about, i.e. while not in the control room where the processor resided. Extensive testing showed that the processor would reset the monitor after the user had commanded the monitor with the mobile controller. The two remote controllers where battling each other and confusing the monitor.
We did three things to address this situation. First, I gathered all the stakeholders in one room at one time. This included the company that built the monitor and the mobile controller, the company that built the processor, the system engineer, and a facilitator.
The second thing was to work through the problem. Everyone was anxious to suggest solutions, but what worked was the facilitator kept asking, "Why are we doing this? Why do we want a mobile controller?" In other words, "What are the requirements?" Once they agreed on the requirements, they only needed 15 minutes to agree on the solution.
The third thing was to draw a state transition diagram for the system. In a state transition diagram a labeled circle represents a state the system is in such as "Monitoring," "Sleep," or "Collect and Transmit." When something enters the system, such as a command from the user, the system transitions from one state to another.
The state transition diagram showed us that with two controllers the monitor could be stuck in an undesired state. We could list each combination of events that would cause these hung states. Once again, we could see the solution to our problems.
I felt both elated and dejected. I was elated because we were well on our way to solving the problem and deploying the system. I was dejected because we should not have had this problem. All we did was hold a meeting, understand the requirements, and draw a state transition diagram. Those are fundamentals; why hadn't the system developers used them?
I think most IT managers share this experience with me. Consider two questions: (1) Do you have any problems with any systems you are building or maintaining? (2) Are you and your people using the fundamentals you learned long ago? Please be candid with your answers. I think they are (1) yes and (2) no.
Most people I have observed, including myself, tend to drift and forget. We are busy, in a hurry, and we don't take the time to reach for a dusty old text book that helped us learn how to do something fundamental. Instead, we try to save time and just "figure it out."
I recommend three things. First, review some fundamentals. I learned how to draw state transition diagrams in college in the late 1970s; they still work. Tom DeMarco wrote about structured analysis in the late 1970s. Regardless of how many times people tell us to think about objects, patterns, extreme agility, and web enabled whatever, structured analysis still works. These two fundamentals may not fit your situation, but you can probably think of ones that do.
Second, consider the problems that you and your people are facing today. Many other people have faced them many times. Their high frequency of occurrence produced the fundamental tools and techniques that we often neglect.
Third, try applying the fundamentals to the problems. I think that your results will be similar to mine - elation, dejection, and a renewed interest in some old fundamentals.
Dwayne Phillips has worked as a software and systems engineer with the US government since 1980. He co-authored "It Sounded Good When We Started" with Roy O'Bryan and authored "The Software Project Manager's Handbook, Principles that Work at Work," both from the IEEE Computer Society. He has a Ph.D. in electrical and computer engineering from Louisiana State University.
Dr. Phillips can be reached at d.phillips@computer.org.