The cost of software development. A developer’s perspective.

I’m writing this to help managers, clients and anyone that is not a tech savvy or doesn’t come from a technical background understand what is the cost of building big software products.

But what does it mean? Well, the easy answer is that it depends who you’re asking. E.g. for the client the cost is money (how much they pay for a the product). For a manager could be the resources (how many people, computers they assign for something to be done). For employees it would be time. This might be a bad analogy, but bear with me for the next minute.

Everything resolves to demand and supply.

• If the client demands that his product would be ready to hit the market quickly, it would cost them more money;
• If the manager wants things to be done faster, he could assign more resources to the project;

If the developer would like to go a little faster.. what could that cost him?

Time is a limited supply. You can’t just say “Ok, boss. If you want to this by tomorrow, this day will have 82 hours instead of 24.”

So how could you go faster anyway? There are many articles about people that code 6 hours a day are less productive than people that code 2 hours, but that’s relative.

Story time
Let’s take Bob as an example. He is a software developer with about 5 years of experience. He works for a small company where every developer is working alone or in pair on a relatively small project for some client. He is asked to create a dashboard for some client where he can manage his employees. His first task is to create a small web page where the client can see a list of the employees, their information like name, birthday, position, hours worked, salary. He is also told that the client must be able to edit the information
displayed.
Oh. He is also told that needs to be done as fast as possible! They forgot about the client and the deadline is in a week. (This actually happened to me)

For the simplicity of this example let’s assume Bob has done projects similar to this one in the past and he has already a design for the website, the credentials to the database or any other details to start.

It’s Monday morning. Bob thinks for about an hour what he has to do, reads the requirements a few times, he does a mental plan on how to do it and gets down to it. Bob knows that this is very important and must be done really fast. His manager made sure to put pressure on him so he works at 110% capacity.

Bob spends the first day connecting to the database, writing logic to fetch the employee information and process it.
On Thursday he modifies and adapts a template for the web page to display the data according to the design.
On Wednesday, to save time, the website connects directly to the database through a backend that just translates the http request into requests to the database.
On Thursday he integrates his work from Wednesday with the UI and start working on the Edit and Update functionality.
On Friday he manually tests as much as he can, fixes small bugs and declares the task Done.

The manager is pleased — “You did it, Bob!”. The client is pleased — “The dashboard is nice! I’m pleased”.
Bob is a little proud of himself for finishing the task, for being the one that the manager asked to do this. Bob gets an increase in pay. He thinks he has done something well. Spoiler alert: He will soon find out that he is wrong.

A few weeks pass and the Client asks for another feature. He would also like to be able to rate an employees performance through the app and at the end of the month. The client expects to be done rather quick, since it only took a week to build the entire dashboard.
Bob gets the task. He completes it in one week, which is reasonable. This feature is not as big as writing the project from scratch, but still OK.

A few more weeks pass. The client has hired a few more people and he has noticed that he still has to add their information manually in the database. He would like to use the fancy interface to do it. He still expects it to be done in one week.
Bob gets the task. Bob fails to complete it in one week. He actually takes two weeks. The manager was disappointed, the client was disappointed. Bob was not surprised. He knew he was leaving a mess in the code because he had to do it fast. Really fast.

Then another change is asked. This time something small, he would like to move some panels around. Bob took two more weeks to complete the task.

You can see where I’m going with this. But why? Why is Bob becoming so slow? Is he becoming dumber? Is he working less hours? Is the manager’s fault for pressuring him and setting unreasonable deadlines? Is the client wrong for asking the changes?

Many questions. Twice as many answers. Bob is not dumb, but he was not smart enough working like this. We’ll talk about this later.
The manager did what he knew best — to manage, motivate and make sure things are getting done.
The client, obviously, is not wrong to want changes or features.

So what did it cost everyone, anyway?

Who is actually wrong?

Bob is now stressed, thinking he might be getting fired someday because he is not performing as well as he was in the beginning of the project.
The manager is now under watch by the bigger managers because he guaranteed that he could get things done.
The client is furious because the firm ‘has become lazy’. He payed hard earned money and was told that things would’ve been done. Not going to leave a positive review for sure.

This does not sound right, but it does sounds like something I’ve encountered personally and like something I’ve heard my friends talk about.

What about who is actually wrong? The client is never wrong, even when he is, because he pays. If you think your client is wrong, perhaps he didn’t pay enough — objectively speaking. He might ask for unreasonable deadlines, but the manager has to deal with that.
Is the manager wrong? Well, no. As I said, he did what he does best. He knew that the deadline was not reasonable, although he pressured Bob to work faster.
Bob is great, he acted with the best intentions to finish FAST. Or did he?

What does it mean to go fast?

Bob did great at the beginning of the project. That’s only because there was no code before. No code = nothing that’s wrong or difficult to modify or hard to maintain. It’s a blank canvas, waiting to be transformed into art. Or spaghetti in Bob’s case.

When did things go wrong? When Bob was asked to modify something, to add something to the existing codebase. This is the part that most managers find difficult to understand. Imagine you’re adding forniture to into your home: a bed, a table, a sofa. When the room is empty, that’s easy, there’s room to maneuver the forniture. Ok no take the bed out and add a new one. A little more difficult, ain’t it? Not as much room as before, you have to move stuff to make space.

Going back to “people that code 6 hours a day are less productive than people that code 2 hours”. If the codebase is messy, you will spend hours trying to understand why something breaks or how it works so you can modify it. If the codebase is not existing, and you’re beginning it. Then you can be more productive writing code for 6 hours straight, which rarely happens.

“But there are there codebases of hundred of thousands of lines. How can they modify something and not take one year?” — Marcel, manager. To answer this question let’s think how would you do it if you have a lot of things in your room and have to swap the bed.
Well, you could arrange your room in a manner that would allow you to do so quickly, and not throw all the things together with no order. Order. What a beautiful word.

If the codebase is a mess, it would take an exponential amount of time to maintain or modify.
How can you keep your codebase from not becoming a huge pile of spaghetti con bolognese?. The key word is refactoring. You rewrite the parts that are a mess. Every time you modify something, you leave it a bit better. That is if you’re a developer.

As Robert Martin said: “To go fast means to go well”. To go well means to use abstraction, to name variables explicitly, to use design patterns, to write unit test and automatic tests and much more.

But how do you deal with a unreasonable deadline? As a developer you have to explain it to the manager in a way that he would understand what cutting corners to do things fast would get to. (Pro tip: who them this post).
Once the manager understands this, it won’t move the deadline, he can’t most of the time. He can only set expectations accordingly and do his job accordingly.
The client is the hardest to convince so I wouldn’t bother. Just tell them things might get difficult on the long run, but give no detail.

I still have to do work really fast, cut corners, don’t test enough and deliver quick. But after that, after the expectations has been set and everyone would understand the cost of software development if not done properly I try my best to clean the mess I did in the first part and continuously improve it. This has to been done in balance with adding new features.

Let’s say if I have to do something that might take me a week to do, I’ll take a week to do it properly plus a day to refactor the part of the codebase I interact with.

Here’s another tip. When discussing requirements, try to identify the parts that might change the most frequently. The developers might use this information to write code that allows modify with ease. Like the UI. Clients love to change the UI. This should never break your code. The UI should be well separated from the actual logic of the program.

So, as a developer, I try to write the best code I can in every circumstance. I try to best present the issues of each approach I can think of to people that don’t understand how developing software works. Deadlines are a thing because without them we would never finish. I think that everyone should understand what’s the cost of their decisions.

I’m not perfect.

I’m writing this to help anyone who’s interested and who would like to hear a developer’s point of view.

I still learn, still google how to do stuff and how to improve my skills as I know many of you do. I still write messy code just to go fast because in my circumstances is the best approach. I’ve separated the projects into phases because sometimes the time to market is the most essential thing for the client. Once the idea is validated we move to phase two where we rewrite almost everything the way it should’ve been initially and add new features. I still use abstraction, design patterns and general rules of separation of concerns, but I still create a mess. It always happens, but you should always try to fix a little bit when you’ve got the chance.

What should you take from all this.

If you’re a client wanting to know how much money software development costs, then I’m sorry. It’s now what I had to say.

If you’re a manager try to understand that doing things as fast as humanly possible is not always the key to profits. Sometimes you have to do a little more planning and when it’s not possible, manage resources to fix it along the way. Don’t ignore it.

If you’re a developer try to learn about clean code, clean architecture, design patterns and all the stuff you already heard of when talking about how not to leave a mess behind. Also, talk to your manager, help him understand too what’s the cost of rushing things.

Thank you for reading. I hope it has been useful to at least some of you :).