I’m sure you have seen yourself, or at least heard of a handful of software development projects that have run into cost and time overruns. They are so common, it’s not even funny anymore. They blame it on the waterfall model; they also blame mis-alignment between business needs and final project specifications on the waterfall model. So they went to the other extreme, to AGILE. (for the record.. I am so fed up with agile all I can think of is puke when I hear that word).
In between these two extremes there is; somewhere, some kind of equilibrium. A space where software specifications still have importance, and when; by the same token, user stories also make sense. I mean ideally you have both; you care for the user AND the system. It’s not exactly rocket science. Some elements of the system need to be thought through thoroughly; beyond the consideration for the user experience. Lets call them server experience? who the fuck cares. Epics? lol. They are SYSTEM REQUIREMENTS.
The main reason why projects end up costing so much more than planned and taking so much longer than planned goes far beyond development methodology. It has to do with the inherent inability of human beings to care about what they call problems. In fact a problem doesn’t exist, they are all just situations; some situations you want and are ok with, some others are obstacles for you to reach your goal. You label them problems. But they aren’t problems. They are situations; they exist, you don’t want them to, but they do.
The first thing most humans do once they have identified a problem is label it. That’s the first step, they give it a name and by giving it a name they believe they have understood it. But that is incredibly superficial. Then, the second thing they will do is throw preconceived ideas at it, already built concepts. Which will end up being mistake numéro deux.
But all this is nothing compared to certain things i’ve seen. First they name it, then they ignore the existence of the situation and try to force it to become something else.. yes, but a lot of times, the process of making it become something else becomes a high stakes game of who’s who, a chance for team members to demonstrate their superiority at juggling concepts. In french I call this “enculer des meilleurs pratiques les unes dans les autres”.
Remember that what we are trying to achieve is get to the goal right? well, that whole focus just shifted. The goal isn’t go get beyond the initial situation now, it’s actually shifted to showing how superior so and so is to the goal. Remember also that the only thing you need to get to the goal is sit down with the situation for a bit, understand it and find an easy way out. THERE ARE ALWAYS EASY WAYS OUT. 99.99999% of the time. Yet, because nobody takes the time to really understand the situation and they throw all these concepts, best practices, design patterns, tools, and make sure to avoid anti-patterns, well, the situation doesn’t even matter anymore. Nobody is paying attention to it; the attention shifted to how we’ll include this pattern with that pattern while respecting this best practice and that one and avoiding this anti-pattern and that one too. Yet, did anybody even check to make sure any of this was necessary in the first place? Hell no, who does that kind of shit? Who’d lower themselves to the level of a boring, meaningless situation. WHO?
Well, I do. My friend Yann does too. We’re the people you call when you’ve fucked up and need a quick lasting fix. Or the person you call (in my case) when three people have tried to solve a problem for months and now you need a solution like yestermonth and you have run out of money. Yeah. Those people.
What happens when you sit down and understand the situation properly? Well the solutions generally aren’t very rewarding, most of the time they are frowned upon because they are so simple and meaningless. Yet.. in the world of computers where resources are limited and large volumes of traffic are needed; simple is king.
But does your solution respect this pattern, and that concept, and this best practice? To be quite honest, I couldn’t care less; but because you aren’t smart enough to evaluate the relevance of the solution with your INTELLIGENCE and would rather use your INTELLECT; well we’re in a dead end. I couldn’t care less that you understand or not; unless you dare to use your intelligence.
See so many people think they are related, intellect and intelligence; but truth be told they are polar opposites. One is borrowed, the other is owned. One is a reflection of reality, the other lives perpetually in the world of dreams. One is risky, the other one is safety. One is incredibly relevant, the other, well nobody really knows.
It reminds me of so many anecdotes. The first one, in 2001. I was working for Newtrade Technologies and well I was quite the rebel then and had major attitude problems and procrastinated a lot. But I understood shit fast, and needed a proper challenge. Anyhow one night while I was helplessly trying to deliver before the deadline, a big challenge found me. My boss came in at midnight, asking me to fix this javascript thing they had going on; hey that’s a challenge. And so I tore at it, and 4 hours later, I was done. Little did I know the team had evaluated the task would take weeks, and involve many people. And so the next morning when the team came in, I hadn’t delivered my piece because the boss had asked me to do something else instead, and on top of that I had delivered 120 man hour’s worth of work in 4 hrs. Yeah. Guess how they felt?
They felt that I was a problem. They felt like they didn’t like me so much after all, they felt like hey this guy needs to go. I was brought into the CTO’s office, to try to find a solution to the problem he’d caused. Eventually I had to choose between being fired to resigning. Yeah. Smart move!
Another time, I was working on a new phone OS’ prototype for Nokia back before Nokia became microsoft and was ruined. We had this awesome Meego phone going, and I had worked on the UX prototypes for a little under a year and the team in london was working on the real deal. Anyhow, someone needed to write an algorithm for reordering home page icons, you know drag and drop icons to new positions. Well, I got that going in less than 4 hours in my client’s NYC office one day before a trip to africa. Then some time after the trip I was sent to london to deliver the UX prototypes and help the team in the transition and this guy in the london offices had been working for over a month on the algorithm to re-order home page icons; and it wasn’t working yet.
One simple way to put it is over-engineering. The other is that people don’t take the time to sit down with the problem and get to understand it. In my case I never see them as problems; but rather situations. A situation is so that the flow of water goes south; and I want it to go south east. Will I create a huge apparatus to re-route water 100 feet over the land surface because best practice xyz says water should always be rerouted in the air, at least 90 feet over the land? Well you know what? I’ll go and explore the riverbed with a scuba diving suit to see if maybe something already exists that can help me reroute water flow with minimal effort. 99,999% of the time, there is already something, some solution but it is dormant and all I have to do is activate it. Yes. you saw that right.
Now take that at a large enough scale. Multiply this stupidity by the number of employees, and by the number of task they will each undertake. And then understand that this will inevitably cause performance problems because of the sheer amount of over engineering; and become hard to maintain too as a bonus.
All you had to do was go underwater (yes I know it’s scary and dark) and move 3-4 rocks to realign the flow of water. Of course you can’t know about this unless you go inside. Of course going inside means dropping your ego. Of course whatever solutions you come up with using this particular situation adjustment skillset isn’t very rewarding in the common sense; you didn’t have to work THAT hard for it. You didn’t use the gabazillion cool things that have become industry gold standards. You are right; it isn’t even rewarding. BUT IT WORKS. IT IS EFFICIENT. IT’S AWESOME.
So why bother? I call it Elegance. Back before agile became a thing; at a conference I had called it agile; I wrote my presentation using the word ‘AGILE’. But then this guy (whoever his name is) came out with the Agile Manifesto and ruined the word “agile” forever. Idiot.
I had to find another word, and Elegant came. It means, quite simply putting in the least effort while getting the maximum results with style.
This was part 1. There will most likely be like 12 parts to this series because of how many bloated design I produced over the years and also how many I saw. The worst always being with the government.