[passivate]

Agreed, we need both quantifiable metrics, and also a human brain to interpret them with subjectivity, context and compassion.

I see many people wanting to take writing code into the liberal arts domain, but I am of the opinion that it may be more useful if we can overlap it with the engineering domain. IMHO the goal should be to repeatedly churn out high-quality bug-free code, and to create an objective process methodology so that time and money is well spent. We may end up with multiple different methodologies for various technologies, domains, etc.

[closeparen]

The part where the code needs to execute correctly is engineering domain. But lots of bad code executes correctly. "Programs must to be written for people to read, only incidentally for machines to execute." Writing things for people to read is unavoidably an arts discipline.

[passivate]

>Writing things for people to read is unavoidably an arts discipline.

I understand what you mean, but I'd have to disagree with that. I've been working on a very large engineering project with a large-ish team (~50 members) for over two years. All of our communication is via an established methodology of engineering diagrams, design documents, position papers, etc all of which are in a structured format that follows common rules/regulations/conventions.

As a result, all the companies we work with for e.g. understand our P&ID diagrams, electrical schematics, mechanical design docs, system layout diagrams, etc. There is no reason why such a methodology can't be brought to code. I don't view code as anything special - having now worked on on both sides. I think there really is a lot of value in the engineering methodologies that can be adapted and applied to the software world.

[closeparen]

Do your diagrams, design docs, and position papers not vary in the clarity of their presentation or in the wisdom/simplicity/fitness-for-purpose of the ideas they convey?

[passivate]

Indeed, they vary. The larger point is we still get a lot accomplished/communicated and done because of a common underlying methodology. I don't have an answer for what that means when adapted to the software field. Its going to be a soup of many things - coding guidelines, BDD, TDD, modular programming, etc, etc. I'm sure there are brains far bigger than mine already working on this, its not really an original idea in that sense.