
Software is hard - volida
http://gamearchitect.net/Articles/SoftwareIsHard.html
======
idlewords
I worked at the Mellon Foundation for a while, and one of my jobs was to visit
Chandler and find out what they were doing with our money (my boss had
foolishly funneled them a lot of funding for a version 2, "Westwood", suitable
for university use). It was a complete vanity project - Kapor had brought in
his art collection, the offices were spacious and lovely, every developer had
state of the art workstations with an acre of screen space - but the software
never worked. Pointing this out just created tension and bitterness. The
project floated along on Kapor's reputation and ate his money, and had no
opportunity to make contact with reality. I think of it more as a cautionary
lesson about lack of outside constraints than software complexity. It was a
Spruce Goose, except nowhere near as pretty.

------
hxa7241
Software is rather good actually. Only a small percent of any of it is faulty.
It could be improved but it is largely not considered worth it.

Civil engineering is not as perfect as often supposed. There are plenty of
defects from barely noticeable to catastrophic. The software world simply
knows nothing about other engineering. There is an easy way to see: just check
the references in software engineering books and papers and count how many
point to other such disciplines: practically none.

Neither is civil engineering as predictable (or controllable) as supposed. The
majority of time, cost, and risk is borne by construction, so this overshadows
the part most equivalent to software -- the engineering design proper. But
this stilll has the same inherent difficulties as any design work.

Saying software makes other engineering look trivial shows a lack of
knowledge. If you learn a little of civil engineering you will find it is just
as complex as software.

Software is not all entirely new: look at all the reused components,
libraries, etc. That is substantial, perhaps even the majority proportion in
some sense.

There is probably more complexity of interrelations of parts in software,
since physical designs are constrained to a more 'regular' physical substrate.
But I don't think it is too bad, because the design activity is intrinsically
isolating to a large degree.

Software has almost none of the physical constraints in other engineering, and
it is so changeable at any stage. It really has distinct good fortune and
advantages. And it is everywhere, it runs the world. It is a great success.
Yet it is seen as failing. We don't have a mature, perceptive, understanding
attitude to it.

~~~
rplevy
This point was actually made in the book fwiw.

------
Zak
The author makes some claims I think are conflicting - specifically that
software shouldn't be built by brute force and ignorance, and that the
Chandler project should have used C++ instead of Python because more
programmers know it.

Maybe they were hiring the wrong people (programmers who didn't already know
Python), but I really doubt that the choice of language was a major cause of
their failure.

~~~
DannoHung
The problem with Chandler was that the requirements were shit.

People talk a good game about Agility and Extreme Programming, but if you do
not know what you want software to do, it is going to do whatever the
developer feels like making it do.

------
allenbrunson
I am actually more interested in the small amount of information about Cyan.
That's a spectacular flameout of epic proportions that I've never seen written
about in any detail.

------
swolchok
...let's go shopping? (sue me, I loved consultant Barbie and I have points to
burn)

