[dduff442]

Originally Posted by airmalik

I agree. Building bridges can't be compared to building software. This article does a pretty good job of explaining why:

http://gamearchitect.net/Articles/SoftwareIsHard.html

I'm sorry -- please don't take it personally but I just had to go nuclear on the article you linked to. It's an admirable lesson in how not to do engineering.

Originally Posted by Kyle_W

Myst Online started out as a single-player game of modest scope called D'ni In Real Time, or DIRT. By the time I left Cyan, it was planned to be an MMO with a million subscribers, a driving application that would convince casual computer users to sign up for broadband Internet connections. Chandler starts out as a free replacement for Exchange that's simple enough for casual users. But that's not enough. That would be merely ordinary.

The story of Chandler's ensuing development is, for anyone who's spent time developing software, sadly predictable. There comes a point halfway through relating Chandler's saga, where Rosenberg writes, "By now, I know, any software developer reading this volume has likely thrown it across the room in despair, thinking, 'Stop the madness! They're making every mistake in the book!'"

(...)

From the beginning, Chandler is conceived as a peer-to-peer application, for little obvious reason except that P2P apps were considered to be a new and nifty thing at the time the project was starting up.

(...)

((Another problem was)) Uncontrolled feature creep. Kapor originally conceives of Chandler as a complement to Microsoft Outlook targeted at "'information-intensive' individual users and small companies." But everyone on the Chandler team has a different vision of what that means, and in the absence of pressure to ship, Chandler becomes the union of everyone's ideas. Instead of borrowing from successful similar products like Outlook/Exchange, the Chandler team is determined to invent something entirely new from first principles. They want to support user plug-ins and scripting, built-in encryption, storage of messages in multiple folders and infinitely customizable user views. As the project goes on, the simple replacement for Outlook/Exchange grows more and more complicated.

No decision is ever final. Time and again, the Chandler team hashes out compromises on complex issues, only to hit reset when someone new joins the project with new ideas or when it turns out that someone wasn't really satisfied with the compromise. They revisit their choice of database layer, whether to use Mozilla's UI primitives or wxWidgets, and the whole design of their user interface. Eventually, the peer-to-peer architecture is abandoned in favor of a client-server architecture. Three years into the project, the team is still debating whether to turn Chandler into a web-based application like Google Docs & Spreadsheets.

Chandler's story, you'll recall, starts in the spring of 2001. As I write this, in the fall of 2007, OSAF is trying to get version 0.7 of Chandler out the door.

The author has an odd way of making his case -- by showing in fantastic detail how the Chandler team flushed the engineering rulebook down the crapper right from the start. He doesn't describe the complexity of software, he describes the complexity generated by a flock of headless chickens wandering around at random.

Originally Posted by Kyle_W

And yet, OSAF's employees are all smart people, and most of them have a great depth of experience in software development. How did they end up here?

I actually have no problem believing this. The root of all their difficulties is the fact that their discipline is divorced from all other branches of engineering and science.

A spine of core engineering and science skills should run through the curriculum, even if it was of no *obvious* practical benefit, simply to ground the subject in the broader engineering world and to teach students the commonalities between all its forms.

The examples in the article are classic studies of talent and genuine skill married to a basic lack of competence. Approaches of unnecessary complexity were chosen over simplicity. Approaches that could work on an ad-hoc basis through individual skill but that could never be classified as engineering were preferred to simpler but surefire methods. Peripheral concerns such as the specifics of the UI not only proceeded in parallel with the development of the core system, they were allowed to retroactively redesign it. Use was made of novel or fashionable techniques purely because of their novelty even though they complicated matters, added risk, exceeded the team's expertise and in no way advanced the team towards its goals.

All this by W's own admission and to create... a group scheduling server. This isn't Folding@Home, folks, but an application designed to replace the time-honoured fridge magnet/sheet of paper combo.

Originally Posted by Kyle_W

(...)All software developers would like to change their minds during the course of development, as they gain knowledge about the application they're making.

If they're working to a formal method -- not always practical, admittedly -- this is possible. More probably, their methods were informal so the moment they start making changes they must either scrap large parts of the design or else their project is *out of control*.

Originally Posted by Kyle_W

Speaking of lines of code, my friend Rebecca, who's a Pentagon reporter, has sat through countless briefings about military software projects. She's bemused at the briefer's fondness for citing the number of lines of code in the systems they're developing.

This is maybe because the developers are working on a magical "cost plus" Pentagon contract that insures them against any screw ups they make.

The parts that follow this about the difficulties of scheduling are correct, IMO, but much of the problem stems from the proliferation of techniques, languages, philosophies etc. Much of the duplication is pointless and the balkanisation of the industry hinders the development of useful metrics.

Originally Posted by Kyle_W

In theory, I suppose, the complexity of a well-structured program should be O(n), where n is the number of lines of code, if each line of code is tightly coupled only to the line that precedes it and the line that follows it. A poorly-structured program would be O(n2), with any line of code possibly calling into any other line of code in the program. If n is on the order of a million, the gap between O(n) and O(n2) is staggering. So why do we count lines of code at all? Because it gives us the comforting illusion that we can measure that which is essentially unmeasurable.

The above paragraph is literally gibberish.

Originally Posted by Kyle_W

When it's done, Fracture ((a game W worked on -- dduff)) will be merely the length of the Encyclopedia Britannica. But it will be a lot more complex.

This is highly implausible and is stated without any evidence or argumentation at all. The complexity of Fracture is mostly trivial and elective. If an encyclopedia can be called simple in any way its because its created according to a proven design and in the simplest way possible.

Originally Posted by Kyle_W

Every software engineer has a low opinion of the way we develop software. Even the term "software engineering," Rosenberg writes, is a statement of hope, not fact.

I'm with him here. Certain software problems are not amenable to engineering solutions properly speaking. The job mixes art and science. Sadly, most software engineers give little heed to the transition from science to art and needlessly move from the secure outcomes engineering permits to the hocus-pocus of useful but unnecessary methods that can't be proven or kept under control.

Originally Posted by Kyle_W

And yet, in a typically optimistic programmer triumph of hope over experience, everyone believes that someone, somewhere, is building software the right way, and that we too could make software development predictable and well-behaved if only we possessed sufficient will and discipline.

For 90% of applications, this isn't an aspiration, it's a provable fact.

Originally Posted by Kyle_W

Part of the problem, clearly, is that every time we build software we're creating something fundamentally new. There are, Wikipedia tells me, six main types of bridges. Once you know how to build a bridge of a particular type, you're just iterating on a theme. The principles behind a suspension bridge, for example, are well understood--if not by me, then at least by the people who build them!

His lack of comprehension of structural engineering doesn't stop him making confident, general statements it. How a group scheduling server constitutes "something fundamentally new" in anyone's mind is beyond me.

Originally Posted by Kyle_W

Weinberg's Second Law: "If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization." (...) It's true, too, that construction is less predictable than many would like to believe. (...) The difference is that the overruns on a physical construction project are bounded.

Unlike these IT disasters, just a random selection amongst many.

Originally Posted by Kyle_W

But software is fractal in complexity.

I repeat: he's talking about a system to allow people to arrange meetings over a network.

Originally Posted by Kyle_W

If you're doing top-down design, you produce a specification that stops at some level of granularity. And you always risk discovering, come implementation time, that the module or class that was the lowest level of your specification hides untold worlds of complexity that will take as much development effort as you'd budgeted for the rest of the project combined.

If unexpected complexity lies within a project description then that description does not satisfy the definition of the word 'specification'. A specification cannot include any component that is not well-defined.

Originally Posted by Kyle_W

"The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence."

Try a BS line like that at Siemens or Boeing and security would be escorting you to the door in minutes.

Originally Posted by Kyle_W

Software construction is the most complex endeavor ever undertaken by mankind. It makes building things like cathedrals and space shuttles look like child's play

The full blush of madness. Countless engineering projects of all sorts involve a software component and all would involve a proper specification -- not a concept W has a good grip on. The software component(s) will have well-defined inputs and outputs and will be mathematically verifiable as possible to execute.

W's argument is totally self-defeating. He starts out by describing a long list of easily avoidable errors, demonstrates a broad ignorance of engineering basics and then explains away disasters in terms of literally meaningless nonsense about complexity dressed up as pseudo-mathematics.

Software needn't be like this. Formal methods won't eliminate bugs but they will enable bugs to be traced. They'll ensure a long lifetime for the codebase and make the project much more cost-effective in the long term. Think Oracle, SAP etc.

Even if the money to fund these methods isn't available, the designer should at a minimum produce a proper specification where each component is theoretically (mathematically) understood.

I don't doubt that either W or Rosenberg are highly talented. Probably they're highly productive as individuals. They're victims of a culture that precludes quality, however, and often guarantees failure.

dduff