The quest for perfection
When looking for the ultimate perfection, one must reject obsolete concepts and defunct perspectives, the hopes of the future and nostalgias of the past. Instead, focus only on the infinitely short period of time called now and immersed in its blazing sway, allow themselves to sense its presence.
Perfection is timeless, but we are not, and our appreciation of perfection changes with our now.
Chapter I: The legacy conundrum
A natural tendency I have observed, in my 20+ years of service as a professional designer, developer, architect (and everything in between and around) is the capacity to complicate things, which grows proportionately with age.
Where a student or an intern would come up with a solution within an hour, a senior architect takes more time than that just to schedule all the required meetings so that he can start discussing the plan to best prepare the available resources to devise a strategy and design a workflow around the team so that they can start ideating on the potential approaches that would (eventually) lead to a solution (someday).
Exaggerated, but you get the point.
Student's solution may be far less robust, may have some bugs, may cater for only one scenario and have plenty of assumptions and other limitations.
Whereas a good architect will predict all possible scenarios and use cases, cater for proper security measures, think about the potential scalability challenges down the road, design with accessibility in mind and tackle performance from the get-go. His solution will be robust, flexible, scalable, efficient, and… completely over-engineered.
Don't get me wrong. I'm all for quality products and well-designed things. But so many of them in this world are shooting themselves in their feet because of this invisible trap:
- You have a simple idea for a thing. A perfect little app to do "A".
- You want to make the best of it, but in the process you realise that with some small effort it could be even better if it was doing "B", "C", and “D”.
- It just needs some tweaks here and there and maybe a hinge here and a crank over there and some widgets. Yes, widgets always make everything better!
- But now "A" doesn't work anymore.
- Who cares! No one needs "A" if you can have "B", "C", and "D".
- And perhaps "E" and "F".
- And “G”. Maybe.
And then you release it.
Ending 1
No one cares, as your app is no different from gazillions of other apps.
Your app dies of natural causes.
Ending 2
Everyone likes it (with a "but").
Suddenly, the alphabet is not enough.
People want more! More features, more releases, more stuff!
There are bugs everywhere, nothing works anymore, and no one even knows what's the app supposed to do in the first place.
App dies of attrition.
Chapter II: Enemies of Perfection
Perfect things do not suffer from the symptoms described above. But they do have some enemies lurking around every corner of creation.
Unnecessary complexity
Hitting the right balance between simplicity and complexity in design and architecture or a product is very difficult. Agile development was “invented” to fix this, and partially it did, but it has also created another universe of problems in the process.
Products were not designed from start to end, before going to production.
There was this mythical MVP, which in layman’s terms is a product in its simplest possible form so that it is (barely) usable. Thereafter, in a blissful harmony of communication between the development teams, quality assurance teams, dev-ops teams, UX design teams, architects, project owners, project managers, business analysts, development managers, and – finally – the divine Customer – the rest of the product is slowly developed.
On the bumpy road to every one of the frequent releases there are repeatable periods of breaking things and then fixing them again, of radical changes, and PoCs that bring them, of waiting for CI builds, and issue shuffling, so that they guesstimatedly, but exactly fit the sprint length, leaving time necessary for re-testing, re-fixing, re-reviewing, and re-doing whatever is required to push the release over the fence.
A forced change
Agile development – like most theories – sounds wonderful on paper. But in the wild, real world, where money is the principal decision maker – it is what it is, and with all its processes, it still looks best… on paper:
- Planning around your sprints, not features:
- If a feature does not fit into a sprint, it must be cut and chopped. So that we can release the product with half-baked functionality. That's ok. We have feature toggles! (to make it simple and easy, of course! /s).
- If it's too small – that's ok, too. We'll find one that can fill the remaining time (not necessarily one that is actually needed the most). - CI/CD – continuous integration, continuous development, continuous delivery – everything, everywhere, all at once.
- Frequent releases – you don't release your software when it's ready, you release it on Tuesdays.
- Hippo – one more factor when it comes to unsolicited changes.
Expectations
A well-planned product has a phase where requirements are gathered, market is researched and business is properly analysed and – most importantly – understood. The correct conclusions are drawn and fed into the grand design.
But if this phase – with the limited time or some management rotations – fails in even a small bit, a product ends up with:
- Conflicting requirements – two of our five potential users want something rather different from what we initially planned, so we'll be changing our plans.
- Wrong assumptions – our house is designed for short people, so we will never need to build doors taller than 150 cm (or 5ft).
- Trying to satisfy the wrong audience – often happens when we have ideas about our users, that we don't validate. And also – hippos.
Story time again
Imagine building a house this way:
- You start off with one room on the ground floor and then decide what else you need.
- You add a second floor because you’d like to have stairs.
- Oh, you need a kitchen – you add the kitchen on the ground floor.
- And a living room, of course. You can even build it around your already nicely placed TV.
- You decide that your first room on the ground floor is not that great, so you move it to the second floor.
- Then you add 3 more bedrooms.
- The area of your second floor is now bigger than the ground floor, so it has to be supported by columns. You don’t like columns, but there’s no other way at the moment.
- Then you change your mind about your living room and decide it’s better to have it on the right side of the main entrance, instead of the left. You “delete” your living room and build a new one on the other side.
- Part of your second floor collapses, as there were not enough columns available to support it. That’s ok. You can fix it later. You just lock the door to the collapsed room, so no one goes there.
- You’d like to have a basement, but you are not sure if it is possible in this area.
- You build a PoC basement in a field nearby. It works. So now you “delete” the PoC basement and recreate it under your house. Some walls started to sink in the ground. That’s ok. You just put a fresh paint on them, and they seem to look fine if you stand in a particular spot in the room, and there’s not too much light.
- It started raining. You don’t have a roof yet because it was not the coolest thing to work on, so your house becomes a pool.
- You put some canopies here and there and design indoor gutters, so that the flow of water can be managed, and doesn’t get in the way too much.
Result
This approach to creation is very wasteful. It wastes resources (dehumanised word that managers use when they discuss the actual people), wastes time, building materials, and energy (both electrical and personal).
Moreover, at no point the house is actually liveable. All this leads to:
Over-engineering
Creating elaborate solutions to problems that should not even be there if things were done properly from the start.
Feature creep
With so many teams and people working and contributing to the product, everyone is a designer and knows best what to do. Features are added that are not necessary and not really useful to anyone.
Poor workflows & processes
Because nothing is really well-designed, well thought through and well done, and because everything is constantly “in the process”. Where making one thing simpler, makes other things more complex.
A humongous overdose of tools
Because everything is so complex, we need more tools for everything. We can't trust people to do their job properly, we must automate it with tools:
- Tools for generating project scaffoldings,
- Tools for generating project modules,
- Tools for managing dependencies and 3rd party packages,
- Tools for checking and "fixing" the code that humans wrote
- Tools for building all that mess,
- Tools for checking if it actually has built,
- Tools for publishing artifacts,
- Tools for testing the published artifacts,
- Tools for deploying the ones that happened to work this time,
- And tools to manage all the tools above,
What do we get from all this? Ultimate complexity. Where fixing a typo in a comment takes half a day, and fixing a simple bug is a team effort and never ends.
There's also one other issue. Dependencies! Because we’re moving so fast, we cannot afford to do the basic stuff ourselves. We must use other people’s work. Who are those people? Do they even know what they’re doing? Did they check their dependencies? We don’t know, and don’t care. They released a package that adds a space to a string – that’s enough for us!
Chapter III: The eligible alternative
So, what's the alternative to all these over-hyped cool-words?
Creating Perfect Things, of course!
Making products not for profit, not for sale, and definitely not to satisfy someone's ego.
Making products that do one thing, and do it well – was an excellent principle, that seems forgotten nowadays.
Making products because they are useful, beautiful, or because they help someone.
Not because we can.
Epilogue: Perfect Criteria
How does one assess whether “a thing” is close to perfection, or rather on the opposite spectrum?
The criteria are quite simple, besides, of course, being utterly subjective, e.g.,
- Does it do the things you want/expect it to do?
- Could it possibly do these things any better?
- Does it do things you don’t want/expect?
- Does it bring you joy when you look at it and use it?
- Does it get in the way when you do your things?
- Does it change frequently or radically?
- Can you become better at using the app with time (become a power user)?
If you answered: yes, no, no, yes, no, no, yes, to the questions above – congratulations, you are in the presence of perfection!
Otherwise, keep looking :-)
Obviously, you may want to ask different questions. Other qualities may be more valuable to you, or you simply aren't concerned with some of those. And that's perfectly fine. It's important and quite enough to have requirements, but also to stick to them and avoid compromising as much as possible.
Feeling emotional
What else may help us in our quest for perfection?
A more technical person would probably mention: usability, ergonomics, accessibility, and overall user experience.
A less technical might just say: “love it” / “hate it”.
All these technical terms help define or assess the quality of a thing. But even without knowing them, one naturally prefers a thing that exemplifies the correct balance between these qualities, sometimes without realising why.
But yes, ultimately it all boils down to personal feelings.
"I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel."
Maya Angelou, famous poet and civil rights activist.
This goes for everything: apps, services, garden tools, food, or mittens.
The thing is, people usually don't really know what they want. Steve Jobs once said:
“Some people say, "Give the customers what they want." But that's not my approach. Our job is to figure out what they're going to want before they do. I think Henry Ford once said, "If I'd asked customers what they wanted, they would have told me, 'A faster horse!'" People don't know what they want until you show it to them. That's why I never rely on market research. Our task is to read things that are not yet on the page.”
But people do have opinions and the lower the knowledge about the subject, the more their opinions are dictated by the “gut feeling”.
And I suppose this is the most important criteria for us: if we have 2 products, both of them work and do what we need, we will always choose the one that makes us feel better.
A logical mind
But perfection is much more than that!
It’s flawless, beautiful, and timeless.
It does not answer to fads, much less to someone’s “guts”!
When the initial infatuation gives way to the logical mind, material fatigue begins to uncover even the tiniest cracks in every product.
The feelings are overclouded by more rational criteria, like the aforementioned usability, accessibility, and ergonomics, but also by the harmony between the user and the product.
Whether the product is an extension of the user, or rather a liability.
Whether one’s needs and expectations are satisfied by the product and the smoothness of the process.
And, finally, whether the initial seed of affection has grown into luxuriant respect between the two: the user and the tool.
Member discussion