« Atom Protocol: draft-ietf-atompub-protocol-08 | Main | Try JOnAS »

Learn more stuff

Clemens Vasters on the growing surface space of .NET:

"But for a development team to benefit from all these technologies, specialization is absolutely needed. The times when development teams had roughly the same technology knowledge breadth and everyone could do everything are absolutely coming to an end. And the number of generalists who have a broad, qualified overview on an entire platform is rapidly shrinking."

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. Aside from the technology, there's a good argument to be had that we're not especially good in this industry at getting specialists to colloborate and communicate on projects, ergo any platform that acts as a forcing function towards specialists rather than generalists presents its own risks.


January 2, 2006 08:31 PM

Comments

Sylvain Hellegouarch
(January 2, 2006 09:40 PM #)

I spent my entire year (well now last year) working extensively with Visual Studio for quite a big project. It's a great product and features wise VS2005 look even more interesting. Nonetheless I still feel less productive with those products than I am with a simple text editor and few tools aside.

I am not trying to say VS200x are bad products, not at all but I wonder how far one can get to force developers into one given way.

Developers tend to dislike be tricked into one way to do their job. They like to be able to pick up their tools to a certain degree.

That's also why there is a growing trend of rejecting frameworks, specially enterprise frameworks. Because as their name imply, your work is framed and thus you know in advance that one day the framework will fail you because the thing you want to achieve is not part of the frame.

Better to offer good independant tools that are quickly grasped than a full featured environment that tie your hands.

Kurt Cagle
(January 3, 2006 09:10 AM #)

Bill,

You (and Clemens) both point to something that I've felt for some time was seriously wrong with the software industry.

Most of the major languages in use today have fairly similar cores ... there are, in fact, surprisingly few significantly different ways that you can create a computational language. Every so often, from one sector of the industry or another a computer language will emerge, one that is intended to solve the difficulties of the existing languages by "simplifying" the language structure itself. For typed languages, this usually amounts to reducing the access to pointers and performing better garbage collection, creating a marginally better objectification mechanism and so forth.

Both weakly and strongly typed languages exhibit what happens next, though for a number of reasons strongly typed languages are more susceptible to the problem.

Certain technologies come along that necessitate the introduction of an extension to the framework (XML was perhaps the most recent major ones, but there are minor ones that come along all the time). In some cases, the extensions really are critical - they deal with underlying data structures and access and are used heavily. In many other cases, the extensions are "nice-to-haves" - a set of RSS readers, for instance. Enterprise frameworks are the worst for this, because in many cases the classes that are added are essentially thin functional wrappers around very highly variable data structures used for business logic, and as a consequence you end up with a wide variety of these. What's worse is that most of these in turn necessitate implementing active classes on top of virtual interfaces, frequently designed not by business experts but programmers who know programming but have only a very rough sense of the business logic at work.

Thus the frameworks grow and grow and grow - and the incentive to cheat on the strong typing increases to the points where the languages reimplement templates, after deep avowals from the language's developers that templates are evil because they break down the strict typing regime.

I believe that the complexity of frameworks is directly tied to the degree of typing inherent within the language itself, which in turn is a function of the degree to which we attempt to encapsulate structural form. We have followed Bjarne Stroustrup religiously for a quarter century into this morass of cathedral-like frameworks, all because we have all caught the OOP meme which states that objects should be self-encapsulating.

What's the alternative? I'm not sure, but I have my suspicions. I see an different binding model emerge within the XML space, one where encapsulation is not in fact a given, where data structures are given functionality in a just-in-time fashion by interactive binding language instances which are themselves largely class-like models.

This doesn't necessarily solve all of the complexity problems - you are replacing complexity within frameworks by complexity within namespaces, but in general I've found that generic XML DOM models are actually quite powerful in reducing the number of classes that a given application requires. Type, far from becoming the fundamental characteristic of frameworks, instead becomes simply another form of binding, a temporary abstraction that's useful for validation but that can be discarded when necessary.

Of course, the other side of this coin is that we've solved most of the low hanging fruit of programming, which means that, of necessity, the programming tasks that remain are far more tightly bound to the specific context of the industry that the applications are being written for, and hence require far more specialized knowledge than was true even half a decade ago.

This is seen by the fact that while good specialist programmers are awash in work, young programmers are finding it inordinately difficult to get jobs even now. Businesses are not wanting C++ experts or Java developers - they are wanting experts in device driver development or financial systems or publishing or telematics. What makes these difficult to build good comprehensive packages for is the fact that these particular verticals are both highly specialized and generally not compatible from one manufacturer to the next. A good programmer should be capable of recognizing when looking at a problem that an analogous problem existed in a different context that he or she solved, and then weighing the degree to which the dissimilarity of contexts makes the application of that previously solved knowledge feasible in the current situation.

Frameworks (and especially upgrades of frameworks) sell the IDEs and components and related products that software vendors produce. The hope is that a reasonably solid framework can in essence duplicate the skill of the programmer in dealing with at least the analogies of a project, but as Sylvain pointed out, as often as not such frameworks simply become crutches that bad programmers use, demanding ever more pieces of the puzzle from the vendors to minimize their own work. I see it as a vicious cycle, and one that's very difficult to get out of unless we seriously rethink, at an industry level, whether it is not our tools but our methodology that is fundamentally wrong.

-- Kurt

M. David Peterson
(January 3, 2006 09:46 AM #)

After reading Kurt's post just now I've realized that in fact I have the same complaints, and in particular blame these complexities in many ways on the fact that the software companies are not just in the business of creating software, but also to make money. Obviously this is not a sudden and overwhelming revelation nor is it a suggestion thats theres a whole lot we can do about it and/or complain because of it. Theres not an industry nor company on this planet who is not concerned with both making a profit and, if possible, a significant profit.

Fast forwarding through a lot of useless mumbo-jumbo we are all already aware of, the downside to the development world is that the drive to both make and increase profit means a push to not only create better software that is alluring to the consumer base, but to increase that consumer base if at all possible. To increase the consumer base of the devtool/platform market is easy... build tools and platforms that will attract more interest, increasing the base of "developers" willing to purchase more products.

As Kurt has already pointed out, this is cyclical downward spiral that brings the words of Trent Reznor's March of the Pigs into a whole new light:

---
maybe afraid of it let's discredit it let's pick away at it
I want to watch it come down
now doesn't that make you feel better?
the pigs have won tonight
now they can all sleep soundly
and everything is all right
---

Please don't take the above to mean a directed comment at MS in regards to the "Pigs". Obviously this is an industry wide problem, and I doubt much there's a whole lot that can be done about it. While there are a handful of companies out there that are content with developing products that attract only the select (elite?) few, and they're fine with serving the needs of these folks without taking it to the bloatware extremes. Unfortunately, theres not enough of those companies/people to change the rest of the industry's tendency to be "Pigs" even if they don't realize that this is actually what they are/what they are doing.

The funny thing about this... I > http://www.xsltblog.com/quoteoftheday/archives/2005/12/morts_welcome_a.html

Bill (and Sylvain, and Kurt), you're absolutely right.

But is there a way to fix this? How do you fix a problem thats only seen as a the problem it is by a small minority of the developer population.

Come to think of it... it seems there's another group of folks that have a similar tendency to see the problems and fallacies that come when the business men and women realize there's a market and as such, profit to be had:

Artist's

Yet again, Paul Graham is proven correct.

Thanks for opening my eyes Bill (and Sylvain, then Kurt ;)