Crafting An Utterly Boring Dev Stack
To Simplify your own developer journey to happiness and compound growth
How we love to adore shiny new things! It makes us feel all warm and tingling inside. To achieve that upvote, like or golden star on your forehead if one can reference the newest tech in a tweet or an interview. I am guilty as charged!
Each year companies spend billions on new technology as they feel like they might get outdated in the tech arena. On the other side of the spectrum there are developers, the executors of ambitious product roadmaps, who seem to be hopscotching from new topic to newer topic. Both in search for another dopamine-hit after mastering yet another perceived new tech frontier. On and on the swan-dance goes…
New tech is awesome, but highly likely most individuals and firms out there can be way more efficient by utilising boring technology stacks without hopping on every new bandwagon which passes by their headquarters. I have been reflecting lately on the opportunities and costs beyond technology switching. Turns out I am not alone… There are other like minded individuals who are asking the same questions. More and more are beginning to keep things utterly simple and boring, while focusing on shipping useful features to their customers.
Boring technology should not be perceived as bad technology, rather a better word to use in this context would be mature technology. This is not some brand new paradigm-shift which started yesterday, rather there have been many advocates over the years of keeping one’s tech stack as simple as possible. I guess we (me included) were just blinded by the bling-bling of Silicon Valley.
Rather than pitching technology to their customers, these advocates have consistently compounded their learnings into more productive workflows, shipped more often, and bare more fruits given their labour inputs. I have yet to find someone that has formulated boring technology so well as Dan Mckinley (boringtechnology.club), and practiced it as well as Pieter Levels. Each showcasing how far one can stretch the perception of building with less. I will dig a bit deeper into more examples in some of my follow-up articles, but for now let’s look at what exactly is boring technology?
It is highly likely that boring tech:
- is often easier to explain
- is often perceived as too simple
- has gone through multiple iterations
- has multiple online tuts / stack-overflow questions / forum posts from which one can learn faster
- will highly likely not go viral
- will bring on less worries for you to switch attention to learn, because it does not bring on a flurry of changes everyday
It is highly unlikely that boring technology:
- is out-dated
- does not scale well
- breaks easily
- can not solve complex problems
- can not create a sustainable cash flow stream for developer(s), agency(-ies), and business(-es)
- communities are smaller than they are marketed to the wider public
These assumptions are not at all complete, but can be supplemented with more well-tested findings. I hope to go deeper into some of the boring technologies out there in production, such as: php, python, ruby, server-side html rendering via Hotwire, cron-jobs, R, etc.. For now, let’s expand on some principles, which might help guide our understanding of productivity a bit better.
How do we become more productive? is an age old question which has been asked by several economists. I will touch on some principles below, but it really is just the tip of the iceberg. It should be enough to at least get you started thinking about how you view your productivity. For each of the principles, I added a simple rule of thumb at the top, which helped me to apply them in my current workflow.
PRINCIPLE 1&2: Compound Learning + Switching Cost
A marginal decrease in productivity by using a specific (software) tool/technology is inevitable. One have to incorporate switching to new technology at some point, the real question is; when? When is the perfect time to switch, while not negatively impacting one’s own productivity?
Rule of thumb: As long as your compound learning of a tool does not lead to lower marginal productivity, keep utilising your old boring stack.
In a perfect world your learning curve compounds well over time, but there is always some switching cost involved. The three curves which I still need to refine looks something like this for me currently:
- a) One hopes to achieve higher productivity over time through compound learning in that tools’ domain
- b) In reality, there is always some marginal decrease in productivity due to old technology becoming too outdated
- c) Technology switching does causes productivity to decrease / stabilise, as it requires a significant investment of upfront time and effort, which only later pays off in gained productivity (hopefully…).
PRINCIPLE 2&3: Pareto Principle + Production Possibility Frontier
A production possibility frontier shows you how much can be produced given existing resources. A production possibility can show the different choices that an individual, business or economy faces. To explain better Figure 2.a, the maximum output given existing resource input, I will quote an example of Dan:
“Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet. Clearly this model is approximate, but I think it helps. If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that’s existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you’re in trouble. Any of those choices might be sensible if you’re a javascript consultancy, or a database company. But you’re probably not. You’re probably working for a company that is at least ostensibly rethinking global commerce or reinventing payments on the web or pursuing some other suitably epic mission. In that context, devoting any of your limited attention to innovating ssh is an excellent way to fail. Or at best, delay success [1].”
What if there is a new technology innovation which allows one to be way more productive than with the boring tech stack?
“If there is an increase in land, labour or capital or an increase in the productivity of these factors, then the PPF curve can shift outwards enabling a better trade-off” (Source). This is referred to as the new higher frontier indicated on Figure 2.b, where one can see the Pareto % at a new higher level of productivity.
Rule of thumb: Stick with a high *boring tech ratio* until new technology comes along, which radically moves your productivity to a whole new higher frontier.
PRINCIPLE 4: Happiness
Decision-making is a complex art/science with lots of hidden heuristics. At the end of the day one would hope to achieve (a) happiness on the journey, as well as (b) happiness with the fruits of one’s labour. From all the principles I have listed so far, this one I am still busy testing myself and understanding it better, but at this stage I think following rule of thumb resonates well with me:
Rule of thumb: Rather than just adopting new technology and dumping boring tech, productivity gained through mastering boring tech, will bring the majority of your happiness.
Note: If you still want more information on this topic be sure to also read more into game theory (i.e. prisoner’s dilemma), and the extrinsic vs intrinsic motivation, which causes people to be less/more productive.
Next I want to briefly touch upon Freedom Of Choice and the Switchlord, both which stands between you and crafting your boring stack.
Perception of freedom
The Internet is such a special place. You can literally tap into it and have a value exchange at little to no cost at all. What a wonderful time to be alive and be: a builder, an entrepreneur, a teacher, an artist, an investor, etc. etc.! We are pretty free to choose where we want to spend our time and energy, and the Internet has become a massive enabler for change. In the same breath, too much freedom has become a nuisance to your productivity as each of us has only 24 hours in a day.
Switchlord
The biggest challenge you will have to face when refining your boring stack on the road to higher productivity, is the Switchlord. In a world where we are often overwhelmed by million + 1 choices, one of the challenges is to focus exclusively on productivity. This is easier said than done, as this gatekeeper is always looking to block you from reaching master-level status in your boring stack. It will never rest until it has recommended you the perfect switch, which allows you to get side-tracked. Watch out for this one, as he/she/it is closer to you than you might think!
Degree of Boringness
The ultimate question you need to ask yourself is: How boring do you want to be? Answering this question will make the journey to battle the Switchlord way way easier! Knowing that boring technology encompasses lower investment of time, higher compound learning, higher productive feature shipping, higher certainty to prove pilot software early-on, etc. Three roads lie in front of you which will guide you to your question:
- Option 1: 80% (boring tech) +20% (new tech)
- Option 2: 50% (boring tech) +50% (new tech)
- Option 3: 20% (boring tech) +80% (new tech)
Option 1 is way easier to maintain if you are running your own business, as your end-customer does not really matter about your tech stack, he/she just want you to solve their needs. That said, Option 1 is also not out of the picture if you are working for an employer, but there is definitely going to be more gatekeepers in charge of making this choice more difficult for you. So be aware of that. You should just focus on shipping and showing true value (aka: fruits of productivity).
Finally, The Utterly Boring Stack, is a series brought to you as part of my distilled thoughts I have been refining for some years. I am aware that one can never satisfy the masses, at least not while keeping your own freedom of time, space & opinion. So this is the part where I am transparent on who this series is / is not for.
Who is this series of articles for?
- New python web developers (or data engineers/scientists)
- Weekend tinkerers who loves to refine their existing boring stack
- Makers who want to simplify their web development workflow
- Builders who want to move more of their logic to the server (not client)
I hope to simplify topics dramatically and hopefully make them less intimidating and daunting in the process. As mentioned this series will be more geared to python developers, but I hope to also talk more about general topics, which will hopefully be applicable to other developer tools & techniques as well.
Where-ever you are in the world, I hope you can take at least one thing away from it, make it your own and refine it further. If you have liked the introduction so far and would love to get notified once I write about the topics below, please feel free to follow me. As always, I cherish feedback, so feel free to add your comments below. The future topics I hope to cover, will be:
- Part 1: Utterly Boring Stack (Genesis)
- Part 2: Utterly Boring Stack (Environment)
- Part 3: Utterly Boring Stack (Development)
- Part 4: Utterly Boring Stack (Staging)
- Part 5: Utterly Boring Stack (Production)
- Part 6: Utterly Boring Stack (Alpha & Beta Communication)
- Part 7: Utterly Boring Stack (The Marketplace & Value Exchange)
- Part 8: Utterly Boring Stack (Optimisation Through Refinement)
- Part 9: Utterly Boring Stack (TBD)
Enjoy, and see you soon!
