RSP&&A;; Web Site: Commentary

Is Software Engineering Dead?

I get dozens of emails each month from users of SEPA, 6/e (and earlier editions). As the book has evolved, I have emphasized a more agile engineering approach, and as a result, readers often worry that discipline may suffer. A professor who has adopted the book emailed recently and made the following observation:

I wrote you before and mentioned that I have been happily using your book as the basis of a graduate course in software engineering … because it had its emphasis on concepts - software engineering is really a formalized common sense - and its broad coverage of topics of interest …

I may be a little more dismissive of major paradigm shifts - not that a lot of ideas coming up over the last twenty years were not very good and potentially useful, but I have not seen a method that can really make software development a no-brainer recipe.

My reaction to [the reemergence of an emphasis on coding as the only real deliverable as evidenced in agile methods] is that this can result in a loss of the requisite documentation to allow the use of the word "engineering". Is it time, after thirty years, to drop Software Development as an engineering discipline?

My response:

First, to answer your implied question – NO, software engineering is not dying … but it is evolving.

The ponderous methodological approaches that we tried over the past quarter century have taught us that:

1) we work in a field in which uncertainty (about user requirements, business needs, methodological approach among others) pervades the process from front to back;

2) there is NO silver bullet (as Fred Brooks said many years ago) – therefore methods alone, no matter how good, are NOT the answer to effective software development;

3) all problems are people and management problems and too few software developers have the knowledge or inclination to deal with them effectively (that’s why so many projects get into trouble);

4) every generation of software developers thinks that the “old school” is, well, old, and inapplicable to the work they do (they are wrong, of course, but you can’t convince them of that).

However, having said all of this, each generation brings excellent new ideas to the table. As this happens, older ideas are sometimes jettisoned or modified, processes are transformed, and a few new methods are inserted, but the engineering discipline remains (read SEPA, 6/e, p. 468 where I quote myself on this issue).

I do believe that an agile approach is a good one, but I’m not dogmatic about XP or any other agile method, and I don’t denigrate those who prefer traditional SE paradigms. Whatever works!

I do believe, as well, that we must continue to be disciplined in the way we build software. Very bad things happen if we’re cavalier about it. But “discipline” does NOT translate into ponderous, or document laden, or method specific. It does mean that we must do the core things (analysis, design, construction, testing, QA, etc.) well.

Home About us Products Product Models SE Resources Commentary Contact us
Web site and all contents © 2006, R.S. Pressman & Associates, Inc.
All rights reserved.

Free website templates


	*Is Software Engineering Dead?* I get dozens of emails each month from users of SEPA, 6/e (and earlier editions). As the book has evolved, I have emphasized a more agile engineering approach, and as a result, readers often worry that discipline may suffer. A professor who has adopted the book emailed recently and made the following observation: I wrote you before and mentioned that I have been happily using your book as the basis of a graduate course in software engineering … because it had its emphasis on concepts - software engineering is really a formalized common sense - and its broad coverage of topics of interest … I may be a little more dismissive of major paradigm shifts - not that a lot of ideas coming up over the last twenty years were not very good and potentially useful, but I have not seen a method that can really make software development a no-brainer recipe. My reaction to [the reemergence of an emphasis on coding as the only real deliverable as evidenced in agile methods] is that this can result in a loss of the requisite documentation to allow the use of the word "engineering". Is it time, after thirty years, to drop Software Development as an engineering discipline? My response: First, to answer your implied question – NO, software engineering is not dying … but it is evolving. The ponderous methodological approaches that we tried over the past quarter century have taught us that: 1) we work in a field in which uncertainty (about user requirements, business needs, methodological approach among others) pervades the process from front to back; 2) there is NO silver bullet (as Fred Brooks said many years ago) – therefore methods alone, no matter how good, are NOT the answer to effective software development; 3) all problems are people and management problems and too few software developers have the knowledge or inclination to deal with them effectively (that’s why so many projects get into trouble); 4) every generation of software developers thinks that the “old school” is, well, old, and inapplicable to the work they do (they are wrong, of course, but you can’t convince them of that). However, having said all of this, each generation brings excellent new ideas to the table. As this happens, older ideas are sometimes jettisoned or modified, processes are transformed, and a few new methods are inserted, but the engineering discipline remains (read SEPA, 6/e, p. 468 where I quote myself on this issue). I do believe that an agile approach is a good one, but I’m not dogmatic about XP or any other agile method, and I don’t denigrate those who prefer traditional SE paradigms. Whatever works! I do believe, as well, that we must continue to be disciplined in the way we build software. Very bad things happen if we’re cavalier about it. But “discipline” does NOT translate into ponderous, or document laden, or method specific. It does mean that we must do the core things (analysis, design, construction, testing, QA, etc.) well.