[cemerick]

What I was driving at with the "it depends" part is that, in the real (commercial) world, there's only so many reasonable ways to get something done. There will always be a variety of important details, but the fundamentals don't change much because of the natural constraints that exist. The same cannot be said of just about any software development activity.

I stand by the blueprint:building :: X:code concept. Brian posted a comment on the actual post along the same lines as your rebuttal:

"With regard to "blueprint:building :: X:code", I think code is the blueprint. If not code, then a specification that's precise enough that it may as well be code."

And I'll repeat here that if precise specifications required code, then you wouldn't have regexes, SQL, or any of the other common (and uncommon) DSLs that flit about. If you think those things are code, then what about BNF grammars? RDF triples that inform expert systems? There are a lot of things that system behaviour that don't suffer from the problems of software as I described, and they often are far closer to the relevant domain than any "code" that would be required to implement the desired behaviour directly.

[zb]

Thanks for the reply; I wasn't sure if you were following this thread. So, if I understand your argument correctly, you're advocating that domain experts create software in high-level languages so that we don't have to write code.

The problem with this theory is that it relies on what I've seen best expressed as "the neat separability of ends and means." This is also the fundamental principle of top-down design, and it's the reason people hire armies of (<cough>Java<cough>) programmers, give them no domain knowledge and ask them to construct the code while waffling about how projects are like houses.

In the real world that's simply not true. Engineering is where ends and means meet and overlap and are reconciled through the process of design. The result is, for civil engineers, blueprints; for software engineers, code. That's why I think you have code on the wrong side of the relation: because code embodies both ends and means it cannot be merely constructed, it must be designed.

[cemerick]

I agree that that's how things are now. My argument is that software development today is not an engineering discipline. You're right that I know almost nothing about "real" engineering. However, what I do know seems to suggest that commercial software development, even in the best of circumstances and with the best people, does not possess necessary characteristics that are relied upon in commercial engineering.

The thing is, so much of what software developers do could be systematized, or at least codified into what would often manifest as what we'd call "tools" that are then used to far more productive effect by those domain experts.

I've mentioned Matlab and Mathematica elsewhere as an example of delivering domain-specific notation, but they're also a great widespread example of delivering a domain-appropriate environment. What if these tools didn't exist, and any time someone needed to do some math, they had to cajole some programmers somewhere to help them get the job done? That'd be a disaster in relative terms, but that's the status quo of so many other "domains" where software development is regularly involved.