The question "Why we cannot build software like we build bridges?"
assumes a deep over-simplification of the problem of building
software.
The question falls in a basic assumption. Physics laws.
Construction of bridges have them, have always have them, and they
have always been the same (2000+ years of accumulated knowledge).
Further more, the users experience them inside and outside the
bridges.
Software does not have to comply with physics laws. Sure there are
performance and constrains imposed by the hardware. But in the
strict software sense, one can put a menu bar on top of a window
and it will not fall down, nor need to be hold by any other
element. And only 50+ years of knowledge.
This is so simple and basic that we think of it as a ridiculous
reason to look at, and we ignore it. But it is a huge wedge in
between bridges and software construction methodologies.
User requirements:
Bridges: We better let a qualified engineer to tell us what can be
done. He knows how to calculate the structure so it works.
Software: We better tell the guy that read "Programming C++ in 24
hours." exactly what we dreamed last night, most of the time even
ignoring technically embarrassing requests (recently I read about
a guy that was worry that the printer will print hyper links
because the user might want to click them)
Design:
Bridges: This is what can be done, this is were can be done, and
these are the exact materials that will need. And we might be able
to negotiate some aspects of it, but you cannot negotiate nature
laws. Period. (Sorry, cannot put the foundation on sand and expect
it to support tons of weight for the next 100 years)
Software: Design??? You mean the sketches of requirements that you
gave me, which are incomplete? And no point to complete them,
because as you go using the system, you will discover new
requirements that you didn't think before. Better yet, lets go
agile! (try to build a bridge with agile methodologies)
Development:
Bridges: Well planned, knows exactly how the foundation has to
work and were to put it, everything was measure before hand. And
there is no expectation to try to use the bridge yet, because it
does not makes sense. Construction crew is working, leave them
alone.
Software: Well... I would like to see a mock up of the screen, to
have a feeling of how it will work... since the mock up is already
working, why you want to spend my money tossing it away and
creating a "real system". I'll just use this one that already
works. Or better yet, you really don't need a database server, I
have been doing my calculations in excel all these years, just
look how well organized my folder structures are. You see? it
works! Just make it work with more data, that is all. What do you
mean it can't be done? I though you were the expert!
And of course I can keep going...
The fact that there are physical constrains in bridge building
known by everybody, forces construction projects to work within
those constrains.
The fact that there are no physical constrains (beyond hardware
limitations) in software construction, and the constrains of
software development are very little known even by programmers,
allows all parties to ignore them.
Asking "Why you cannot build software like we build bridges?" is
such gross oversimplification.
I have a friend that is a construction engineer, and he was
looking down to my programmer career because he had write a few
excel macros. Then I showed him how I change the flooring in my
bedroom all by my self, and that I was going to take on commercial
buildings designs (his trade), because after all it is the same
thing only with more materials, right? He felt offended, but got
the point.
Discussion on:
Message 14 of 1
The best of ZDNet, delivered
ZDNet Newsletters
Get the best of ZDNet delivered straight to your inbox
