Re: What databases have taught me

topmind wrote:
> Dmitry A. Kazakov wrote:
>

>>On 25 Jun 2006 16:59:44 -0700, Marshall wrote:
>>
>>
>>>topmind wrote:
>>
>>>>I suggest you try to focus on more practical issues, such as comparing
>>>>solutions to realistic scenarios rather than get bogged down in a
>>>>definition battle. When software design is turned into a science rather
>>>>than an art, then revisit definitions. Until then, stop bickering over
>>>>art.
>>>
>>>I think the idea of software as art is something of an
>>>anti-intellectual one.
>>
>>"Irrational" would be a better word. There exist quite intelligent artists,
>>you can't deny it.
>>
>>To understand software design rationally is an intellectual challenge for
>>CS. Calls to give up, to remain artisans, "reflexive developing" indeed
>>smell anti-intellectual.

I read the article. Regarding the comments on computer science, I think that the reason for the name hasn't been explained to the author.

Computer science is no more like chemistry or physics - the "hard" sciences he mentions - than political science is. But it's not supposed to be. Computer science, like political science, is a scientific approach to the study of solutions to problems that the respective practitioners try to solve. That's where the science is.

Some of the problems have no optimal solution. The scientific approach allows us to evaluate alternatives and collectively decide which solutions appear to be fundamental; i.e., as good as they can be. So far. Given as much as we know. The author is aware of this but doesn't seem to know how to judge the relative merit of alternatives.

Well, it can be done. And the trade-offs he cited in the software development process have analogues in the "hard" engineering disciplines he refers to. The mechanical engineer's make-or-buy decision is an excellent example; rather than put people to work fabricating custom fasteners. he goes to the catalog and selects parts that are good enough for the job. Chemical engineers do the same thing: there are often several process available that produce the same product; evaluating which of the alternatives is best for the problem at hand depends on a variety of criteria.

As for a rational approach to software design: a description of the desired product must be expressible; this constitutes the specification. The specification, in turn, must be satisfiable, deterministic, and implementable. Not all specifications are and we're left with the obvious conclusion that not all activities should be automated. Even many of those that could be, shouldn't be.

> Spoiler:
>
> "This nearly infinite flexibility of software, I have concluded, is why
> objective software design evaluation is nearly impossible: there is no
> objective reality inside software. This is the secret cause of all the
> debate headaches. We might as well be a bunch of loonies in the mental
> hospital arguing over which one of us is the real or best Napoleon. The
> difference is that in cyberspace we *can* all be Napoleon....."

The difficulty, I believe, lies in the fact that there are very many objective criteria. Unlike other things that humans build, software has many, many of them. In some circles, these comprise the taxonomy of abilities: software can be affordable, configurable, extensible, maintainable, scalable, reliable, capable, usable, predictable, flexible, deployable, accessible, &c. (I've got a list somewhere that names more that 20 of these things.)

Very few other things we build have so many possible design criteria. For most things, we can tell the customer, "You can have it good, cheap, or fast: pick no more than two." And nothing is as frustrating as having a customer bring a late requirement to the party saying, "Well, any *good* software would be _______ [pick one of the above]; it's so obvious that it needn't be mentioned."

In the case of software, there are many more than "two out of three" choices available. But each of these potential criteria can be identified and measured. Not always easily, but it can be done.

There's a lot more that can be measured than execution time.

>>-- 
>>Regards,
>>Dmitry A. Kazakov