Evolutionary Apps
I’ll attempt to describe an approach to software development inspired by the natural world. It’s an approach that minimizes friction by following the contours of nature. I call it evolutionary; evolutionary software development or, more specifically if you wish, evolutionary app development.
The evolutionary approach is ideal for Indy developers because it leverages the indomitable traits which determine how a system (species) comes to dominate or compete in a category (niche), and do so successfully over time. It’s ideal because once a system has established itself in a category, minimal work is required to maintain it there.
When an app gets released into the world, if you’re lucky, a lot of people start using it regularly. It becomes successful. Its users get used to it. They get used to where things are on the screen. They get used to its undocumented quirks. They start using it in ways that are entirely unanticipated by its designer. And for this reason, as soon as something becomes popular, it becomes difficult to change without angering or alienating its users.
Once an app gains widespread adoption you can think of it as having found a niche, similar to how different species occupy niches in nature. Having found a niche, an app can remain relatively unchanged for a very long time. Again, back to nature, think of species that have been around since the dinosaurs, like dragonflies, sharks, or crocodiles. There are many such species who’ve sported the same basic design for millennia, relatively unchanged. It just works for the niche they inhabit. You might be surprised how long you can get away with leaving an app unchanged. Combine that with a subscription model and you have something potentially quite lucrative. Look at Photoshop for example. It’s essentially the same program it was 15 years ago, but Adobe continues to collect $50 a month for its millions of users worldwide.
Nonetheless developers and especially companies find it irresistible to mess with what’s working. You can attribute it to many things; from the obsessive compulsive nature of programmers to project-managers doing their “job,” in other words, justifying their paycheck.
Oftentimes developers will redesign something just for the sake of scratching their own itch, to try out some new fashionable framework or design paradigm. That in and of itself will piss people off no matter how flawlessly you pull it off. But odds are, the redesign will be accompanied with a slough of bugs and unintentional omissions that really send users into a blind rage. And they’re right to be upset because on the surface it shows a lack of empathy and respect by the developer for the users of his app.
Another anti-evolutionary way that developers alienate their users is through slow “corporatization” where an app that was originally loved by consumers is slowly morphed into an “enterprise-friendly” solution transparently geared toward attracting corporate dollars. You can tell when an app is under the spell of corporatization because it bombards you with a bunch of emails, popups and notifications about new features you have no interest in while becoming harder and harder to do the thing you originally downloaded it for. And on the app developer’s website you’ll see many emblems of certification and seals of approval by rating agencies and 3rd party auditors—all part of the hoop jumping required to land big corporate customers. Once corporatization takes hold, the app as it was, the app once loved by many, goes extinct.
Obviously one should not draw the conclusion that all redesigns are bad or, more specifically, that all redesigns are anti-evolutionary. That’s not true. You can redesign an app in such a way that preserves backward compatibility; in such a way that preserves all of the functionality that users have come to rely on including that which wasn’t intended by the developer. In other words you can do it evolutionarily.
But even if you are careful about abiding by the evolutionary approach when executing a redesign, you’re obviously not immune to human error and some, albeit easy-to-fix, bugs will make their way through. And one should expect those bugs to enrage their users. And one should expect them to attribute those bugs, and every inconvenience they encounter in the near future, to the redesign.
I’ll never forget a one-star review I received from a user after giving one of my apps a cosmetic makeover which accidentally broke a lot of things (I probably wouldn’t characterize this update as evolutionary.) Anyway, the reviewer said “Please repost the last known stable release because someone has gotten too cute for their own good with the latest update. SMH.”
Too cute for my own good. LOL. Truth is I was new to iOS development and the update, among other things, included a complete visual redesign of the old version which was horribly designed in my opinion. But this guy could care less because the app solved a problem for him. It was useful. And the cute redesign broke it. Fair enough. I shouldn’t have broke it.
Let’s turn our attention again to PhotoShop. It’s the canonical example of an evolutionary app. It has evolved over time with subtle aesthetic changes, and it has gained an adornment of new features as time has progressed but at its core it remains familiar to those who started using it over a decade ago. The multi millions of dollars of man hours that went into developing new features and adornments for PhotoShop over the years has been almost entirely unnecessary. A team of 3 engineers, or dare I say, a single individual, is entirely sufficient to keep something like photoshop viable in its niche.
This is why I say the evolutionary approach is ideal for Indy app developers. Because once an app is established, a relatively minimal amount of work is required to maintain it. Of course you need to pay attention and stay up to speed with changes in the platform(s) on which its built. And it’s always nice to deliver periodic design refreshes. But as long as you’re disciplined about making evolutionary changes (i.e. avoiding changes that break backward compatibility and alienate your users) then you can be confident that you’re leveraging past work.
Think of this as the most frictionless approach to development. The obsessive compulsive impulse to redesign and refactor is suppressed in favor of additive changes. Typically such changes manifest as git fast-forwards which, when reasoned about, are theoretically incapable of breaking something.
So the evolutionary approach is something to strive for where creative effort can be channeled into new endeavors instead of remixing the same product ad infinitum to the great annoyance of users. It’s less work to maintain the apps you already have so you can have more of them spanning a wider array of categories, diversifying your app portfolio such that one of your apps can go extinct without endangering your entire portfolio.
