Wouter van Ooijen wrote:
>  One technique of locating the source of a problem is
> a kind of binary search: disable part of the program (or hardware), if
> the problem disappears you focus on that part and disable a smaller part
> of it, if it persists you re-enable that part and look elsewhere. I
> found that this technique failed me more often than I expected,

On a related note from:

http://msdn.microsoft.com/library/default.asp?url=3D/archive/en-us/dnaruml/=
html/msdn_visualmod.asp

=85 If you want to build a doghouse, you can pretty much start with a
pile of lumber, some nails, and a few basic tools such as a hammer, a
saw, and a tape measure. In a few hours, with little prior planning,
you'll likely end up with a doghouse that's reasonably functional, and
you can probably do it with no one else's help. As long as it's big
enough and doesn't leak too much, your dog will be happy. If it
doesn't work out, you can always start over, or get a less demanding
dog.

If you want to build a house for your family, you can start with a
pile of lumber, some nails, and a few basic tools, but it's going to
take you a lot longer, and your family will certainly be a lot more
demanding than the dog. In this case, unless you've already done it a
few dozen times before, you'll be better served by doing some detailed
planning before you pound the first nail or lay the foundation. At the
very least, you'll want to sketch out several ideas of what you want
the house to look like. If you want to build a quality house that
meets the needs of your family and of local building codes, then
you'll need to draw some blueprints as well, so that you can think
through the intended use of the rooms and the practical details of
lighting, heating, and plumbing. Given these plans, then you can start
to make reasonable estimates of the amount of time and materials this
job will require. Although it is humanly possible to build a house
alone, you'll find it to be much more efficient to work with others,
possibly subcontracting out many key parts or buying prebuilt
materials. As long as you stay true to your plans and stay within the
limitations of time and money, then your family will likely be
satisfied. If it doesn't work out, you can't exactly get a new family,
and so it's best to set expectations early and manage change
carefully.

If you want to build a high-rise office building, it would be
infinitely stupid for you to start with a pile of lumber, some nails,
and a few basic tools. Since you are probably using other people's
money, they will demand to have input into the size, shape, and style
of the building. Often, they will change their minds, even after
you've started building. You will want do to an extensive amount of
planning, because the cost of failure is high. You will be just a part
of a much larger group responsible for developing and deploying the
building, and so the team will need all sorts of blueprints and models
to communicate with one another. As long as you get the right people
and the right tools and actively manage the process of transforming an
architectural concept into reality, you will likely end up with a
building that will satisfy its tenants. If you want to keep building
buildings, then you will want to be certain to balance the desires of
your tenants with the realities of building technology, and you will
want to treat the rest of your team professionally, never placing them
at any risk or driving them so hard that they burn out.

It's a curious thing, but a lot of software development organizations
start out wanting to build high rises, but approach the problem as if
they were knocking out a dog house.

Sometimes, you get lucky. If you have the right people at just the
right moment in time and if all the planets align properly, then you
might, just might, get your team to push out a software product that
dazzles its users. Typically, however, you can't get all the right
people (the right ones are often already over committed), it's never
the right moment (yesterday would have been better), and the planets
never seem to align (instead, they keep moving, entirely out of your
control). Given the increasing demand to develop software in Internet
time, development teams often fall back on the only thing they really
know how to do well=97namely, pound out lines of code. Heroic
programming efforts are legend in this industry, and thus often it
seems that working harder is the proper reaction to any crisis in
development. Oft times, however, these are not necessarily the right
lines of code, and furthermore, some projects are of such a magnitude
that even adding more hours to the work day is just not enough to get
the job done.

-- =

http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist