While I was taking in a recent episode of Dot Net Rocks (the one covering the new LightSwitch rapid development platform), co-host Richard Campbell said something in passing that caught my ear. He described a hypothetical enterprise development scenario in which the “senior guys are building a set of WCF services that the, um, client-building guys can access”.
I batted an eye. Why are we assuming that our senior developers should be focused on the server side code?
This is no slight to Campbell, of course—he probably meant nothing by it at all, good-natured Canadian citizen that he is. But it called to mind tales I had heard before of concerns being separated across a team in this way. The more experienced members of the development staff get assigned the IMPORTANT BACK-END WORK, while they let the new kid, y’know, bring up some screens.
Sure, the nether-layers of your stack contain critical elements that must be tightly engineered for performance and accuracy. There is little value in a brilliantly laid-out page on a website that can’t perform, or in a screen that renders the wrong answers in a gorgeous typeface.
But is this really a working model for a team shipping successful software? Can we afford to regard an application’s User Experience as a foregone conclusion, or to pretend that the real art to be created is in the logic and plumbing of the application?
In the age of jQuery, WPF/Silverlight, and the iPad, our users are expecting a friendlier and more compelling experience from their software every day. Is the server really the place that a seasoned application developer can provide the most value? Would their skill and experience not be better put to use connecting meaningful information with the human being on the other side of the screen?