05/05/09 :: [MOP] Who moved my Coupling? [permalink]
As I read some of the responses Ian came up with and this comment from Saul Caganoff. It seems that we are at an interesting point of the software history. Lots of old ideas keep being recycled by an old guard of developers and architects: applying over and over the things they often learned in school and applied religiously since then.
If you are not American, you probably have never heard of this book "Who Moved my Cheese?" (and boy aren't you lucky, the CEO of one company I worked for asked every employee to read it before announcing significant layoffs, I cannot tell you how embarrassed I was to be working for this company after I read the book). The book is trying to drive you along a path:
- Change Happens
- Anticipate Change
- Monitor Change
- Adapt To Change Quickly
- Change
- Enjoy Change!
- Be Ready To Change Quickly And Enjoy It Again & Again
As you can see, that's not really rocket science. When you read these few lines you realize how retrograde the vast majority of the software industry is. Ever so often a spike happens, for instance, Object Orientation, Extensible Data Structure, REST (Roy's REST) or Message Oriented Middleware and how does the industry reacts to "change", it springs back to where it was as fast as it can. The pundits reify every new idea behind corny textbook ideas while self-proclaiming their understanding of the innovation in play. They make a living out of it and write more books to make sure every new idea is properly hashed down into these "timeless" concepts. I was wondering if some of the folks at ThoughtWorks would consider writing a book on Who Moved my Coupling? The path to illumination would be a tiny bit different:
- Change Happens
- Control Change
- Reify Change
- Eliminate Change Quickly
- Don't Change
- Enjoy Status Quo!
- Be Ready To Kill Change Quickly And Enjoy It Again & Again
I bet this book would even be more successful than the Cheesy one...
Unlike other industries, software engineering has no (apparent) gravity or any other annoying physical constraints, let alone measurable metrics. Once in a while a company dies and people never look back at "reification" as the major cause of death, it's probably sales and marketing or the stupidity of the customers which was at play.
So next time around when you design a system, just ask yourself how much reification did you bake in your design? The degree of reification (i.e. the number of concepts you used to construct the solution divided by the number of concepts available in your programming model). I bet that you'll be surprised how well this number correlates with level of effort, risks, maintainability...
The question is: will we continue on the path of reification or will we for once "change"?