This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Generalization and Specialization
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
Ralf brings up a lot of intersting points in his last post - some I agree with, and some points I don't. In the context of XP, Ralf counters the requirement that members of an XP team be "jacks of all trades" (which I think is a bit of a misunderstanding - from what I've learned, (and I'm far from being a XP master) XP and the agile methodologies "generalizing specialists"). Anyway, that's not the point I wanted to bring up. Ralf states:
"Software quality requires specialization: Number and complexity of software technologies and tools will continue to increase. I think it´s obvious, that it becomes ever harder to stay on top of current tools and technologies. 20 years ago database programming was plain simple and required knowledge of one API. Today it´s several APIs, languages, programming models (e.g. ADO.NET, O/R Mapping, SQL XML, SQL), plus the intricacies of database products like SQL Server 2005 (e.g. SQL CLR, T-SQL, Web service interface, SQL Service Broker, SQL Reporting Services). And what about (G)UI programming? There is at least WinForms, WebForms, AJAX, Flash, and WPF around the corner. Add to that a couple of new Smart Client frontend options VSTO and IBF and I guess you see what I mean."
Yes, there are lots of technologies out there. No you don't necessarily have to know them all, XP teams included. If you're a UI developer, most of your coding takes place behind the technology specific facade. MVP and "the humble dialog" make client-side programming more resilient to technological churn. On the web, things are different - the paradigm for UI programming there is still solidfying, but most data-driven web UIs where user experience is not the primary requirement can use many of the winclient techniques as well.
The same is true for data access, or rather will be true once you take the O/R mapping pill.
A well designed architecture will isolate technology behind domain-driven interfaces in such a way that the vast majority of a system can be understood without getting down and dirty on MSMQ vs Rendezvous vs MQ - a queue's a queue (more or less).
However, one sentence in particular struck a chord with me:
"That´s also one reason why software architecture is on the rise. There needs to be someone with an overview of all this and coordinating the weaving: the architect."
Personally, I disagree with the view that architecture can be handled by a team without any one person grasping the end-to-end view. That person may not need to delve down into every last detail (depending on system size), but the system level flows need to be understood, fully, in a (at least) one brain.
To sum up:
Every problem in computing can be solved by adding yet another level of indirection - well, besides the problem of having too many levels of indirection.
Previous Topic
