KISS my YAGNI abstraction
I’ve recently been observing what appears to me to be a growing contradiction within the software development community. One the one hand popularity and adoption of the various flavors of Agile and its affiliated principles is growing, while at the same time tools, technologies, patterns and frameworks are being pumped out which seek higher levels of abstraction, looser coupling, and greater flexibility. Agile principles encourage simplicity, less waste, less up front design, the more familiar of those principles being:
But are the tools, technologies, patterns and frameworks simpler and necessary? Does the fact that those recommended tools, technologies, patterns and frameworks continue to change so rapidly undermine any claims that they are simpler or necessary?
Who are you calling stupid?
In contrast to the doctrine of simplicity and just-in-time design, the latest technologies, tools, patterns and frameworks seem to be trending towards ultimate flexibility at the expense of simplicity. Certainly, SOA, N-tier, DDD, MVP, MVC, MVVM, IoC, POCO (and the list goes on), are anything but simple. Not only aren’t they simple, but they are also likely to fall into the “not gonna need it” category. If one were to blindly follow best practices recommendations, then every application would be a Service Oriented N-tier Domain Driven multi-layered highly abstracted masterpiece, and would be re-written every few months. But that hardly seems agile, lean, simple or less is more. In some ways, Agile principles almost demand architecting after the fact. On the other hand if you wait until you need Service Orientation, Inversion of Control or a Domain model its very difficult to add later.
“If Woody had gone straight to the police this would never have happened”
How many successful companies succeed using systems that don’t subscribe to any of these concepts, but instead run their businesses using Cobol, Foxpro, Access, VB 6.0, Classic ASP (or any equivalent ‘old school’ technology)? And the corollary, how many failed businesses can attribute their failure to a fatal flaw in their LOB application design? How many companies have said, “if we had only decoupled our inventory system from our purchasing system using a service layer and utilized a POCO capable O/RM tool we’d still be in business”? My guess would be very few, and of that few they’d likely be software companies or SaaS providers where the technology is their product. But for the vast majority of companies out there where technology is the enabler not the product are we being encouraged to over engineer by the loudest 1% of developers?
In some ways developers are snobs. I think we spend a lot of energy looking for ways to separate the men from the boys. The classic ranking of developers as professionals, amateurs, hobbyist and hacks gets played out over and over. Just recalling the C++ vs. VB developer comparisons reveals parallels with each new generation. C++ developers are professional developers while VB developers are hobbyists' and amateurs. C# developers are professionals while VB.NET developers are hobbyist and amateurs. ASP.NET MVC are professionals while Webforms developers are hobbyists and amateurs. Professionals use an O/RM, IoC, SOA and Mocking frameworks, if you don’t you’re an amateur.
I don’t want to suggest that when used to solve a particular problem, any one of these technologies, tools, patterns or frameworks can’t in fact simplify a solution or make it more elegant or flexible, because they can and often do. Or suggest that I’m not a participant in this snobbery, which I invariably am. What interests me is when the desire to produce a ‘sophisticated’ or ‘professional’ solution means stuffing it full of the latest technologies, tools, patterns or frameworks and calling it simpler or more elegant. While this is often interesting learning opportunities for developers and architects, and one more feather in our caps to differentiate ourselves from the outdated riff-raff, it hardly seems lean. If when your only tool is a hammer, every problem looks like a nail then it can also be said that when you have a lot of (cool) tools every problem seems to require them all.
“It depends on what the meaning of the word 'is' is”
This is topic is further obscured by the fact that there is seldom a widely accepted ‘right’ way to do anything in software development. Almost any approach has its share of debate.
For instance, there’s lots a debate about which O/RM tool is the best, or purest. Even if you decide, yes their is a general consensus in the community that some form of O/RM is the preferred persistence/data access strategy, as I recently did, and you wade through the debates and pick a tool, inevitably you’ll discover another perspective that throws the decision back into question. A recent post by Tony Davis, The ORM Brouhaha, did just that for me.
“The IT industry is increasingly coming to suspect that the performance and scalability issues that come from use of ORMs outweigh the benefits of ease and the speed of development”
Benchmarks posted on ORMbattle.NET purport to demonstrate a staggering performance difference between O/RM’s and standard SqlClient. I mention this just as one example of how there are few right answers, just an endless series of trade-offs.
Which leads me back to my original premise. I don’t think we are necessarily keeping it simple or waiting until we need it, and we are certainly being pulled in two directions.
Comments
Post a Comment