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.

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.

This point was actually made in the book fwiw.

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.

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.

He never said it should have used C++ vs Python but that good Python devs at the time were harder to find (vs C++/Java/C# in his example). This is something time can solve, however his point that picking a platform/language that is has a lot of available talent is a good point if you want to get your product to market quickly. Python was not exactly obscure, but at the time it in my experience, was used more for bash/shell replacement scripts rather then desktop app development. It might not have been the major point of failure but it definitely contributed.

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.

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