Developer Burnout Sounds The Alarm

The age of developer burnout has arrived for Windows Silverlight developers. The tipping point came a few weeks ago when Microsoft gave its first public demonstration of Windows 8. While the preview sent a wave of positive buzz through the digital globe, there was one group that immediately reached for the antacid …and in some cases, the whiskey or an ice pick to gouge their eyes out. That group was Windows Silverlight developers.

They are facing the daunting prospect of having to throw out millions of lines of proven code and domain experience about how to build for Windows, and go back to the drawing board to learn a new development paradigm, this time built on HTML5 and JavaScript.

They’ll be in good company, joining Web and mobile developers for whom the age of developer burnout arrived over the past year with a rapid proliferation of mobile operating systems. Every Web and mobile developer is painfully aware of the rapidly growing OS list: iOS from Apple, Android from Google, Symbian from Nokia, Windows Phone 7 from Microsoft, RIM from BlackBerry, webOS for HP/Palm, and more are coming.

We are in a true golden age of operating systems and platforms available for the picking. And while many developers are rallying around HTML5 as the way forward, others realize they simply don't have enough time nor the unifying tools to let them build across all of these platforms.

This proliferation of OSes and the demands of application development are frying some developers to a crisp and leaving employers out of luck. However, there are ways to fan the flames by future-proofing applications. This requires developing them around open standards so developers can capitalize on every popular platform without having to reinvent the wheel. Here’s how to build applications once today that will run everywhere tomorrow.

From the frying pan to the fire

The challenge for developers is that there is simply not enough time and no unifying tools that let them address all of the platforms out there. Frankly, it could be argued that one brain is not large enough to remember all the nuances and idiosyncrasies of developing for all of these different targets.

iOS requires Xcode and Objective-C. Android and BlackBerry require Java. Microsoft requires .NET. HP/Palm requires HTML, CSS, and JavaScript. Symbian requires Qt. And let’s not forget the Web, which requires HTML5, CSS3, JavaScript, and who knows what else in the future. Now juxtapose this OS proliferation against the shrinking budgets of IT departments.

While we're getting out of the recession woods, we can still see the trees right behind us. Companies cut staff to the bone during the Great Recession. You can talk to any developer and they’re all producing more with less—less people on their team, less access to tools, and less domain experience on the OSes they’re trying to target.

Yet the demands on them continue to grow because every company wants an iPad or an Android app, plus they’re looking hard at private and public clouds, SaaS solutions, and so on. And most important, they're looking at ways to tie all these systems together into common back-end infrastructures.

The complexity of meeting those demands is going up, while the resources are not expanding. And the result is that developers simply cannot keep up. Something has to give.

Coming back from the brink

One way developers and their organizations are dealing with this is by deciding not to support certain platforms. When the decision is made to only build iPhone apps that leaves customers who prefer Android out of the equation. This narrow focus eliminates access to the potential revenue independent software developers or businesses could be gaining if they were able to support the devices their customers prefer.

We’re also seeing tool vendors make the same kind of decisions. Tools are being built and optimized around specific operating systems to the exclusion of other platforms. Not only does this make it harder on developers to have access to the tools they need for certain platforms that might not be well supported, but it also further complicates their lives. Now they need to know two, three, or four different development environments as opposed to just one that could target all these platforms.

There is a growing, vocal community of developers who have already thrown up their hands. They’re refusing to build custom code for all of these apps because it is simply too expensive and too time consuming. Instead they are saying that the Web is the platform.

Web technology-based development can in fact be a smart, affordable, and practical platform for a solution. It’s now becoming clear that even hardware features such as the accelerometer, camera, and GPS can all be accessed directly through modern mobile browsers.

The old mantra for application development tool vendors like us was to help developers increase their productivity. We did this by providing rapid application development tools that let them quickly take a business problem and address it in code for the most widely used platform, which was Microsoft Windows.

For us the equation has changed. Now it’s not just about how quickly a developer can build an app, but how quickly a developer can build and deploy an app to a half dozen platforms. Nobody has solved this problem yet. I can tell you that it’s one we are working on and I’m sure other companies are thinking about and working on too. I’m sure there will be multiple approaches that will result in the next year.

That’s good because if we don’t find an answer to this problem, an iconic emblem in the computing world will have to modernized. Once used to poke fun at how long it took certain processes to complete, the image of the developer sitting at his desk covered in cobwebs on his skeleton will now have to speak to the developer who has reached the end of his line. He can no longer keep up with the demands of contemporary application development.

You might also like...

Comments

Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

“Debugging is anticipated with distaste, performed with reluctance, and bragged about forever.” - Dan Kaminsky