We’ve got some extreme software development experience in Aista. I sometimes jokingly say that “our junior developer has 22 years of professional software experience”. This puts us in a position where we’ve over time accumulated knowledge and experience in what it takes to deliver a successful software project. Below you can see the top 5 reasons why software projects fails according to our experience in this space over a lifetime of building software that simply works!
1. No idea what to build
This is far more common than you think. The parody of this of course, is some guy in Europe having seen Mark Zuckerberg’s bank account statements, with 5,000 EUROs to spare, contacting some 3rd world outsourcing company, with a specification that says.
Build me a better Facebook
This is wrong on so many levels I’m not even sure where to start. Unless you’ve got passion about your product, you might as well give up before you’ve started. A person “wanting to create a better Facebook” does not have passion about the product. More importantly, he’s got no ideas how to do it either, and believes he can “delegate” the solution to some 3rd party.
The fix for this is actually quite easy, assuming you’re building something you’ve got passion about of course – And it’s to spend more time planning what you want to build up front. This leads to fewer iterations, less changes into the project, higher predictability, and accountability for the hands delivering it. The amount of energy required to apply a change, grows exponentially according to the amount of time that passes since (the flawed) logic was implemented. This is true for bugs, and it’s true for features and project trajectory.
Spend more time planning what you want to build, to save time as you start building it.
2. Letting the junior start the project
The fact that this is as common as it actually is, is a parody of itself. You wouldn’t let the least experience builder create the foundation of your skyscraper would you? Still, in software we allow for this to happen all the time. When you start a new software project, you need to dedicate time to your MOST experienced software developer(s) to initiate and start the project.
The initial project structure becomes the architecture of the project. If all decisions were made by somebody without the experience to initiate it, the destiny of the project becomes to fail over time. The reasons for that the juniors tends to get to start projects is quite simple though. The seniors are typically busy with your “business as usual projects”, ensuring these are running – Probably paradoxically because your BAU projects were initiated by a junior developer may I add. So your most experienced team members rarely gets the chance to start out the project, resulting in a vicious circle where your entire company’s software foundation inevitably over time turns into mud. The big joke about this is that it’s basically the equivalent of …
Letting a child create the architectural drawings of your space shuttle
When spelled out like the above, it probably makes more sense. This needs to stop! Seriously, it needs to stop!
3. Hyped technology
I refer to this as “CV based software development”, but it’s basically an internal developer, lacking experience in some field, wanting to use a specific technology, to add to his experience, making him or her more valuable as an employee in the future if looking for higher salary or a better job. It’s really just a special case of misaligned incentives, where the incentives of your employees are diverging from the incentives of your company as a whole. How would you react if I told you the following?
At Aista we CONSISTENTLY choose the most boring tech!
The reasons are simple; We’ve got so much experience, we’ve got nothing left to prove. And we’d rather have a happy customer, then learning the “new and shiny stuff”, that will inevitably anyways be irrelevant 5 years down the road. The worst case of this I ever saw, was a project that had.
- Serverless Azure Functions (because “it’s cool”)
- CosmosDB (because “it’s NoSQL”)
- Logic Apps (because “it’s cool”)
- 3 different frontend frameworks (I have no idea why here to be honest with you)
When looking through the project’s source code, I got the distinct feeling that the main architect that had initiated the project like this simply because he had “holes in his CV”, and needed to fill them. Needless to say of course, but the project was scrapped after having spent some 1,000,000 EUROs trying to fix a codebase that was literally dead before it was even in BETA stage!
At Aista we consistently choose the boring stuff, because it works, it’s proven, and we know the client is going to come and ask us about statistics, grouping, and joins over time – So for 99% of our cases, we simply drop NoSQL. No need to start out the project using something you know for a fact will create trouble further down the road. As to Azure Logical Apps and Azure Functions? I’ve got one word for you; LOCKIN! Look it up if in doubt …
4. Lack of supervision
This is one of those consequences often experienced by outsourcing your projects, because the client doesn’t follow up on the company that’s to implement the actual thing. It’s not that the outsourcing company is lazy or anything, they just don’t know what to build unless you clearly communicate it to them – Preferably at least once every single day.
This is why we in Aista will start out the project with hundreds of boring questions about your project, such that we can avoid both number 1 and number 4 here. It’s better to spend one extra month up front getting to understand the project’s requirements, then to spend 2 additional years further down the road to abandon the project entirely, and start it all over again, because the developers implemented something completely different then what the client expected. This is one of those places where the “law of exponential diminishing returns” as a function of time kicks in.
The cost increases with the square of time that’s passed since things was set in motion towards the wrong direction
The above should probably be referred to as “Newton’s law of software projects”, or maybe the “11th law of mechanics” or something. It basically implies that the further away from the path you want to walk on you’ve moved, the more energy it will require to bring you back to where you should be. It’s really not rocket science when explained like that.
5. Fill in the blanks
To turn this into a discussion, I’ll leave this one blank. Do you have suggestions? If so, please add them up in the comment section, or even better, if you’ve got a software project you’re starting these days – How about getting it right from the beginning this time …?
However, I’ll give you a hint; KISS! Or lack of thereof to be specific …
Top comments (2)
yes yes and yes, I have seen all the reasons.
i would add: failing due to the inability to fail.
softwareprojects set goals, but often they are soft goals. this specially happen in big companies. it was invested to much so the project can no longer be stopped. But it also can not really succeed. in the end of a financeround, there will be something found that was ok and that was achieved. just enough to keep the project go for one more round,...
Brilliant point. Sometimes the big rewrite is simply needed