I want to highlight a couple of things that Bob Warfield has pointed out in a recent blog entry on the “small vs large” team size debate. My very small experiences observing and participating in development projects in the thick of the small and medium sized business environment have lead me to suspect these things, but it’s always good to hear someone that can articulate this stuff concisely:
“There are two ways to think about this. Chris takes the path that says the example is irrelevant because most software isn’t that way. I take the path of saying that the example is spot on because all software should become a language if done right. The benefit? Your small team is enormously more productive as are your customers if you can actually make the language something they can grasp and use. There is a reason these small teams built languages (though I’m not sure I view Linus as a tool/language). In fact, Quattro Pro had no less than 18 interpreters buried in the guts. Very few of them were surfaced for end users, most were there to make the code simpler and the product more powerful.”
So if you’re building something complex that has to meet a lot of different people’s needs (and whose needs are constantly changing) then you need to see through the cloud of conflicting requirements to the generic tools that would enable solutions to actually emerge. And the most powerful tools are actually going to be languages.
“Don’t kid yourself that a giant team running around gathering requirements and hacking out use cases in monolithic modules is building software, business or otherwise. It’s creating an unmaintainable mess that makes nobody but the IT guys that assembled that laundry list happy. Certainly the business users who it lands on are going to find it isn’t what they thought they were getting and it is almost impossible to change it into what they wanted.”
If we solve today’s problem, we’re hosed. Today’s problem isn’t the real problem… it’s just one iteration of it. So we shouldn’t give into the temptation to “hard code” stuff for the check-list people just to please them in the short term. The requirements and use cases of today have to be expressed in terms of our tools and linguistic abstractions: we need to invest efforts in expanding their scope and expressiveness.