True cost is a total cost, which includes not only coding, but also: impact on quality (i.e. defect fixing), impact on design (i.e. feasibility to continue development), impact on complexity (i.e. risk to slow down), and impact on maintenance (i.e. run the app without developers).
Let me clarify right now - myth is not the possibility to have a quick and cheap software, myth is the belief that such software can do what you want it to do.
Everybody in the software development industry knows about the common problem - delivered software is nothing near what was asked. That's not because the requirements were not clear, and not because developers didn't want to do the good job. It's because doing a good job in software development can be defined in many different ways. What a non-technical customer thinks is a good software, can be a half baked application that cannot function well in many cases. It's not reliable, and importantly, does not deliver value.
It's very easy to end up with software like this. You just tell developers that you need something quick and cheap. It will be quick, but is it really cheap? You will think it is cheap by looking at the first check you are writing... Did you see the catch? I'll explain every point in detail below, and hopefully you'll understand what you are dealing with.
This one is easy. Let's say you asked for a small application with a simple use case. You get it in a week. You are happy and excited to get it to a couple of new customers. Before doing so, you try it out... and you discover something is not working, e.g. button on the screen is not doing anything.
You call your developer and she calmly explains that defects in software are a normal thing, and she will look into this issue you just found, and will fix it in a day or so. So you pay for a couple of more days of developer's time and get the button working... If only this was the last defect you are going to find.
This is where you realize that the actual work took 1.5 weeks, not just a week. So, you could have considered working with another engineer instead, who had much better reputation and seemed overpriced when she gave an estimate of 1.5 weeks with all the fixes and maintenance guaranteed. Did she know that this would happen?
So, finally you got your app into the hands of your customers, and they crave for another feature. You see this as a great opportunity to increase your customer satisfaction and attract even more new users, so you call your developer who helped you build the app.
After listening to the new plan, the developer tells you that it will take a month... but wait, this new feature is not any more complex than the first one, what happened? "Well", the developer explains, "you had to tell me that you wanted some new features in the future too. I built it so that it works fine the way it is. I never thought I would need to add something to it, so I need to figure out how to do that now... probably change some things and so on".
You scratch your head and ask yourself: is it supposed to be this way?
No, it's not. But you are dealing with the developer that cuts the corners just to deliver what you asked. Better developers, professionals, won't even give you such choice. It's the same as using a chewing gum to glue your tooth filling just because you are in a hurry. Do you think any dentist would do that?
Your user base is growing and you are adding more and more new features to the app. But something is bothering you.
With every new feature, number of defects to be fixed amplifies. You finally fix one defect and another one is popping out. You fix this one and the old one comes back. It's like a bubble that is about to explode. "Is this the limit or end of the road?" - you are scratching your head. You are thinking to hire one more developer because it seems what you already have is not enough. You need to see if your income really allows you to do that.
What you are experiencing is a typical slow down in software development. It's not normal, but it happens in most of the software projects, unfortunately. Only way to avoid it is to have the appropriate techniques applied to the software development, which manages complexity and allows acceleration instead of slow down long run.
Your developer definitely does not know much about it anyway, so never mind. You just need to realize how much every new feature costs now after the slow down. If you take all the features you have built so far, average cost is growing for each one now, almost exponentially.
You decided that the app has reached its potential, and it's time to invest into another great idea. Let the app run and bring you some side income, finally paying off all the investments into its continued development. You ask developer to show you those buttons that you need to click to send newsletters, to answer customer's tickets, and to apply discounts for Black Fridays. Developer gives you instructions, but that's a bit more than just pressing buttons. Then she records the video with instructions to help you learn those steps. Then she gives you couple of programming books to read, because it turns out you need some of those skills to maintain the app on your own.
What the hack?
Did you assume that every feature development would also include every bell and whistle for comfortable administration of it? I did too, because any professional developer would have done that, but probably not quick and not so cheap. Now if you add those convenience things to the app, it will cost you even more. Where is the logic?
No. You just need to decide what your long term priority is.
Building a good software is like investing money. Today you put some money down, and tomorrow you enjoy dividends.
This article is not meant to be an advertisement, but I want to clarify that techniques for building a better software exist indeed. I practice them on daily basis, and I train teams of engineers to do the right thing, for every single feature they deliver. Over time, I hope that those techniques will become part of a normal development process, positively affecting delivered software and customer satisfaction.
The author of the above content is Tengiz Tutisani.
If you agree with the provided thoughts and want to learn more, here are a couple of suggestions: