[UPDATE: Two excellent follow-up comments from Sylvain and then Bill can be found below. Thanks to the both of you for taking the time to comment!]
I think the question here for .NET practitioners and architects has to be - is all this stuff actually needed to the point where specialists are required to make projects succeed? I also wonder whether .NET isn't in the same boat in 2006 as J2EE was in 2002, whereby the technology on offer is overkill for what's needed
Assuming that Bill is suggesting that "No, we don't need all this stuff" then this would be one of the few times I disagree with his point. In most cases (I can't say for sure about all cases, but I can for most) the need for a specific area of the .NET Framework Class Library stems from two things:
* Common Sense
* Customer Demand
His point stems from a quote in which is suggested that effective use of the .NET platform requires specialists. However, my assumption again is that Bill views this as a bad thing.
I disagree.
In fact I will go as far as suggesting that instead, this is a really, really good thing. It means there's more variety, more choice, and more ability to get the same job done WITHOUT requiring a specialist in a particular area to get it done.
Regarding specialists: The medical profession easily showcases the fact that the more knowledge we obtain, the more advanced we become, the more specialists are required to implement, build upon, and extend the prior two points (more knowledge, more advanced.)
Are you sure thats a bad thing?
[UPDATE: Extending this a bit. When comparing J2EE from any year thus far to the current state (or any state for that matter) of the .NET FCL, the primary difference that seems to be overlooked is that .NET is focused on any language where as Java -- while others have gone to the extent of building bytecode compilers for their language of choice, the practice is still in its infancy and is FAR from what the .NET communities have in regards to language options. This difference in platform philosophy showcases the fact that with .NET one can build from existing knowledge to gain the advantanges of more advanced technologies. I see this as both a productive as well as an appealing point in regards to not forcing a requirement that I become an overnight specialist just to be proficient on the .NET platform.]
TrackBack URL for this entry:
http://www.xsltblog.com/xslt-blog-mt/mt-tb.cgi/1268
Hi mate,
I would agee with Bill. Look at Office for instance. It’s a huge product that most people will only use at 5% of its capacities and resulting in enormous books (strangely called Bibles usually) to explain the regular user how to make the most of Word…. man I just want to write a letter!
VS2005 follows the same trend. It looks nice and shinny but it’ll need develpers to have a great knowledge of a product when they should focus on design or code.
As I commented on Bill’s blog, I feel more efficient with a simple text editor such as Crimson or Scite than with VS.
“Regarding specialists: The medical profession easily showcases the fact that the more knowledge we obtain, the more advanced we become, the more specialists are required to implement, build upon”
Ahh. The point in about specialisation in general is true, but the medical profession is not a great example of this for software development - yet. Even today, most medical professionals are GPs and nurses, who are generalists. Medical specialists exist to fix specific things that go wrong and they don’t tend to work in cross-disciplinary teams as Clemens is suggesting is needed for development. Surgeons + assistants work in teams but they don’t really fit the specialist collaboration idea.
In any case I’ll say the point about specialisation on a project being a risk stands, but that may have more to do with methods than the technologies.
Sylvain,
I can see your point. My only counterpoint is that there’s no requirement to use any of the application you don’t want to and as long as the additional features don’t get in the way of performance, then no harm done. While I probably only use 5-10% of any applications features, there are times when I will use the extended portions, and when I do, I’m certainly glad they’re there.
That said… I look very much forward to the day when compound documents, for all intents and purposes, take the application space over, allow the ability to use a declaritive style approach to our document creation in which allows us the ability to only use the components that are called upon in our final “docuplication” (wow! thats an ugly word. Lets hope Jesse James Garret doesn’t read this and get any bright ideas:
“I’m the father of docuplication!”
Yikes!
Bill,
Yet again you have showcased quite well why I have so much respect for you. I have nothing to say other than, “huh. all very good points” :)
Thanks to both of you for taking the time to comment! :D