« Modern etiquette puzzler | Main | IT administration user experience »
September 13, 2004
The vendor is not the community
Malcolm Davis, comparing C# to Java, promisingly identifies mindset as a more important difference than features. Unfortunately, he has a very bizarre idea about what the C# mindset actually is.
His sole example of the difference in mindset is that Java developers (and Java IDE providers) use Ant and JUnit -- tools initiated and maintained outside the Big Corporate world of Sun and IBM -- which he characterises as "constantly exploring opportunities for increasing productivity," whereas Microsoft are developing their own monolithic Team System to rival NAnt and NUnit.
Now if this is a difference in mindset, rather than a difference in vendor strategy, he presumably thinks all .NET programmers are sitting around in a Visual Studio-induced stupor waiting for Team System to come along -- his "accepting the tools that are provided on the desktop" mindset. I don't know which .NET shops he's investigated, but that's simply not the case. The evidence from the weblogs and mailing lists is that .NET developers have been just as aggressive about creating and using productivity tools as Java developers. The .NET community has seen what the Java community has achieved and collectively said, "I gotta get me some of that, and I'm not gotta get it now." It's the exact same mindset -- finding or making the tools no matter where they come from.
Davis may be partly right about Team System being aimed at the IT shops, as opposed to the commercial shops -- personally I think he's missed the point again, as I see Team System as a countermove to Rational in the enterprise which only incidentally sweeps up features from NUnit et al. -- but if so all he has done is identified a difference in mindset between IT and commercial development. There's nothing inherent in either .NET or Java that ties either platform to either development style, or forces their users into a particular mindset.
September 13, 2004 in Software | Permalink
TrackBack
TrackBack URL for this entry:
https://www.typepad.com/services/trackback/6a00d8341c5c9b53ef00d83421988f53ef
Listed below are links to weblogs that reference The vendor is not the community:
» New Team System Stuff - 2004-09-13 from Rob Caron's Blog
[Read More]
Tracked on Sep 14, 2004 7:24:45 PM
Comments
Most of the .NET shops I have worked in do have an MS-only mindset. They prefer MS tools to other tools, and are very wary of third party and open source tools. On several occasions, I have observed a very hostile reaction to any attempt to consider or introduce a third party tool.
Having been a Borland C++ user during the period when Visual C++ became usable makes me sympathetic - had we been using the MS platform and MFC, we would have had a 32 bit version of our app far sooner. It takes fairly few such experiences before you decide that using Microsoft tools to develop apps for the Microsoft platform may well be the easiest way to get your needs met. Third party tools may help, but they cannot be part of the core tool chain, lest you get hung out to dry when the Next Big Thing happens.
Scott
Posted by: at Sep 14, 2004 6:14:37 AM
"Third party tools... cannot be part of the core tool chain, lest you get hung out to dry when the Next Big Thing happens."
But of course the same is true of second party tools. Microsoft's history in data access technologies is an oft-cited example. I'm betting MFC and COM users are beginning to feel left behind in the move to .NET. I remember Microsoft Visual Test -- I'm glad my company at the time didn't invest any effort in that. Any tool, any technology can leave you hung out to dry.
I'd agree, however, with your reservations about Borland. Using Delphi in my present job has really made me appreciate the Microsoft toolset. But is this really a third-party issue or just a tools quality issue? Do you feel Borland hung you out to dry in pursuit of a Next Big Thing, or is it just that their toolset was mediocre in comparison to other offerings?
Thinking about your comments and John Styles' elsewhere, I'm wondering about the investment mindset. We all recognise that technology changes, toolsets change and each successive wave eventually gets left behind. Maybe rather than trying to guess what has "legs" and glob onto that, we should accept rapid obsolescence as the tax we pay for working in this industry at this point in time? In other words, instead of trying to escape change, just budget for it? Hmm.
Sorry, seem to have wandered from the topic somewhat...
Posted by: Ivan Towlson at Sep 15, 2004 12:02:14 AM
Do I feel left behind using MFC and COM? I feel I should probably care, lest I have to practice saying 'would you like fries with that?' for my next job. But somehow I don't.
Posted by: John Styles at Sep 15, 2004 8:26:44 AM
Possibly bad examples, as MFC and COM developers are hardly being "hung out to dry" the way Visual Test users (if there were any) were.
It's not a matter of "do I care" in terms of whether my skills are going obsolete. Most of us are smart enough that we can transfer our skills to whatever new fad comes along. It's more a matter of "am I going to be able to sustain this existing codebase."
Posted by: Ivan Towlson at Sep 15, 2004 10:01:19 AM
“he presumably thinks all .NET programmers are sitting around in a Visual Studio-induced stupor waiting for Team System to come along” – Not really. I use NAnt, NUnit and many other tools in C# development. What amazes me is the lack of enthusiasm by Microsoft to get involved in these community products, and bring them to the forefront with support in their products.
For several decades we have talked about getting the development staff to work closer with the end user. This closeness not only provides more responsive behavior, but a more complete understanding of the problem space. Open source provides that closeness, that bare metal feel of the end-user needs (the end-user in this situation just happens to be other developers).
Big companies like BEA, Borland, IBM, and Sun not only embrace and include open source tools like JUnit, but also natively run these tools. Additional products like Eclipses, have built in support for Ant build.xml files that includes intel-sense and popup help. Products like Eclipse are also built with Ant, and tested with JUnit.
What tools are used to build and test Visual Studio? Why are we not allowed access to those tools? Is Microsoft going to embrace the developers needs for products, or just Corporate needs for a counterpart to Rational? The fact Eclipses has had extensive refactoring capability for free, and Visual Studio still does contain refactoring, speaks volumes and answers many questions.
The mindset? Vendors like IBM & Sun are inclusive, Microsoft is not. This none inclusive behavior of Microsoft hurts the C# technology base.
Posted by: at Sep 15, 2004 3:08:20 PM
Actually I did use 'Visual Test'. I always thought there was something pretty odd about it. The examples for 'Test Basic' were largely general purpose Windows programs that were nothing to do with testing. It was almost as though it were a parallel Basic to VB that had been relegated to a side-line, and then fell off the edge completely.
Posted by: John Styles at Sep 16, 2004 9:09:10 AM
Yes, there's certainly a difference in vendor mindset. That didn't seem to be what Davis was talking about in his original article, but he did seem to shift towards it in later comments. But does Microsoft's lawyer-induced terror of including open source code within its technology base really hurt C# users? The third party alternatives -- the NUnits, NAnts, refactoring add-ins, etc. -- still flourish.
I guess a danger is that the mere potential presence of Microsoft in a market can serve to kill off alternatives. Will NUnit prosper once Microsoft are shipping a unit testing framework? Will refactoring projects arise from the community when Whidbey is less than a year away?
Posted by: Ivan Towlson at Sep 16, 2004 11:51:32 PM