accesses since April 2,1996
copyright notice
accesses since April 2,1996
ON SOFTWARE ARCHITECTURE
For those of us old timers who have grown up developing software for one purpose or another, it is useful from time to time to reflect on accomplishments past and try to make sense of it all. This is one of those moments for me.
I know some things now that I didn't know when I started my career. First and foremost, I now understand that software engineering and design is not now, and will most likely never become, an engineering discipline. Peter Denning, Terry Winograd, Mary Shaw and others have argued convincingly I think that the appropriate model for software developers and practitioners is architecture and not engineering. The proposed certification in software engineering that rears its head from time to time seems out of touch with reality.
Here is the Denning side of the argument in short form. A discipline must meet three criteria: (1) it must be based around a rigorous, well-defined body of formalisms, (2) it must have a codified set of standards and practices, and (3) its practitioners must routinely and reliably fulfill their commitments to their community. Simply put, software engineering and design do not qualify as a discipline by these criteria. If it is held up against an engineering model, it will probably never become one. In engineering disciplines, projects begin with design specifications and conclude with something tangible (a product, artifact, system, mechanism, or environment). The specifications propel the project. Once agreed to by all parties, modification of objectives and goals is discouraged.
The exact opposite is true of software engineering and design. In this case the design is always incomplete, rarely codified and a continuous dialog with the end-user/consumeris is considered essential to the health and well-being of the project. Furthermore, there is nothing tangible produced. The end product, the program, is considered the starting point in a succession of modifications and refinements which may ultimately lead to a product which bears little or no resemblance to the original program.
Denning and the others have suggested that software development would become more structured and refined if it were modeled after architecture. Software engineering and design could begin with a 'software rendering' (perhaps an interface prototype) which would evolve into a 'software blueprint' (kernel pseudo code). This sketch would then be shared with the 'software contractors' who would transform the blueprint into production code. It is understood that alterations to the blueprint are made continuously based upon feedback from the sponsors/consumers. Although some aspects of the blueprint are expensive to modify, none are considered sacred. Modules come and go like closets and bay windows.
It is worth thinking about this new software architecture paradigm. It seems to make sense of much of what we have been doing for many years.
On the lighter side, I conclude by sharing with you some definitions of key terms in software engineering and design which I have collected over the years.
field tested =df someone got the code to compile
all new release =df it's not backward compatible
pc compatible =df it works on Bill's 486dx and my laptop
performance proven =df no one has been able to find the bugs yet
next generation software =df won't work with your existing
software
unrivaled performance =df almost as good as our competitors
easy-to-use interface =df we couldn't afford to add many features
free, 1-yr maintenance =df help us debug this monster
will ship in the 3rd quarter =df we hired our first programmer last week
state-of-the-art =df a mistake carried through to perfection
Have a good summer!