chris@ankh.ftl.fl.us (Chris Bare) (03/02/91)
In a previous article, Second System Effect was defined as: > Brooks was talking about designing a new (second) system, > not evolving an existing one. The difference is that in SSE one > designs an overly complex beast from the beginning, rather than having > the beast acquire a kitchen sink as it evolves via CF. CF (I've also heard it referred to as requirements creep) is rampant in the industry, but until I started following this discussion I thought SSE was the solution. Meaning that if you stop and think about what you would like the product to do, even if you don't have time to get it all in now, you're in a much better position to get in in later. Is there a flaw in this logic? (other than the assumption that management would ever give you time to stop and think:-) I have worked on many systems (especially the larger ones) which made basic assumptions in the early design and implementation that made new features very difficult to implement. For example, one system involved database update screens, and the assumption was that you would only ever address one table at a time. As features were added, it became apparent that it would be nice to update several tables at once. Granted, this was a bad assumption, but it was based on the requirements at the start. My point is that if it had been planned out more the basic design could have been different without drastically affecting development time. Now development time will basically double because everything done for single tables must now be done for multiple tables. I don't see how OO addresses this problem in any substantial way either. It should help address the problem of fixing A and breaking B du to it's encapsulation. Enhancing base classes may also serve as an easy way to add functionality in certain cases, but even in OO you can make bad assumptions by being short sighted. Chris Bare chris@ankh.ftl.fl.us CASI-RUSCO