Re: Comparison and criteria of design quality
From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 09/13/04
- Next message: Universe: "Re: Is this the DIP confusion?"
- Previous message: Robert C. Martin: "Re: Distributed applications and OOD"
- In reply to: Dagfinn Reiersol: "Re: Comparison and criteria of design quality"
- Next in thread: Dagfinn Reiersol: "Re: Comparison and criteria of design quality"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 13 Sep 2004 15:16:45 GMT
Responding to Reiersol...
>>>> Alas, software development is still in its infancy so it is probably
>>>> still more art than science.
>>>
>>>
>>>
>>>
>>> I think *all* design activities are more art than science. Even
>>> though there are mathematical design principles for mechanical or
>>> electrical engineering, there are still very artful designs.
>>
>>
>>
>> Sure, there is design creativity in every discipline. But that's a
>> matter of degree.
>>
>> To paraphrase Edison, <mature> engineering in 1% <artful> inspiration
>> and 99% perspiration. Unfortunately software development is not
>> mature, so the percentages are more like 70% artful inspiration and
>> 30% perspiration.
>
>
> In software development, we have the ability to automate the
> "perspiration" activities, so it might never be down to 1% inspiration
> no matter how "mature" the field becomes.
My point here is that we don't do nearly the amount of automation of
design activities that we could. In mature disciplines most of the
deterministic stuff has been automated through standards, design
practices, and tools.
For example, the entire computing space is highly deterministic because
it must all map into the rigorous computing models of Turing, von
Neumann, et al. So all the design effort around nonfunctional
requirements that depends upon a particular computing environment should
be reusable for all applications that execute in that environment.
Yet it isn't. Developers are still mucking around with 3GL code
resolving problems that have been solved literally millions of times
before. It's like expecting circuit designers to determine land routing
or having MEs do stress calculations to determine what bolt to use.
Meanwhile, general purpose translation technology, where the application
functional solution is described in just an OOA model and a translation
engine resolves nonfunctional requirements during full automatic code
generation, has been available for two decades.
And don't get me started on the processes around the A&D. In mature
engineering disciplines those processes are highly structured and
repeatable while the software development processes are largely ad hoc.
>
> And I wonder, will it ever be "mature", or does it have the ability to
> produce ever-new challenges that we lack "mature" ways of handling?
Eventually, yes. Automation of the computing space is inevitable. When
I started out in this business my first program was on a plug board.
There wasn't a linker or loader in sight and BAL was the Silver Bullet
De Jour that was solving the Software Crisis. It just takes time.
<flame ON>
If the previous paragraphs sound a bit bitter, it is largely because of
experiencing that history. The frustration I have is that the lessons
of history in both other engineering professions and software itself are
being largely ignored.
Most software developers are memebrs of the Cult of Creativity. Somehow
software development is a unique intellectual exercise is unlike any
other engineering design activity. In addition, creativity is required
at every level of abstraction and in every facet of the effort. Thus we
must hand-craft everything and the craft is complex and difficult to
master, making its practitioners very Special. (Never mind that
12-year-olds who can barely spell C are hacking into DoD.) So a lengthy
apprenticeship is required on a personal odyssey to reach the stature of
a High Priest. Things like standards and design practices are regarded
as heretical impediments to creativity along the True Path. The whole
bloody industry is medieval.
<flame OFF>
In fact, I foresee the time when requirements specifications will be
sufficiently rigorous and will have appropriate notations so that the
software can be "compiled" directly from them. (This is already true
for the niches, such as electronic test specification -- the ATLAS test
specification standard, IEEE 716, that is routinely compiled directly
into a full test program.) Then all the art will lie in creating the
requirements specification.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH
- Next message: Universe: "Re: Is this the DIP confusion?"
- Previous message: Robert C. Martin: "Re: Distributed applications and OOD"
- In reply to: Dagfinn Reiersol: "Re: Comparison and criteria of design quality"
- Next in thread: Dagfinn Reiersol: "Re: Comparison and criteria of design quality"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
