The Modern Application Architecture and The Demise of the Full Stack Developer
As software development matures customer expectations rise, application complexity increases and the ability to have a 'full stack' developer an impossibility. In recent years the profile of a modern application has changed dramatically. The API is an important demarcation between the application engine or back-end and the client experience. I like to think of this as the application hour glass.
In the past our applications tended to be a blob and then more like a silo. The rise of mobility and advance skill requirements have caused the typical application shape to shift to this hour glass profile. In the distant past we might build an entire stand alone application that shipped with its data store. This quickly evolved to a more distributed model where the application might call a remotely hosted database across the network. Web technology introduced a new middle layer we know as the web server. This is where IIS and ASP.NET reside.
Today more than half of new client computing devices are considered mobile. At the same time we have started adopting APIs as the actual application interface. The API can be consider the command line interface. The GUIs we create are merely more user friendly interfaces to the API.
From a developer's perspective this gives us a clear choice to focus our skills and passion. Most developers tend to feel much more at home below the API, developing complex business logic and data access layers. This makes sense as most developers tend to shy away from 'design' responsibilities. Below the API is where we can practice many of the strict lessons we have learned around pure computer science. It is a developer first world or a place where an inside out approach can thrive. It is a place of pure logic that is easy to absolutely test. This world of absolute appeals to the type of problem solver typically attracted to the software development world.
Above the API is a different story. This is where the end user or our customer lives and interacts with the application. While the concepts of logic and core software development practices can be executed, they often produce sub-optimal user expedriences. Automated unit testing often adds minimal if any value to the final product. The example I often to use is the impossibility I can use the AssertWowsAndAmazesUser assertion.
As one of my former client's stated one day 'it requires an artistic component developers normally do not possess'. That moment was a point in time I will never forget. It was the first time I realized I was part designer and part developer. While I will never claim to be a 'designer' I am a developer that studies good user experiences and makes an effort to put user's first.
This is an outside in approach. The term outside in I trace back to Lou Carbone's Mix 09 presentation. The concept is simple, yet difficult for most developers to grasp and execute. Client applications, be it a native application or built using HTML5, must be designed around delighting the customer. This means it must load fast, response instantly to user inputs, be easy to navigate and provide sufficient feedback to ensure the user they have done things correctly.
Applying pure computer science discipline to client application development will only create experiences customers will be less than satisfied using. This means lower sales, less engagement or in the case of an enterprise line of business application less efficiency and lower morale. In short it creates great software that sucks. Which reminds me of a book I love, Why Software Sucks and What You Can Do About It.
As I survey and work with popular frameworks and libraries like Angular, Ember, Backbone and jQuery I can quickly spot the inside out approach. They are large, bullky frameworks trying to dogmatically solve all problems for everyone. They tend to work against the browser's native functionality and encourage bad practices. They are designed to be developer first solutions, ultimately making it more difficult to meet customer expectations, but in a very rapid and efficient manner.
Are their good parts of these frameworks? Absolutely. We have to find a good balance between executing great user experiences and developer productivity.
As I integrate in and out of various enterprise development teams and interact with folks like you at conferences and developer events, I routinely see developers that have no desire to build client applications being tasked with doing so. They tend to not understand the browser platform they are developing on, but instead put faith in inefficient frameworks and libraries. Missing an opportunity to learn the platform and use it efficiently. I consider the browser to be an operating system with a very simple native API using three languages to drive rich experiences. The browser operating system is optimized for one thing, delivering a user experience. Enterprise managers and decision makers still cling to the legacy assumption a developer should be a full stack developer. The full stack approach simply does not work in today's technology landscape.
I think I gravitated to the client because I focused on small businesses for so many years. I was forced to spend about 80% of my development time creating client interfaces my clients desired. They could have cared less what happened behind the submit button as long as it went smooth and was easy to understand. They wanted eye pleasing and no friction. They always asked for more speed. The never cared if I used a gang of four pattern or had a large automated unit test battery.
To me I found the back-end to be less challenging. Sure the absolute truth problem solution world that exist below the API is fun, but not exciting. There is very little need for creativity. Today I spend as much of my time studying and researching user psychology and successful user interface patterns. I also study computer science patterns and apply them where I find them appropriate. But the hard reality is programming patterns and workflows are often not nearly effective in producing a good user experience. They are good at improving developer work-flow but often have a negative impact on the customer acceptance metrics.
On my side of the API I have to consider how my application is loaded across the wire. I have to consider network latencies the way below the API developers have to consider disk I/O latencies. I need to optimize CSS rules the way the server-side developer needs to optimize for loops. I need to understand why the hamburger icon is not a successful metaphor the way the the database programmer needs to ensure transactional integrity.
Software developers are problem solvers. As applications mature and grow more complex we must decide what problem set we want to become an expert solving. For me it is within the browser platform. I encourage you to pick one, focus on the problem set and become good. I predict you will ultimately be much happier with your career and produce higher quality code.
Managers you do not need a large set of developers in a particular problem area. You need to identify your areas of needed expertise. It could be web client, API design, service architect, business logic or data store expert. Your application has a unique personality you must evaluate to determine these areas.