On Simplicity and Software
Scott Beale / Laughing Squid - laughingsquid.com

On Simplicity and Software

It’s all moving so fast - new technology firsts all the time. They are happening so fast that they some are outdated before we even see them. We see this with software architectures consistently - the new and the great. For instance, make everything a service, services are bad; make everything API’s, then point-to-point communication is bad. Make everything loosely coupled via messaging and then messaging is a central part of failure. Make your infrastructure solid and known, then make it cloud native and ephemeral. I could go on, in fact, I bet you’re minding is already filling in obvious missing slots.

Maybe you have young children and have seen this book - it’s a constant juxtaposition.

But what about simple? Ok, maybe that’s a loaded term today. How about “straight forward”? Can we take what’s good and just apply it? For technical architectures today we have to, it’s even written in a bunch of current software books. For instance, micro-services is without a doubt the architecture du jour today (and for good reason in the appropriate use cases) but it’s not for everyone. In fact, the author (Susan J. Fowler) of this book “Production-Ready Micro Services” and this book “Site Reliability Engineering: How Google Runs Production Systems” by numerous authors state pretty early on micro-service adoption requires big changes in tech and people and can be heavy lifting. Meaning, it really is for heavy scale and/or large endeavors like Uber (an author of one book) and the Amazons and Facebook's of the world. Ok, maybe not just those biggies, but it’s not necessary for every API with a handful of operations or a system with just a few dependencies to rebuild into a ultra-horizontally architecture meant for scale.


Of course, just about everyone is not Facebook or Amazon or Uber. What’s missing in the discourse is software that works well, controls costs and delivers business results. As much as the media loves writing about Netflix - they are exceedingly unique. Ultimately, it’s not a round of capital that makes a difference to our customers - it’s results.


With that, here are a couple of examples of products I respect and their approaches. Note, that both of these have evolved multiple, multiple times over the years and this is a bit of a look back to look forward.

Evernote

Sure, this is from 2011, but even then this was viewed as much simpler than most people expected. http://blog.evernote.com/tech/2011/05/17/architectural-digest/ Personally, I expected some massive worldwide casandra and multiple levels of distributed processing. Instead, they focused more on making things work well, consistently and managing cost.

They announced this summer they are moving to Google Cloud to take advantage of the super-stable cloud offerings and services they didn’t believe were worth it 8 years ago when they started.

Instagram

Another good read to see how people set out to create their products first. I had the pleasure of listening to their founders give a talk on this a few years back. Having spent most of my career in much more enterprisey (non-startup) spaces I was impressed by their sheer scrappiness.

https://engineering.instagram.com/what-powers-instagram-hundreds-of-instances-dozens-of-technologies-adf2e22da2ad#.wvx98zpjc

Sure, they did this stuff to get going, but then the next steps of growth wasn’t to move to the most complicated stack possible. I’ve never heard of the Instagram team re-writing all their Python to Scala. Or falling over themselves to move off of Postgres. If the domain isn’t that complex the tech doesn’t need to be. If the domain is complex, it’s expected that the tech stack maybe a bit more complex, but those organizations in particular have to drive towards simplicity harder because their most-simple will still equate to a simple domains’ most complex.

The tech media does their job so well - reporting on so many neat, new, scalable, composable, container-able, distributable, operable, asynchronous and autonomously intelligent systems we can miss something - making software our customers love. Often, focusing on the simple strategies, will produce the best grapes.

Great write up ! Inspiring in a way

Like
Reply

Rich Hickey's Simple V Easy talk came to mind as well. Thanks for sharing. A reminder to be more self critical.

To view or add a comment, sign in

More articles by Stephen Rylander

  • Software Development is Stuck

    As an industry, we are building systems and frameworks for software developers to use at a frenzied pace - more so now…

    6 Comments
  • Falling into the Pit of Succes

    Climbing mountains is hard. I've never done it, and I don't plan on it, but I've been told this by people I know and…

    5 Comments
  • Setting Development Strategies with LIFT

    Over and over, we refer to the preferred development strategy in LIFT Engineering (covered in my book, Patterns of…

  • Software Is Not Cheese

    The Problem A tremendous amount of literature exists on agile product development and lean product development and a…

    3 Comments
  • The Technology of EHS

    In support to David Metcalfe’s article (“Why aren’t EHS Professionals technology leaders?’) - it is surprising how far…

  • Times Change, So Do You

    I have been fortunate enough to receive many questions about leaving Morningstar and taking a new role this year. I’m…

    6 Comments
  • The Honest Reality of Technical Burden

    It’s Saturday and the first beautiful day for a while in Chicago. Across the street the neighbors are doing a pretty…

    6 Comments

Others also viewed

Explore content categories