Rob Howard: marks of a maturing software organization...
We've [experienced] a shift from caring less about the underlying technology to how our software solves the user's problem. It's...probably one of the bigger "maturing" steps a software organization has to go through. You can tell when an ISV hasn't made this transition yet: the literature and announcements about their releases focus 100% on the underlying technology instead of how the software solves a particular set of problems for the people that use it.
If you had asked me 2 years ago about what we wanted Community Server to become ... I would have [answered]: Provider Design Pattern, Server Controls, SQL Server, etc. In other words, I'd tell you about all the cool technology we were using and how we were using it. Today the answer is very different - in fact internally we judge our own success when customers use our software because of the problems it solves, not because of the technology it is built with.
For example, have you ever bought a car because of where the steel was made or because of the brand of the engine? A few people care about these things, but most people care more about: does the car drive good, are the seats comfortable, etc...
Today...our philosophy is: (1) build it as quickly as we can (2) start using it as soon as possible (3) make it simple. Two years ago the phlosophy would have been: make it scalable, make it extensible, etc. Bottom line - If we had started these new projects 2 years ago I don't think they would ever be completed. Now I get worried when I sit in a design review and hear someone say, "we want to make it scalable and extensible". To me that translates to: "We don't know or understand our customer or the problems we are trying to solve, so we'll try to do everything in v1.0."
I'll admit that I fall into the trap of thinking about the underlying stuff like extensibility and scalability too early. I';m excited about the reading and thinking I am doing now on Test-Driven-Development and Contract-First-Design, as well as the Software Factory stuff we're doing internally, and I'm looking forward to using those concepts and practices on the next project I work on, I think those approaches can help with the mind-shift of developers and architects towards Rob's ideas and reduce "scope creep" induced by the "neato" geek factor that gets introduced to projects by architects, designers, and developers (such as myself).
It's like "Just Enough" programming (perhaps this phrase has already been coined), borrowed from Just In Time inventory.
I can hear Joel saying "I told you this two years ago!"