Architecture is Politics
Why Some of Us Embrace “Full Stack”
I just read a few more articles and links about new Rails 5 stuff that were more informative and more technical than my own. Some, like me were relieved and encouraged by the announcements. Others have posted about experiencing an existential crisis at RailsConf after DHH’s opening keynote.
The debate centers on two approaches to developing applications — the “Integrated App” or “Majestic Monolith” championed by DHH and the “Single Page Application” or “Client MVC” approach championed by others.
How you approach this debate depends on your role in the ecosystem and how you see yourself as a developer.
Back in the 1990's, a smart old friend once told me over a few rounds of beer in Cambridge, MA:
“Steven, Architecture is Politics.” — Jim Quick
And Politics, is about money and power.
A lot of developers seem to think SPAs are the new default best-way to do things. You can build many wonderful applications with this approach. I know, I’ve built some. And of course we have all used some amazing SPAs. However, the herd-like rush to abandon the simpler web application model works to the disadvantage of many. I will explain why.
First, let us observe what happened with the NoSQL craze of several years ago. A lot of people went out and tried to abandon one of the most proven and valuable technologies of the Information Age — SQL and the relational model. On the plus side, we got Redis. And Postgres got document storage. Then we moved along. However, I know people who lost big contracts, money and even their businesses by too-quickly embracing this fad.
Shepherds have to watch their flock and developers definitely exhibit herd behavior.
Now, let’s take a look at what SPAs are in fact. Heavy Javascript clients really represent a sort of return to the old client/server type applications albeit with different technology. They almost demand a hard split of “front-end” and “back-end.” This strongly incentivizes career specialization.
This split and specialization affects the power balance of employee and employer as well as the power balance between capital and the aspiring entrepreneur. It also affects the ability of the freelancer to hang up a shingle and deliver entire solutions on their own or to build up a small practice into something that would grant him or her financial independence.
With Rails, it became possible for a single individual of even modest talent to develop an entire application.
If we embrace a split into server-side and client-side, most developers will lose this capability and will be dis-empowered.
In the last year we have begun to see something of a backlash against the “full-stack” developer model that Rails did so much to advance.
If you are a “full stack” developer, then you were empowered by the approach Rails championed. I know I was. And that is what excited me so much.
Client/server is basically what many developers were doing 15 or 20 years ago under a new name, with new tech. Most such apps were developed by teams. The architecture, per Conway’s “Law”, followed the organizational structure.
What a lot of younger people may not know is that the advent of the web application was a sort of return to the “mainframe.” Now it is called, “Cloud.” Today anyone can rent micro-virtual-mainframes on digital-ama-rack-hero-ocean-yard-space. Web apps are basically screens, forms and transactions. All the important stuff happens on the server.
The browser replaced the mainframe terminal.
The difference now is that powerful servers cost so little that almost anyone can afford one and start making something useful. That and everyone has terminal in their pocket.
Now, hopefully what you develop doesn’t resemble either of these in appearance. But how different is it logically
Except for a few key features or window dressing, most apps still reduce conceptually to some form of Create, Read, Update and Delete on a few, tens or even hundreds of record types. This is especially true of all the SaaS apps that aim to “disrupt” various stodgy old line businesses, create new efficiencies and fortunes for their creators. Does your app have forms? Yeah it probably does.
With SPAs, people seem to want to develop the equivalent of full-page Java Applets (only better looking) all over again with less mature tooling. Tread cautiously here. Especially if you are starting out on a new application.
The SPA approach is more interesting the further you get from a form-heavy CRUD transaction type application. But if much of your app conceptually reduces to updating data with forms and/or simple transactions, the SPA architecture is almost certainly overkill.
Given that Architecture is Politics, and politics is about money, I wonder if there is a hidden motivation here for SPA enthusiasm. Aside from pure intellectual challenge, or technical concerns, specialization leads to job security. If you divide your app in two, and specialize in the front end or back end, then it will require two developers to support. More work to go around!
If your team is only two developers, it is difficult go down to one since neither can do the other’s job. If you have a bigger team, then you only compete for job security with the developers who are on the client side or server side. Our current bubble is still in an expansion phase. For now, more work simply means more opportunity and higher salaries.
Ultimately, developing software is about producing value. If you can deliver more value by yourself, you will be more valuable. When the air comes out of the current bubble, if you still need another person to deliver a complete solution then you will be less valuable. Full stack gal will be the last to be let go and first to be rehired when the dust settles.
Highly skilled developers never worry about job security. Preppers or entrepreneurial developers want be able to do as much as possible alone or with one or two others. This is why DHH wants his go-to backpack of specially curated, full-stack tools. As a developer-entrepreneur, that’s I want too.
Less-skilled developers need to be concerned with job security. Those who aren’t looking to build entire products by themselves have little pecuniary interest in simplicity. If allowed, they will complectify every time. For this type of developer there is no real advantage in the integrated app model which DHH has explicitly stated is his motivation for continuing to work on Rails.
If you truly have superhuman programming talent and can manage a full size Javascript SPA as well as a full Rails or other back end, all while making substantial contributions to the frameworks you need for these, maybe you can remain “full stack” in an SPA world. Otherwise, I think you are losing a great deal of power with this approach.
My thesis here is that how you see this drive to split into front-end and back end depends largely on how you see yourself, and thus how you intend to use your programming skills and your backpack of tools.
If you see yourself as an employee, and possibly not the best of the lot, you definitely want to specialize. It is in your interest to do so. At least for now. Go SPA.
If you see yourself as an entrepreneur or an idea person and desire to execute your ideas or deliver whole systems, you want to be full stack.
If you are an employer of developers, you want them to work as efficiently as possible and to be as fungible as possible. Specialization works against this.
If you are a later stage investor, you want to put your money to work and you want entrepreneurs to need your capital. Ergo, you might want them to need larger teams and to make everything more expensive. It makes your capital more valuable to the entrepreneur. Go SPA.
Alternatively, if you are a seed investor maybe you want your investments to get more done with less and to iterate faster. Go integrated.
If you want to break out into freelancing and attain some kind of independence from employment, and perhaps build a successful business or product on your skills, go full stack.
The excess of funny money (I hesitate to call it “capital”) flowing into speculative software projects may be all that is indulging this experiment in “how can we consume more developer time to deliver similar end user value.”
There are good reasons to build heavy Javascript clients. I can and will use these tools and approaches when necessary. But a sizable part of the herd seems to want to run off and make this the default approach. Foolishness, I tell you!
If your developers are pushing an SPA approach and you personally have doubts, maybe you should seek a second opinion. I am available on clarity or through my company, ÆLOGICA.
If you are a developer and want to Level Up professionally, get my ebook, “LevelUp” and learn how to be more valuable and effective.
