Who's Driving?

In the world of software development, it's de rigeur to talk about what you're driven by. Back in the 80's, after I realized that, generally speaking, software should not just mutate like an irradiated fruit fly, I became database-driven then requirements-driven. In the early 90's, I lost myself and went through several stages of rebellion during which I was process-driven, goal-driven, architecture-driven, and finally feature-driven. Around the start of the millenium, people started telling me I should be domain-driven, test-driven, and model-driven.

An identity crisis is looming here. I'm not sure how I can be driven by all these things without coming down with some kind of software engineering schizophrenia. Who's driving this thing?

Seriously, it's clearer to me now than ever just how immature the software development field still is. I can't wait for the next new book that will proclaim to all the world that everything about software development should be [whatever]-driven. No other field takes such a simplistic view of itself. The truth of the matter is that none of these would-be umbrellas can alone drive software development. The agile development people may not always have cornered the market on best practices -- in some ways they, too, try to make software development too simple and linear -- but at least their approach is truly rational. Call it common-sense-driven if you feel you have to have a driver.

I wonder if in my lifetime I'll see the day when this field as a whole embraces the truth that software development is best modeled as a matrix of drivers that must be viewed and managed multidimensionally. And manipulated wisely. A thing does not have to be linear to be simple, and sophistication does not imply complexity.