In Greek, it is called Omphaloskepsis -- though the provenance of this term appears to be fairly recent.  Its origins seem to be found in Eastern meditative practices in which the subject concentrates on his navel, the center of his being, in order to shut out all worldly distractions.  The significance of the navel is also found in the origins of Western culture.  Omphalos, literally "navel", was used to describe the terrestrial location from which all life sprang.  It was also the name of the stone found in the temple at Delphi, purported to be the stone which Rhea swaddled in baby clothes and which the titan Chronos swallowed, believing it to be his son Zeus, prophesied to one day overthrow him.  Because of its divine origins, the Omphalos was believed to be a point of contact between the celestial and the terrestrial, and gazing at the Omphalos was equivalent to gazing into the realm of the gods.

It is also a mode of reflection common in times of uncertainty.  The IT industry is at such a point.  Any software professional who went through the .NET bust at the turn of the millennium and through the financial decline following 9/11 has an ingrained sense that changes in the economy can radically alter the face of IT.  The past five years have seen the emergence and adoption of various tools and methodologies, from Agile to Responsibility Driven Design to Domain Driven Design to alt.net, all premised on the notion that things haven't been going well, and if we all just put our heads together we will find a better way. 

Marshall McLuhan -- I believe it was in The Medium is the Massage -- tells an anecdote about a factory that brought in consultants to change their internal processes, resulting in a 10% increase in productivity.  A year later, for unspecified reasons, the factory reverted to its previous processes, and surprisingly increased productivity by another 10%.  This suggested to McLuhan that sometimes what one does to bring about change is not significant in itself.  Sometimes it is simply the message of change, rather than any particular implementation, which provides results.

The various methodologies, philosophies and practices of the past few years seem to have made improvements in some software houses, but it is not clear that this is due to the inherent wisdom of the prescribed techniques rather than, as McLuhan might say, the simple message that things aren't quite right with our industry.  The acolytes of each methodology that comes along initially cite, quite properly, Fred Brooks's influential articles The Mythical Man-Month and No Silver Bullet.  What they rarely do, once their movements achieve a certain momentum, is revisit those early arguments and evaluate whether they have accomplished what they set out to do.  Did they solve the problems raised by Fred Brooks?  Or do they just move on and "evolve"?

Besides all the process related changes that have been introduced over the pass few years, Redmond is currently caught up in a flurry activity, and has been releasing not only new versions of their standard development tools, but a slew of alpha and beta frameworks for new technologies such as Presentation Foundation, Silverlight, Entities Framework, and MVP which threaten to radically alter the playing field, and leaves developers in a quandary about whether to become early adopters -- risking the investment of lots of energy for technology that may potentially never catch on (DNA and Microsoft's DHTML come to mind) -- or stick with (now) traditional windows forms and web forms development, which may potentially become obsolete.

We also face the problem of too many senior developers.  There was a time when the .NET bubble drove all companies to promote developers rapidly in order to keep them, a tendency that kept expectations high and that did not really end with the collapse of the bubble.  Along with this, companies set the standard for senior developers, generally the highest level developers can attain short of management, as someone with ten years of development experience, a standard which, given the compact time frames of the IT industry, must have seemed a long way off.  But now we have lots of people in lots of IT departments with 10 years of experience, and they expect to be confirmed as senior developers.  Those that are already senior developers are wondering what their career path is, and management is not particularly forthcoming.

The combination of these factors means the IT population is graying but not necessarily maturing.  Management in turn is looking at ways to outsource their IT labor, under the misapprehension that IT fits into an assembly line labor model rather than a professional model in which system and business knowledge should ideally be preserved in-house.  IT, for most companies, falls on the expense side of the ledger, and one expects to find ways to make it more efficient.  The immature state of the profession, compared to medicine or teaching or even engineering, makes these efficiencies difficult to find.

Add to this an economy headed toward a recession or already in recession, and we have all the necessary ingredients for a period of deep navel gazing.  My feed reader recently picked up three, and I suspect this is only the beginning.

Martin Fowler's Bliki contains a recent entry on SchoolsOfSoftwareDevelopment which deals with the problem of competing methodologies, and the Habermassian problem of agreeing on a common set of criteria upon which they may be judged.

Instead what we see is a situation where there are several schools of software development, each with its own definitions and statements of good practice. As a profession we need to recognize that multiple schools exist, and that their approaches to software development are quite different. Different to the point that what one school considers to be exemplary is considered by other schools to be incompetent. Furthermore, we don't know which schools are right (in part because we CannotMeasureProductivity) although each school thinks of itself as right, with varying degrees of tolerance for the others.

A Canadian developer, D'Arcy from Winnipeg, wonders what the new Microsoft technology map entails for him.

For the last 7 years we've been learning the web form framework, learning the ins and outs of state management (regardless of your opinion if its good or bad), how to manage postbacks, and how to make the web bend and do summersaults based on what our needs were. And here we are again, looking at the next big paradigm shift: Webforms are still around, Rails-like frameworks are the new trend, and we have a vector based Flash-like framework that we can code in .NET. I find it funny that so many are wondering whether web forms will go away because of the new MVC framework Microsoft is developing, and *totally* ignore the bigger threat: being able to develop winform-like applications that will run on the web using Silverlight.

Finally, Shawn Wildermuth, the ADOGuy, has posted an existential rant on the state of the industry and the mercenary mentality on the part of management as well as labor, and the long-term implications of this trend.

In some sense we developers are part of the problem. Quitting your $75K/yr job to be hired back at $75/hr seems like a good deal, but in fact it is not a good deal for either party.  Your loyalty is to the paycheck and when you leave, the domain knowledge goes with you...

At the end of the contract you just move on, forcing you to divest in a personal stake. I miss that part of this business.  I have had more enjoyment about projects that didn't work than all the mercenary positions I've ever held...

So do I have a call for action?  No. I think that domain knowledge is an important idea that both developers and companies need to address, but I don't have a nice and tidy solution. This is a shift that I think has to happen in software development. Both sides of the table need to look long at the last five to ten years and determine if what we're doing now is better than before.  Does it only feel better because each line of code is cheaper to produce (mostly a product of better platforms, not better coders). I hope this can change.

 

Something is in the air.  A sense of uneasiness.  A rising dissatisfaction.  An incipient awareness of mauvaise foi.  Or perhaps just a feeling that the world is about to change around us, and we fear being left behind either because we didn't try hard enough, or because we weren't paying attention.

Day five picks up with unsolicited errata and general notes for the remaining Quick Start tutorials from the Silverlight.net site.

Notes to Interaction Between HTML and Managed Code (there is only one tutorial in this section, as of this writing):

Accessing the HTML DOM from Managed Code -- This is a pleasant tutorial showing how to use the Silverlight Host Control as basically a wedge between code behind and the HTML DOM.  From the user control hosted in the host page, you can basically grab the DOM of the container page and manipulate it.  Because there is a lot of code, this is primarily a copy & paste style of tutorial, which means some useful information is left out.  For instance:

• If you name your Silverlight project qsHB, the code will work better, depending on how much you copy & paste and how much you write by hand.
• The HTML controls you add to the Test html page should go in the same div tag that contains the Silverlight Host object.
• By default, the dimensions of the Test html page generated with your project are 100% by 100%.  Change this to 10% by 10%, otherwise your controls will be off the bottom of the browser window.

Notes to Programming with Dynamic Languages (this section only has one eponymous Quick Start):

Notes to Programming with Dynamic Languages: [Skipped] -- some day I may want to learn managed JavaScript, IronPython, or IronRuby.  Right now, however, I can't really see the point.

Notes to Additional Programming Tasks (includes one Quick Start):

Using Isolated Storage and Application Settings -- This tutorial walks you through working with the System.IO.IsolatedStorage.IsolatedStorageFileStream, which allows the application to store files in a sandbox on the server.  The application is very rich, which unfortunately means the tutorial itself involves a lot of copy -- paste -- compile.  To understand what is going on, you basically need to read through all the code you copy & pasted after it is all done.  When a tutorial becomes this complex (and to my chagrin I have written a few like that) it is perhaps best to give up on the idea of doing a tutorial and actually do a "lab", in which the code is already all written out, and the author's job is merely to walk the reader through what is going on.  This is a cool little application, all the same, and I foresee using it as a reference app for lots of future projects.

Whew.  That's it for the Quick Starts found on http://silverlight.net.  Tomorrow I'll start on the labs.

Day Three concluded with finishing the QuickStart series on Building Dynamic User Interfaces with Silverlight, from the official Silverlight website.  Day Four continues with notes and unsolicited errata on Networking and Communication in Silverlight.

A. Sending and Receiving Plain XML Messages with Silverlight -- I learned a new acronym in this very brief tutorial.  POX stands for plain ol' XML.  The System.Net.WebClient class allows us to call a web service (in this case, a DIGG service) and pass the results to a callback method.

B. Building a WCF Web Service and Accessing It by Using a Proxy -- Very nice.  A somewhat sophisticated small application combining Silverlight and WCF, explained clearly.  Someone went through and proofread this particular walkthrough, and the effort shows even in the details -- like stating what namespaces need to be referenced before one actually needs to use them.

C. Accessing Syndication Feeds with Silverlight -- Very simple tutorial on how to access an rss feed in Silverlight using the System.ServiceModel.Syndication.SyndicationFeed class.  The only problem is that if you follow the instructions precisely, it will not work.  The sample code uses the Silverlight.net rss feed, http://silverlight.net/blogs/microsoft/rss.aspx, as its source.  Unfortunately, in order to access an rss feed, the server hosting the feed must have a policy file set up to allow cross-domain access, which the Silverlight.net rss feed does not.

A tad annoying, no?  Or perhaps this is a some sort of Zen exercise intended to reinforce the principle that a Clientaccesspolicy.xml or Crossdomain.xml file must always be properly configured on the feed server. 

Today I have been working through the Microsoft QuickStarts for Silverlight, which include walkthroughs as well as code source.  Here are the high level topics available:

E. Working with Data Collections in Silverlight -- this useful QuickStart explains data binding and the DataTemplate.  No obvious errors, but a few lacunae.

• Life will go much easier if you name your project Quickstart_Bookstore.
• The ObservableCollection type belongs to the namespace System.Collections.ObjectModel.

Today I finished reading through Christian Wenz's Essential Silverlight Up-To-Date.  According to Amazon, the book ships tomorrow -- I was able to read it though my subscription to Safari Books Online.  From what I can get out of browsing the Amazon site, it is the first Silverlight 2 book to come out, and precedes the others by about two months.  It is, essentially, the only game in town for those planning to learn Silverlight 2 from a book.

It is a bit of a mixed bag, due not least to the difficulties involved in trying to write a book about a technology that is still in flux.  Breaking changes are expected during the transition from the beta 1 to the beta 2 of  Silverlight 2, and most book authors in this sub-genre of a sub-genre have adopted the better part of valor.  So thanks are due to Mr. Wenz for accepting such a difficult task and finding a way to meet his publisher's deadline.

That said, while the book offers a good overview of the Silverlight 2 technology, in doesn't go into any particular depth.  The labs are difficult to follow, at times, because some of the things he writes about do not appear in the Silverlight 2 beta 1, such as a project template for user controls.  Since his walkthroughs require the use of a user control, I was obliged to google the right way to create one, just so I could finish the book.

Frustratingly, the chapter on Programming Silverlight with .NET is extremely brief, despite the fact that this is perhaps the most interesting new feature of Silverlight 2.  Or perhaps this is merely an artifact of the way I read it, and the physical copy that will be placed on bookstore shelves will have more content.  At least I hope this is the case.

I was finally able to get a user control into my XAML page by following the official Silverlight 2 hands-on labs, found here.  Microsoft is not known for being good at documenting their bleeding edge technology, but these labs are actually quite excellent, and may currently be the best resource for learning Silverlight 2.  I'll know more tomorrow, as I plan to work my way through all the tutorials and labs on the official Silverlight site.

The trick with adding a user control to a XAML page, it turns out, is that a namespace declaration to the containing project has to be added to the page.  The page, for whatever reason, is not automatically aware of the assembly it is in.  Once the namespace is declared, however, Intellisense takes over and makes adding your user controls -- HelloWorld.xaml, in this case -- quite easy.