System-level design is all about thinking early and implementing later. So why not apply what we already know? We even have statistics. Fifteen years ago, I was part of projects where we measured how effective methods like manual code inspection were in preventing bugs from propagating into the next project phase.So what do you do? Prototypes for one. And not just hardware. Software too. Sometimes it is only in the process of implementing a solution that you come up with a better idea. How do you make sure that idea does not wind up on the drafting room floor? Delay the decision to commit big resources to the last possible moment. Which means a manager must not only be a master of technology. The manager must also be a master of logistics and the PERT Chart.
Everybody seems to know and agree that it becomes more difficult to find and fix defects the further a project has progressed. More recently, studies sponsored by NASA show that an embedded software bug introduced in the requirements phase is 130 times more expensive to fix during integration and 368 times more expensive after rollout of the embedded device.
You also have to recognize the pressures to decide quickly: top management asks, "what is your plan?" and you have to say "I don't have one yet, I'm looking at the options." It requires a lot of trust. And a lot of program time discipline when it comes to execution because you will be using a lot of your project time margin to make sure you get it right the first time.
Posts
4 comments:
This summer at a Workshop on Technical Debt it occurred to me that the phenomena we called "technical debt" was due to the fact that the cost of fixing an error is monotone increasing with time. Any development project has multiple opportunities to make mistakes. Each mistake festers and the cost of fixing it increases with time.
In a waterfall model, the time available for mistakes is maximal at requirements time. IMHO instead of focusing upon avoiding or precluding errors in requirements, we should focus upon verifying, catching, and fixing every decision as soon as possible. Have I mentioned that I drank the Test-Driven Development kool-aid?
Steve,
I have been programming in FORTH since about 1980. I drank that Kool-Aid a long time ago.
omg.. I remember asking a question in my COBOL class about the upcoming year 2000 in 1989 when we were doing our coding! lmao. omg.. you'd think.. the world had just come to an end. My teacher assured me.. that the government would have a plan.. and they had plenty of time to work on it! lol.
I sometimes wonder.. if I should have invested in the fear mongering of making a fast buck on the hysteria that followed.. and can sleep very well at night.. KNOWING.. that I did NOT!
Time.. it's always messing with computer programming. Why is that? lol
Momma,
I was doing non-Y2K work for an aerospace company. Since I was a contract engineer I was able to negotiate a very nice increase in compensation due to the dearth of programmers and engineers caused by the Y2K scare.
I still sleep soundly. Even at my inflated rates the company made a $10 million profit on my work. And that is just the quantifiable number. They also avoided a very large cost overrun that would have happened if I had been unable to figure out how to cut a year off the schedule.
Post a Comment