Blog

Owning the full-stack: A homesteading analogy on software, innovation, and freedom

Have you ever met a homesteader who owns a mansion? Me either. My neighbor, Bill (80),isa homesteader who tries to be as self sufficient as possible. From what I can see, it’s an immensely rewarding and humble existence. Life-satisfaction oozes out of his every pore and, eventually, even enduring the hardships must have become rewarding to him.

He was wearing an interesting smile when he told me that for 20 years the only inputs to the property were paper goods (read as: toilet paper) and that they don’t have any source of heat other than wood, which he cuts off his own property. Homesteading is immensely hard and it’s not for everyone. Homesteaders don’t have the time to live a life of luxury because homesteading means you have to own all the problems of life. The problems of food and shelter, and producing enough value to trade for things you can’t produce yourself. I think this is similar to how a full stack developer has to own the problems of the whole stack.

I have a sense that some of Bill’s perma-grin has come from creating a lot of solutions to a lot of problems. Bill is certainly resourceful, and perhaps innovative in a local sense. I wonder some about whether another homesteader, or a farmer who’s feeding global markets and is financing modern equipment, thinks Bill is innovative. I wonder more how many homesteaders have solved the same problems he has. I suppose each time a homesteader solves a problem, stands back, and says, “now that’s a good solution” they feel just like a developer does when they create an innovative and useful way to visualize data, for example.

But is it an innovation if it’s happening repeatedly in different places? There’s many a time I’ve thought I did something innovative just to find out there was a different and better solution out there already. Specifically, I think back to this Excel macro I wrote to do a conditional join on a relatively large dataset. It turns out I wasn’t innovative. I just forgot to search the web to find that Microsoft Access could have done it in about 1/100th the time. I was resourceful, or even locally innovative, but I certainly wasn’t globally innovative because no one in their right mind would ever use the macro I wrote.

The more I think about full-stack developers as homesteaders the more the analogy proves useful. What I see are people striving to be homesteaders. Full-stack developers are driven by a desire to achieve high overall life-satisfaction, to control every detail of their world, and to learn as much about the fundamentals of their craft as possible. I haven’t decided whether they are also driven by a lack of trust that others can contribute to their world without introducing impurities into the grand design or taking away some satisfaction. Some years into homesteading, Bill reluctantly bought a tractor. Many full-stack developers in the early days of the cloud hardware takeover, said things like, “I don’t trust it’s secure, so I’m just going to build it out myself.”

Bill still insists his horses did a better job of ploughing the fields because he could better control the tool when he could walk behind and see what was going on and when it was a slower overall process. He won’t let the tractor builders take away the satisfaction of having done it the old way, but he will tell you that he can’t do it now without that tractor. I suspect it’s either because his farm grew beyond what one man can cultivate with a horse when he brought the tractor in, or simply because he’s too old now.

If the resources flowing into and out of Bill’s property were put into a box model, it’d be pretty close to a steady-state system. Sure, he’s bringing in paper and gas on a regular basis (and that one-time infusion of the tractor), but he’s also exporting goods (furniture) and services (he’s a museum quality furniture restoration specialist), food (pigs, corn, and grain for his extended family), and knowledge (he’s taught woodworking classes, spreads his knowledge of heritage vegetable breeds at the local fairs, and he sure taught me a few things, like the lack of value in sawing your own lumber).

Let’s play with this model a bit. If you ignore the gas inputs and the one-time tractor input, he actually becomes a significant net exporter of goods and has a net input of money. (He’s got a savings account under his pillow, I’m sure.) It wasn’t until he brought that tractor into the system that he had enough cash to buy a car (I’ll bet he worked hard to try to get a version without computers). With the car he could do things like teach classes on creating wood inlays for museum restorations down to the thousandths of an inch. He also started making it to more fairs and started trading heritage vegetable strains with other people he found that are just like him. Bill was probably a net exporter of goods without the car and tractor, and we’d have to get pretty creative with the numbers to figure out if he’s still a net exporter afterwards by calculating the value of his various products.

When I look at the flows within Bill’s box model I can see the most time resources are going into a few areas. 1) Food (growing, harvesting, preparing), 2) Energy production (cutting wood), 3) Shelter (maintenance), 4) Production of exports (furniture), 5) everything else. The order of these may change depending on the homesteader.

When I look at the flows within the modern full stack developers model I can see the most work is going into design, user experience, data transport, visualization, performance, and security. Again, this is variable depending on the developer and their needs.

Like we started to look at how Bill’s world changed after the tractor, we can look at how full stack development changed from before and after cloud hardware was introduced. Ten years ago people had to own every aspect of the hardware if they wanted to produce a web application, including buying, configuring, tuning, maintaining, updating, etc. Once the full-stack developer freed themselves from owning the hardware, they were freed up to do other things. So what did they do with their time?

I’m sure it varies for everyone, but how much time do you think went into building jQuery by developers who would have otherwise been bogged down bolting down power supplies? Some, I bet. Others probably used their time to pump out more applications, some tinkered with machine learning, some with dynamic visualizations, some with the finer aspects of xhttp requests. Similar to AWS, how do you think things changed after jQuery and other high level DOM manipulation tools freed them from the tedium? Or when they embraced their first integrated development environment (IDE)?

Recently, Bill bought a wood processing machine because he couldn’t do it by hand any longer. He went from about four days per cord of wood (cutting, splitting, stacking, burning), to about one day per cord. He burns about seven cord per year between his home, cooking, and workshop. That machine freed up 21 working days per year of Bill’s time! He also produces enough cord wood for his son’s family. But there’s always a cost. He probably spends two days a year maintaining it and I’m sure it was a hit to his savings.

How about when a full-stack developer lets a high level app development platform that provides all the flexibility in the world without having to own any client-server or server-server communication protocols, without having to worry about how Python queries elasticSearch, without having to worry about preparing data for a network map visualization, without having to worry about how two visualizations asynchronously communicate user interactions with each other. How about a development platform that bridges you directly to other people who’ve used the same type of data and visualization as you, except with a different set of algorithms?

OK, wait, what? That was a mouthful.

This solution I propose would be akin to the homesteader buying a prefab property design optimized for homesteading efficiency and plopping it right into the middle of their property! The insult! Life satisfaction diminished, creativity lost, a lifetime of feel-good local innovations to discover, lost. It’s so different. The only thing they’ve accepted before is the the most valuable rudimentary tools and a toolbox.

You can bet Bill took a good chunk of time before he decided to buy a tractor and an equal amount of time before he chose a specific one (he got a Kubota). And that was just a tractor! Think of all the requirements this design would have to meet before Bill decided to allow it into his world! The design would need to be alterable infinitely so he can make it work exactly how he needed so he can feel resourceful again within his new world.

What if it was sustainable, and built from parts built by people just like him? What if every part was documented by tinkerers and homesteaders just like him, so he could understand how it all worked and build on top of their work. What if it didn’t change the fact he wants to burn wood, it only improved the process, so he had more time for other things? Think of all the things he’d be free to do if the wood stacked itself and the roof never leaked and the workshop was always warm, and there were never mud holes keeping his tractor from the fields and his tractor was always tuned up. If other respected homesteaders helped him make decisions on crop rotation and which strains to try next. If the perfect design was delivered would Bill see it as a nightmare or a blessing, and would he accept it or reject it?

What if a suitable design for the homesteader isn’t that far fetched an idea and what if we’re closer than we think? Exaptive is certainly trying hard on the IT side of the analogy and has made reasonable gains in a few short years.

The precedent exists. The tractor and wood processor are analogs of what AWS did with cloud hardware, and they did a lot more than convince one full-stack homesteader. Nearly every developer in the world uses cloud hardware, and nearly every homesteader now uses a tractor. Only the biggest, burliest, most secure, and most backward organizations who don’t understand value when they see it still build their own hardware. It’s just not cost effective and not scalable. Cloud hardware is a $175 billion dollar per year market, and it was only the tractor. The D3 framework and its visualizations were so valuable they became ubiquitous almost instantly, and full stack developers gravitated to it because they could immediately recognize the purity and value of the product as something they would have done themselves if they had the time.

It’s this kind of innovation, value and quality of product that gets developers’ acceptance . And perhaps Exaptive can become as transformative for the full-stack developer as cloud hardware, jQuery, and D3 have been. We’re certainly trying.