We live in a bit of a crazy world nowadays! In general, but also in the world of software - and software is what I'm going to write about. Fast-paced delivery, fast iterating, all the fake agility (more on that one here), the buzzwords just being thrown around to pique interest, CEOs preaching some stuff that in more cases than not really make very little (if any) sense… quite a mess, really.
If you're simply outsourcing your work, you'll probably not gonna spend too much time thinking about what I'm gonna put the emphasis on here, nor will you care much. If you're, however, building something for yourself, an app, a platform, an API set, or whatever that you deeply care about how is it going to be used, then you'd probably want to keep reading.
Focus misplaced?
In such a world that we live in, the focus of development teams mostly gets put on hype and some purely technical challenges. Developers focus on fast feature delivery, on scaling and security even where it is not much necessary to focus on it (check here what Kitze has to say about that one), on things that are simply bringing attention. And after you deliver the feature you were building, you're usually just jumping to the next one, and the circle continues.
Just think about it, we're creating software solutions. More often than not, we have a predefined roadmap and the scope for the given software solution we're building (so agile, right?!). And more often than not, that roadmap gets delivered "a bit" slower than planned. When you think about it, those roadmaps usually include the performance-based epics for scalability levels we probably don't need from the very beginning even in some optimistic scenarios.
And don't get me wrong, the functionality should be a number one priority. But with the fast-tracking everything on that end, it gets really easy to lose focus from some of the additional things that are enhancing the end-user experience.
Usually, the roadmap makes you focus more on the above-mentioned technical stuff, hence anything that does not fit that agenda gets put aside and tackled "when the time is right". It often so happens that even so-called quick wins are being ignored (a quick win is basically anything that with low effort can improve the experience of the user - sometimes significantly). The point, for me, is that you really have to continuously dedicate time to the improvement of the experience your users have with using what you're providing them.
What is more important really, you having a perfectly built piece of software, or your end-user actually knowing how to do what needs from it even if that piece of software is not even close to being perfect?
To try and answer on that one, I'll walk you down the history lane, circa 600 years back, so sit tight.
The renaissance genius
Ok, so we're time-traveling now. Several sources say the year is somewhere around the 1430th, and we are in the city of Milano. Now, the Duke of Milan was organizing a high-profile extravagant feast with many invitees. He decided to appoint a certain someone to organize such a feast.
Some of you might already know the story, but for the rest - the guy that got appointed for the task was Leonardo da Vinci. This story is popularly known as the "Kitchen Nightmare" - does not sound much of a success, does it?
This story is usually used as a piece of inspiration for designers, but I find it equally relevant when it comes to creating anything else, really. Anyways, long story short, Leonardo was invited to help the kitchen staff handle that huge feast, and being the inventor as we know him, he figured to do a twist on it and enhance some processes he found not fully pleasing.
Beware that this actually happened hundreds of years before the industrial revolution. In preparations for the big feast, Leonardo came up with several new innovations.
Da Vinci developed a series of conveyor belts (basically what we now use in industrial facilities to move the goods, or in supermarkets at the cashiers) in the kitchen to basically bring food to cooks faster and reduce the time wasted on movement. That way, the time needed for food preparation would also be reduced.
In order to make the feast as pleasant as possible, Leonardo also invited a bunch of local artists. Their main job was to carve the dishes into works of art for guests to eat.
He also created a large oven for the food to be cooked faster, at higher temperatures than normal at the time. Again, reducing the time to prepare the food.
Leonardo also designed a (what is believed to be the first) sprinkler system for safety purposes, in case a fire broke out in the kitchen. With a sprinkler system in place, the security of all the staff in the kitchen would be enhanced in case of any firey disaster.
When you really think of it, the whole idea was to literally create the best possible user experience. There was some other stuff done in the preparation process, but I don't find them much relevant for what I am trying to achieve with this story.
The nightmare kicks in
So, the idea with all of these improvements kind of backfired.
What happened is that the kitchen was really crowded with people preparing the food. The conveyor belts, apart from acting erratic, were sometimes too slow and sometimes too fast so the food went from coming too slow to piling up. And due to the erratic behavior, the conveyor belts had to be manually tweaked more than a few times.
Food carving was taking more time than anticipated, which caused the guests to starve while waiting for their artsy meals.
The big oven was cooking the food much faster than the cooks were expecting, hence a lot of it got burnt. On top of it, a small fire broke out so it put a test on the sprinkler system as well.
The sprinklers Leonardo installed worked perfectly and killed the fire… along with ruining most of the food that was being prepared at the given moment.
So the general sentiment is that the Duke was pretty upset and ashamed, and Leonardo da Vinci got himself publically humiliated for what happened.
Moral of the story?!
Coming back to the present time, the year is 2021 and we're still stuck in our COVID-regulated world. The moral of the story is definitely not to simply go out and deploy untested stuff and without educating the stakeholders/users. It is, however, to think about how can you help improve the processes for those people to whom you are preaching, and whose problems you are solving - your end-users. It is to do your best to try and help, even if you end up failing from time to time, as Leonardo failed in our story.
Let's wrap it up
Functionality is the most important thing, so YES, whatever you do, first you make sure it works properly. But, whenever that is feasible, don't be the kind of developer/manager that will simply move on to the next feature or product and forget this one ever existed. Keep thinking about how can it be improved, and keep improving it!
Quick wins… for when you got neither time nor resources to make things perfect. Just think about what would be the minimal effort that would still make things better or easier for the user. Even if it is a temporary solution, that minimal effort of yours can be huge to everyone using the solution.
Be the alpha-tester of what you're creating. Keep thinking about what would you be missing if you were on the other side, what would make it easier, smoother, better for you in such a situation. Don't be one to just deliver and pivot to the next one.
That's my few cents on the topic, what would be yours?
Top comments (0)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.