Gregory M. Kapfhammer

Associate Professor of Computer Science

http://www.cs.allegheny.edu/~gkapfham/

  
View  Edit  Uploads  History  Top  Changes  Search

Chapter 5: Cost of Change




  • Beck and Gamma assert that a certain type of cost of change curve is no longer applicable if certain types of tools, technologies, and methodologies are exploited. What do this curve look like? Is there a certain type of software development methodology that seems to assume the existenve of a cost of change curve of this nature?


Well, first of all, the "old curve" shows a gradual increase in the cost of change as the software lifecycle moves through requirements, analysis, design, implementation, testing, and production. At the production end, the cost of change is very high (even infinite). The methodologies that seem to assume a major increase in the cost of change as the software process comes closer to the production end are the waterfall model and the formal systems development. The waterfall model's problem comes in that to change an issue, all of the steps must be hit before we go back to the step we need to change. Formal systems would be very costly to change once production is hit because so much prerequisite planning and derivations go into the final product that any change may necessitate "going back to formula." Clearly this is highly expensive.

Matt DeNapoli

Brenda Gruber

Beck and Gamma assert that the cost of change curve was exponential over time, but now after improvements in tools, technologies, and methodologies, it appears to have slowed the cost of change down, that is, the further along the curve (the further into software development a design gets, it will cost less to go back an make changes than before.

I think that BUFD (big up front design) is a methodology that supports the original cost of change curve. BUFD suggests that the majority of planning occurs early on and it is difficult to change things the further along the design process you get. For example if a customer changes their requirements or new knowledge is discovered that force a designer to change the requirements it is more costly since the designer will essentially have to start over and go back to the beginning, which will change the desing, implementation, and testing.

  • What are some of the tools and technologies that the authors state will make "change cheap"? Can you think of other items that could be included to make change even cheaper?


The major technology that the authors claim will make change cheap is Extreme Programming or XP. It is a methodology of programming that involves hitting all aspects of a project in little chunks. Also, they point out that reusing objects (stored in object databases) and object oriented programming will also make change cheap. The ideas to flatten the cost curve involve keeping things simple, unit arranged, and object oriented. It can be considered that unit testing may flatten the cost curve, but that is really a part of Extreme programming.

Matt DeNapoli

In order to create this flattened cost of change curve, would we need to adopt all of the practices that are reccomended by XP or could we simply adopt some of these practices? You talked about techologies like OOP, OO databases, and unit testing; but, what about things like pair programming and 40-hr work weeks? What about managerial techniques? Greg

Brenda Gruber
Beck and Gamma claim that "...better languages, better databases, better programming practices, better environments and tools, and new innovations..." will make change cheap. Better technology such as message sending and object databases also help. Other "tools and technologies" might include the actual software designers. Going back to a concept previously brought up in class, maybe all of the new technology by itself isn't the "silver bullet", but maybe the advanced technology along with training better software engineers comes a lot closer.

I propose that the software engineers are themselves, a tool to make the cost of change cheaper. Perhaps it is in their training and education to make the best decisions about a system, sometimes with limited knowledge of the system. This may also include the commincation with the customer about their wants and needs and what is absolutley critical to the software system.

This is a very insightful response. I think that you are right; if we have OO languages like Smalltalk about Java but no programmers that can fluently speak "object-oriented", then it is likely that we will not be able to realize a flat cost of change curve. Do you reccomend any specific types of education of training to realize this cost of change curve? Greg


Link to this Page