Everyone thinks of the word paradigm as a way to describe how programming languages work. Can we also use it to describe how the whole process of software design is organized and managed?
. . . . . . .
So, what exactly IS a paradigm?
Like Alanis Morisset's broad use of the word "ironic", I know it's technically correct to call object oriented programming a programming paradigm, I also know there is a lot of real disagreement on how the word "paradigm" should be used.
Anyway, for me, "paradigm" is more like what you have when you strip away all the recognizable physical world objects from a metaphor. It is a frame of reference, taking some well-understood norm from current-day social and vocational practices and using it to generalize into a newly discovered area. That way we don't have to grope around so much to find useful new relationships. In other words, a paradigm is laying something we understand well on TOP of some new thing we don't yet understand well in order to accelerate our understanding of the new thing.
. . . . . . .
Ok, The Point
In this narrower sense of the word, there have been many undocumented paradigms applied to the craft of software design. Some that I've seen in my days as a software developer include those represented in the following metaphors:
- Software design as the manufacturing process itself (component assembly)
- Software design as development of hardware to be manufactured. (machine design)
- Software design as knowledge recordings.
- Software design as business consulting services
- Software design as a martial art (e.g. programmers who refer to themselves as extreme "masters". Careful, don't let these boys bate you).
- Software design as building/skyscraper architecture.
The first two are what object oriented programming methods have embraced and have attempted to cater to and simulate. IMO, these two are based mainly on what amounts to wishful thinking by suits. They are at best a forced fit with what the practice of software design actually is.
In light of this, it is not the least bit surprising to me that people who are heavily invested in the first two paradigms will try to blame things like pointer-use for unusually high numbers of defects in software designs. If you're trying to force fit an inadequate paradigm over your process, you may as well blame defects on how the water flows in an Egyptian river.
. . . . . . .
A Paradigm Named Six
In my experience, while number 6 is still a forced fit, it is the best of this group at representing the actual practice of software design. For example, to design a skyscraper:
- an architect must consider the environment the skyscraper will be deployed into
- How it will affect and interact with other skyscrapers around it.
- How it will affect and interact with older buildings and infrastructure
around and under it.
- How it will affect the people who use the existing infrastructure and
- How it will be perceived by people who use IT daily
- How it will be perceived by people who visit IT occasionally.
- an architect must be concerned with accessibility and aesthetics
- an architect must be intimately knowledgeable about a myriad of:
- Materials such as steals, glass, cements, wiring, ducting, marbles,
- Components: Everything from air conditioners to lifts and sprinkler
- Construction methods
- An architect must understand management and financial issues:
- In the case of the larger buildings community planning, etc.
- Observation: Perhaps, the craft of making buildings has in some small way
actually benefited from
the fact that when mistakes are made, buildings fall down (ok, this
has very little to do with anything, i admit).
. . . . . . .
So What Am I Saying?
This is not really a call to begin thinking about software design in terms of building design which has its problems. IMO, like many paradigms taken from physical-world metaphors, it suffers from one big problem, that memes are not objects.
This is really a call to take back the word paradigm, so we can begin to attach names to these things that have been used to organize the software design process. They have been affecting us in our craft on a daily basis, and should be a point of consideration when analyzing defect and functionality trends.
Last modification: JRepici - 05/20/03 at 10:55:07