This one relates to details about the software development business. Those interested mostly in my travels and book recommendations might want to give this one a pass.
Of late, I’ve noticed an interesting progression on the balance between front-end and back-end development resources. In the kind of projects that I’ve been doing in the past few years (small-scale web application development with teams of anywhere from 1-10 developers), I’m seeing a much greater amount of effort being spent on UI development than backend.
Backend development has been getting a lot simpler. The open source revolution has won, with the result that things that ten years ago would take months to build can now be done in days or weeks.
An example: in my first few years at AOL in the late 90′s, I worked on the search development team. Many of my projects involved adding search capabilities to existing AOL applications like message boards. It could take a team of three developers a couple of months to build those capabilities using expensive software libraries bought from specialized vendors.
Flash forward to 2007. When building Mixx we wanted to add a search capability. With open source libraries, it took me one week to add search with no software cost. Admittedly, the problem was somewhat simpler, but still – that’s a major change.
By contrast, UI development is getting a lot more complicated. UI’s have to be better: users expect much more sophisticated UI’s than they used to. But more important, there’s now an abundance of devices, each with its own complexities. These include traditional web browsers, smartphones, and tablets. But even there, it’s worse than it sounds. If you want a fully featured consumer application available on all these platforms, you have to have UI’s for all of the following:
- Traditional browsers to run on desktop or laptop.
- A web interface for smartphones that will work on smartphones of varying sizes (iPhones now come in two screen sizes, and there’s a wide variety of screen sizes for Android and other phones).
- A web interface for tablets, including tablets of various sizes (iPad, iPad Mini, etc).
- An IOS app for iPhones.
- An IOS app for iPads.
- An Android app.
- You might want a Windows Phone app, or one for Windows tablets – market share is still low, but that may change.
There are techniques and libraries that allow one UI to support more than one of these platforms, but those techniques are compromises and will not give their users the best possible experiences on all platforms. Further, even using those techniques complicates building the UI: building a web interface that can operate on both smartphones and desktops is not as easy as building an interface for traditional browsers.
The end result of this is that I’m seeing the ratio of frontend to backend development shifting. Ten years ago at AOL we might need one frontend developer for 3-5 backend guys. Four years ago at Mixx, we usually had a ratio of 1:1. At Treater, we had one backend developer and two frontend developers, plus a group of contractors building IOS and Android apps using an API built by the one backend developer.
Further, when I build my own apps, I’m finding that I’m spending most of my time doing frontend work. The backend practically writes itself.
In addition to the management/staffing implications, there’s some interesting computing cultural implications. Traditionally, the backend jobs have been the higher status jobs, and backend developers have been paid more than frontend developers. I’d say that should no longer be the case, though it may take a while for that to happen.
But this leads to some advice that I’d give:
- To people hiring for a new web application company, concentrate on your frontend developers. That’s where your difficulties will lie, and that’s where you are going to need your rockstars.
- For developers, make sure your frontend skills are up to scratch. I expect things to shift to the point where frontend guys make more and are in more demand than the backend guys.
- Special bonus advice for developers: learn to build native apps for IOS and Android.
- For platform builders: if you can come up with a first-rate solution to the plethora of platforms, you’re golden. (Yes, I know there’s lots of companies with solutions. But as I said, they tend towards compromise – which may be good enough for many apps, but the perfectionists will not be happy. And as Apple has shown, perfectionism in UI can be a winning strategy.)