There is one other tendency of engineers that I have observed throughout the years, and it is something to watch out for. When you go to them with a problem, they tend to view it in the most general light. That is, they naturally assume you want "the whole problem" solved. Sometimes this is colloquially referred to as DC to daylight, because in electrical engineering, the frequency spectrum can go from zero (direct current) to infinity, which is actually well past that of visible light!
Now this is a problem for two reasons. First of all, solving a problem over the entire range of the parameter set is usually much harder than solving it over some restricted region of that same parameter set. In some cases, in fact, it may be impossible to solve generally, while being quite tractable over some limited range. So the engineer may throw up his hands in dismay until you specify that you actually only need a solution over some finite range of interest.
The second problem is more insidious. The problem may or may not be generally solvable, and the engineer may or may not be capable of that solution. In the worst case, he thinks it is solvable and tries to do it only to find out he was wrong, either because it wasn't solvable or he wasn't capable enough. This turns out to be very expensive.
Finally, there is the case where the problem is generally solvable, the engineer is capable, and he produces the golden nugget. Unfortunately, it takes way too long and is way too expensive. You just needed part of what he accomplished, one-tenth the result at one-tenth the price. He will be proud, and you will have a bittersweet taste in your mouth.
The only way to avoid this dilemma is careful discussion during step one and step three as to what the problem really is, and how much of a solution you can afford is an inevitable part of step four. So you have multiple passes at avoiding this pitfall. Remember, in the business world it is usually unprofitable to build a $50 fence to keep in a $10 horse.
Not every software engineer you will run across will be amenable to the protocol described in this chapter, because engineers are individuals and one size does not fit all. On the other hand, I've found that this approach works in a vast majority of cases, so it always makes a good default starting point.
In the next chapter, I turn to the follow-on to step four. In that step, we believe we have a commitment from the engineer to do something by a certain date. We will be successful or not depending on whether that commitment is met. This fundamental paradigm is further explored in Chapter 15.