Re: OOP - a question about database access

"Uncle Bob (Robert C. Martin)" <u.n.c.l.e.b.o.b_at_objectmentor.com> wrote in message news:6b7lqvgajitik3qnseegf8t1afs6gep9fb_at_4ax.com...
> Tak To <takto_at_alum.mit.edu.-> might (or might not) have written this
> on (or about) Wed, 05 Nov 2003 20:39:45 -0500, :
>
> >It seems to me that these managers have confused features with
> >tasks. Using the analogy of a building: these managers think
> >they can schedule construction by rooms, thereby ignoring
> >tasks such as pouring the foundation, laying down the pipes
> >and ducts and pulling the wires.
> >
> >Translating featuers to tasks is often non-trivial. Most
> >managers lack the necessary skillset and that is often why
> >they become managers instead of architects or independent
> >consultants.
>
> I have found, over the years, that the building analogy just doesn't
> work for software. In software it really *is* possible to lay the
> foundation after part of the building is up. The costs of doing
> things "out of order" is so much smaller than in construction work,
> that the term "out of order" becomes nearly meaningless.
>
> I have seen the database ripped out of an application and replaced
> with very little effort. I have seen a system that worked on one
> computer turned into a distributed system working on many computers
> with very little effort. I have also seen systems in which even the
> tiniest change is a nightmare. What differentiates these two kinds of
> systems is the care taken with the code. If the code is clean and
> well ordered, the system is flexible. If the code is supported with
> sufficient unit tests and acceptance tests, the risk of changing it is
> greatly diminished.

I don't think it is the building analogy that is inappropriate but the way it was used in this case. The assumption that one cannot add a foundation after a building is built is simply wrong. Four houses down the street from me, my neighbour is doing that right now. He dug a basement under an existing house, poured a foundation and is now extending the house with an addition. He is the second neighbour in my neighbourhood to do so, and one family legend involves two of my father's uncles at a time when one of them was digging a basement by hand under my great-grandfather's house.

The pace of software development is much faster, and software is much more malleable than bricks and mortar, but the analogy is reasonable in some contexts. By the pace of software development, I mean the complexity added per unit time. A programmer can implement greater complexity in a few moments than an electrician can implement in a day. By malleability, I observe that a programmer can perform the equivalent of replacing an entire wing of a building in a day, and programmers often do.

The faster pace, greater malleability and complexity increase the risk of error while allowing expectations to soar far beyond the expectations placed on builders. A major building project will spend years just in planning, while people will expect a handful of developers to deliver a comparably complex finished product in a few months from conception to completion. Received on Thu Nov 06 2003 - 20:48:33 CET