Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
This is absolutely true. In software design: A good set of specs will reduce programming time and testing time. One of the problems that causes serious delays is design flaws. You have a decent plan and design, but the design contains a serious flaw. The programmers implement according to the spec. The testers test to the spec. Product is shipped on beta test, customer finds a serious bug. The programmers find that this bug is evidence of a design flaw, and must make some major changes to the product. The product that I worked on the past 2 years was a porting project. We planned it around an existing tool. One of the limitations of the tool was well known to us and our management, and was communicated to the company whose product we were porting. At some point, that company decided that they could not live with that limitation, which was a fundamental limitation of the tool. The end result was that we (our group, the tool people in Nashua, and the Alpha chip design people) came up with a workable idea. This required significant changes to the tool (which engineering management supported) and significant changes to our approach, which required restructuring much of what we had already done. The flaw was communication between the engineers here and the engineers at our customer in Palo Alto. Another problem is that classical programmers want to start writing code immediately. In any case project management is not a panacaea. Many things can go wrong, but a good plan, a good set of specs, and the proper allocation of resources (if the project is going to be written in C, get C programmers not ADA programmers). On 18 Jul 2002 at 16:22, Derek D. Martin wrote: > Right from the start you were doomed to fail, because your functional > spec was useless. Software engineering design principles depend upon > having a well-stated (and well-understood) functional specification... -- Jerry Feldman <gaf at blu.org> Associate Director Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |