Strive For Simple In Everything

Having shipped software for more than 30 years now, in many different environments and industries and forms, the one thing I’ve found that distinguishes the best projects from the not so good ones is Simple.

Simple is not simplistic, it isn’t quick and dirty, it isn’t lazy, it usually takes longer and it’s not doable without imagination and creativity. Simple is also not just about writing code, it involves everything associated with building software, from people to processes, from how you make decisions to how you organize their implementations. Simple is an attitude, it has to pervade everything you do and how you think and you can never stop looking for it, because as soon as you allow complexity in it will take over everything and you won’t be able to remove it again.

Simple sounds like snake oil, it seems too easy a word, too primitive to possibly matter. After all modern software is itself complex, with so many demands on what it has to do, so many requirements, so many interactions with other software, and constant worries about security. How can such a simple idea make any difference? Isn’t this yet another ideal no one can ever match up with?

I learned about simple back in the “dark ages” when C was barely a language; we shipped apps on plastic disks in boxes to computer stores, we had little modern tooling, no repository, no internet, no Stackoverflow, no Google, barely a bug database, no email, and unless they called us or sent in a reg card, no clue who our customers were, no idea what a process was and computers slower than your toaster today. Yet despite all these challenges (that no one would put up with today) we still shipped quality apps to real customers for money, shipped many versions on a regular basis, and never thought ourselves as deprived.

What we also didn’t have were many of the irritations of today as well. No servers, no test harnesses, no tickets and story points and user stories and estimates, no interminable phone meetings, no security worries, few choices on tools or languages or frameworks or arguments about CI/CD or environment promotions or having to make a zillion choices about everything, and especially thousands of unread email messages begging for replies. What we had was the time to write code, to figure out how to do things without distractions; back then we had to imagine solutions no one had considered before and actually take the time to find the right one. Of course we also had to depend on each other without access to the world at large and everything it knows.

The point is in the absence of most everything we have today, simple was sort of the only way to build anything since we really couldn’t do it any other way. No one asked me to estimate a user story in points six months in the future that I would be held to, requiring me to guess about how I would do something without knowing a whole lot about it. Vague was good enough to get started on in those early days. Back then we didn’t think about process, we just did what came naturally, which today mostly resembles a lean approach. It was the simplest thing that could work and it did. Anything more than that didn’t seem useful. We heard no voices clamoring that we obey some dictate. For that matter we had almost no idea what anyone else was even doing.

Today we are so overwhelmed by demands on our time, meetings, emails, slack, estimations, grooming, planning and sometimes yelling that the end result never approaches simple. We build whatever we can squeeze into the estimated time, there is no time to think or consider, just do and move on. We skip experimentation, we hire people to tell us how to do it faster, every time we screw up we add more process, more meetings, more sign-offs, more blockages to progress all in the name of faster and cheaper. We desire to save money and hire random people on the outside which requires more management and usually results in less quality and more rework and angry customers and pissed off workers. We obsess over code reviews for everything and everyone and demand more complex testing automation and everything must be dockerized and in the cloud and it must be there right now or … what?

The more complexity you add to any system the less you understand what it is doing, the less you see what the customer will see, the harder it is to change, the further behind you will get. Every project we do at my job is like this. Sure, it's a huge company, but our actual software needs are much simpler than our insanely complex process and environments and decision making and expense would indicate. In the end everything is late and later and sometimes we wonder if anything will ever ship. I am sure we are not the only people in this boat.

Simple is incredibly hard to keep going; maybe it really is impossible and the simple I’ve experienced over the years, even as recent as 3 years ago at the travel company, is just too hard to accomplish any more. As software people we seem to relish complexity, often done in the name of making things easier while we really wind up making them harder. I remember the first few javascript single page apps I built with maybe one framework and how much fun it was. Now I look today at web development and think: even J2EE development in Java was simpler back then. Despite working in iOS and Swift, keeping our codebase simple and easy to understand and remain flexible in the face of our mind-numbingly complex product (with its dozens of systems and teams and constant change) is not an easy job.

I often use my work in the mobile team at the travel company (whose brand was sold by our parent company and everyone laid off and all technology abandoned) as an example of how a simple mindset and real agile thinking can make a small team make a huge difference. We did 15% of the company’s revenue with only 2% of the employees. Our process was very light, everyone involved in the products we had (6 apps, mobile web and a backing mobile API) sat together for the most part, decisions could be made without getting up, we had a single manager who acted mostly as a guide and priority setter, we managed our own infrastructure (early AWS), we had no committees, no daily shiprooms, no one telling us how to do anything, no sign-offs, few if any hard estimates, no user stories other than brief overviews, no story points, no tickets, and especially no long meetings. Yet we had constant communication in almost real time, we had consistent QA, people with a deep understanding of what everything was supposed to do, and everyone was looking to help each other out. We did have politics to deal with of course, the rest of the company wasn’t too fond of us since we cranked out products and they were stuck with a monolithic web app that they barely could ship updates to twice a year. The CEO was our biggest supporter which helped. Even when he drove us nuts it still turned out well.

There was no special magic about any of the people, but the fact that we were left to our own devices (the manager had started the mobile team 3 years before I joined in the early iOS timeframe) allowed us to find a balance and process and rhythm to getting things done. If our parent company hadn’t had their need to dump us onto the their biggest customer (our competitor) I’d still be working there today. I like shipping software, I like making a customer happy with good products, I like getting things done with the least amount of fuss.

Sure today I work for someone who will never go out of business, but it isn’t all that much fun, and everything keeps getting more complicated and frustrating. We have too many teams, our main apps have 5 dozen repositories they are built out of, we have more committees and boards and policies and prescriptions and teams that no one can actually keep track of. We have to have massive processes to even get anything done. Add to that complex politics and game playing and finger pointing. How does any of this result in a good product for a reasonable expenditure? It doesn’t. We aren’t a technology company per se, but we need technology to do things, and everything we do with it is painful to the extreme.

The apps we build here and the apps (particularly the iOS 7 launch day app) we built at the travel company are actually similarly complex. Yet we built that brand new travel app with 3.5 people, 1.5 QA, a product manager and a designer in around 5 months plus some part time work I did before we started. Here we have 5 dozen repositories and I still can’t count all the teams; probably 100+ people directly involved. We have to have more meetings than I can even attend to coordinate things and it still goes off course a lot. This is not simple.

I still remember back to that first app (Trapeze) that shipped for the first time 30 years ago last month and how easy it felt even though everything was new and we had little of what we have today and no idea what we were doing. What we did have was simple and lots of it. What we did have was time to figure it out.

I have lots more examples of both simple and the opposite but there isn’t enough room here to discuss them all. I am sure all of you have your own stories.