A New Software Engineering

- Build a good team. Keep management overhead and bullshit to a minimum. Motivate people by giving them really good people to work with and not pulling crap compensation games.

- Do your product three or four times. Rule of thumb: When you're absolutely sick of re-writing the thing and you're ready to work on something else (probably at about this many repetitions) you're reaching the point where you have a decent solution.

- Work on something hard and fun that people actually want to buy.

- If someone in management tries to cram a methodology down your throat, or a salesman knocks on your door with a rad new way to do scrum, kill them and stuff the body with all the other miserable wastes of oxygen who tried to bamboozle you with snake oil.

I dunno. This stuff is just bloody hard, and every silver bullet I've ever seen -- especially the ones that management loves or that use the word "paradigm" in their literature -- has been a dud.

I think this is half right. There was quite a bit of cargo-culting going on. But the fundamental error was to try to apply the project-management process for the construction of other kinds of artefacts to the design of software. I wrote about this very topic here:

http://www.zerobanana.com/essays/reclaiming-software-enginee...

You're correct that no other engineering discipline attempts to use waterfall-style project management of its design process. They don't really use it in the construction process either (in practice, design tends to continue alongside construction), though it probably has at least been attempted.

It was no surprise to see that the authors of this piece are in fact among the originators of the Rational Unified Process. They claim to have corrected their mistake; in fact they are still pushing the same wrongheaded ideas as they were in the 1980s.

We just can't find anybody to pay for us to retool the whole stack (and I do mean the whole stack, since we're only as strong as our weakest link) while the current ad hoc solution operates within acceptable parameters.

The guy who wrote this paper, in my opinion, is missing two really bedrock principles of "pure" engineering-- manufacturing tolerances and cost. If it works as well as it needs to and comes in under budget, it's miller time. There's a reason every stereo ever made goes -clunk- when you push the 'on' button. There's a reason none of the walls in your house are exactly plumb.

SCRUM, Extreme Programming, Waterfall, etc. These are all about management and business practices, not about what we do. Extreme Programming has some craft related "practices" (TDD, CI) but even these are mostly in the QA corner.

I think we need a theory about classes of programming problems and their solutions. We need to analyze our code bases, and how we grew those, in order to understand the trade-offs and nature of our approaches. And by this I really mean analyze the code base, the "project idioms", the abstractions, their cooperation.

Examples I recall are from the Lisp world where the bottom-up onion is a well liked strategy (layering toolboxes on toolboxes, each made up of many small pieces which can be combined effectively). Another such observation is the many types with few methods vs many functions on few types debate. This is what I want to see researched (and research myself).