wmb@MITCH.ENG.SUN.COM (02/21/91)
> Unfortunatly, coding is 20% of > the effort that goes into building a software product. The rest > is specifications, design, testing and acceptance. Eric speaks a mouthful. And then, after the software product is built, the next 80% of the project involves support and maintenance. One of the serious problems with using Forth for a "real" project is figuring out who is going to support it after the original implementors are gone. After finishing most of the coding for Sun's Forth-based Open Boot PROM firmware, I basically spent an entire year building a team to carry on with support and enhancements. This problem can be solved (I did it), but it requires dedication, perseverence, and a willingness to accept a fair amount of risk. Mitch Bradley, wmb@Eng.Sun.COM
cwpjr@cbnewse.att.com (clyde.w.jr.phillips) (02/22/91)
In article <9102211535.AA22605@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM writes: > > Unfortunatly, coding is 20% of > > the effort that goes into building a software product. The rest > > is specifications, design, testing and acceptance. > > Eric speaks a mouthful. And then, after the software product is built, > the next 80% of the project involves support and maintenance. > > One of the serious problems with using Forth for a "real" project is > figuring out who is going to support it after the original implementors > are gone. After finishing most of the coding for Sun's Forth-based > Open Boot PROM firmware, I basically spent an entire year building a > team to carry on with support and enhancements. This problem can be > solved (I did it), but it requires dedication, perseverence, and a > willingness to accept a fair amount of risk. > > Mitch Bradley, wmb@Eng.Sun.COM I strongly suggest everyone who wants to work with FORTH and wants it's use to be successfull really think about this thread. My experience is the successful FORTH products I've produced have FORTH as the LCD and code-debugged-and-ready-to-go0under-budget-with-all-creeping features-reasonably-implemented-and-documented-for-future-maintaninance base, but as said above that's only 20% or so of the deal. This is the secret of why an academic travesty like C can be used dispite itself. Really. FORTH's "superiority" or barring that it's elegance doesn't make THE difference. Really. The rest of my experience of successful FORTH projects means that I demonstrated that I could train good people to be good FORTH programmers "on-the-fly" ( ie they could be useful at all levels of expertize if supervised adequately ). These people then ideally would be instructed by me as to how to clean up rough spots and look at the objects we've created and refine them, as a part of their normal work tasks. Save some memory here, some execution time here, some better factoring there, etc. The essence is you want someone who wants to discover your "rhymm&reason", facilitate it and be able to carry on when you are gone and NOT be like the std consultant who CAN'T (because or ego or your mees) pick up on what you've done, why, and where to go with it. Custom Versions, DOG&PONY and all the rest become something the organization starts to shine at. Not to mention customer satisfaction with quality and turn-around-time. But all these issues point to more than just tolerant or worse, "in-the-dark" management. These guys have to be on board. They have to understand the advantage you provide with your use of FORTH, the migration path you have planned to not dead-end their products and the non-issue of readily available FORTH programmers. The only critical thing beyond mgmt is your ability to determine who is a good candidate for FORTH and who is not. If you can choose these people to be on your team, and the mgmt knows your plan and supports it then you will be in a win/win situation. This is what the 80% is about. Clyde P.S. Thanks for stating this Mitch.