This article was originally published in my blog smartpuffin.com.
Not so long ago I hired a team of freelancers to work on a project of mine.
Everything started as it usually starts. I found several teams, some through friends and some - through a website. I met with team leaders, we discussed my requirements, we agreed on time and on a budget. I picked the team that looked the most reliable to me, they rolled up their sleeves and started to work.
Beginning of work
On the first day we discussed the requirements again. I listed the requirements again and added a couple of new small ones. The freelancers agreed with everything. Even with the new requirements, said they, it was still plenty of time.
Great, thought I.
They started briskly, did quite a portion of work the very first day, and didn't require much handholding. I went home pretty reassured that day.
Time passed by. I let them work in their own pace. Some days I didn't see what they were working on. Some days they didn't show up at all. More often than not, I saw them walking around drinking coffee and enjoying the view. Still, they kept telling me they'll be on time, and I trusted them.
I didn't care how exactly they were working, I only cared about the work being done.
First bug
Then the trouble started. Looking through the half-finished project, I noticed a huge bug. It was very visible, hugely annoying, and prevented the project to work.
I pointed it out to them. They were immensely surprised. Apparently, they didn't see it before. Couldn't I live with that? No, I couldn't. Okay, they said, it's a shame, but it's quite some work to fix it. But we're still on schedule.
First bugfix
Okay, how are you going to fix it, asked I. We don't know, they told me. What did I think?
I didn't think much, because I wasn't very familiar with the details, and also I wasn't an expert in that area. We brainstormed together. Then they brainstormed on their own. A couple of days the work wasn't moving forward - everyone was thinking on the solution. Finally, the solution emerged, and the work continued.
Are we still on time, asked I? Yes, very much on time.
More bugs
Of course, bugs like that one happened not once and not twice. Features got forgotten. Features were done badly. Sometimes, I had to ask to fix the same problem several times.
Deadline is approaching
The deadline was approaching quickly. But the end of work seemed far away to me. Are we still on time? Yes, we are. I asked every day and got this answer every time.
I started to get more nervous and checked on them more often. More and more bugs appeared and features got forgotten.
Deadline
The deadline was on Friday. You might have already guessed: they didn't finish on Friday. But they promised to work during the weekend, and they would finish 99.9% of the job by Monday.
After the deadline
You might have already guessed: they haven't finished before Monday, on Monday or after Monday. Many features were incomplete, new bugs were appearing, and old bugs were being reopened.
The team leader was saying they have other projects to work on, and they couldn't work with me full-time anymore. I was exhausted. They were tired. They worked weekends. I didn't have the finished project. Our arguments were more and more heated. Everyone was nervous. When people are nervous and work overtime, they make more mistakes. When they make more mistakes, it's more work to fix them.
They were defensive. I was angry. Every morning they told me it's the last day. Every evening they said: goodbye, we'll see you tomorrow.
Way after the deadline
Long story short. The project took almost three times longer to finish than originally estimated.
The budget was almost two times higher than originally estimated.
What a twist!
Sounds very familiar, doesn't it? Those developers, you think. Never on time. Never good quality. Never without handholding. Always have to check on them. Can't work by themselves.
Now, it's time for a confession. The project was to renovate an apartment, the team consisted of renovation workers, and the original time was three weeks.
The real time was 8 weeks and 5 days.
What does this all have to do with software developers?
You have probably heard phrases like: "software developers are never on time", "don't trust a developer to estimate a task", and many more. Developers are being sneered at for not complying with time estimates, including the ones they made themselves.
But my theory is - everyone messes up with their time estimates. This renovation project is a very good example. And there're many more. Projects go overtime and over budget all the time.
My point is - it's not software developers - it's humanity.
In the next article I'll give more examples of delayed projects in different spheres. I will also list the reasons why the projects get delayed.
This article was originally published in my blog smartpuffin.com.
Top comments (11)
Interesting read. It's easy to fall under the impression that the problems we face as software developers are only encountered by developers if you don't have experience outside the industry. Because I get most of my informations from programming sources, it's always the same stories about bad software, wrong estimates, poor management. Sometimes, I ended up thinking: What is wrong with us? Can't we just be reasonable, responsible professionals like anybody else?
Well, apparently, we are very much like everybody else. Still trying to figure out what the hell we are doing, and how to do it.
Yes, we're just like everybody else! And also I think that when we developers view ourselves as unique professionals in a first-of-a-kind industry, we can't relate to other industries and learn on their example.
Isn't this pretty common in the contracting sphere? If you hired a company that always deliver on time. Then it would be on time. But would cost big $$$. Now the article I would love to read is how to fix this, maybe part 2? Great article tho. Brave to highlight obvious defects in society like this, that no one talks about.
Well, technically, I hired a company, but they were still late, but cost a lot. Sigh.
Part 2 is definitely coming! Can't promise the solution, but will definitely list reasons why this is happening.
This isn't just down to humanity. Those contractors were just terrible at estimating.
There's a large difference between software and such rennovations. The reason software is so difficult to estimate is because it's a unique project virtually every time. We're never faced with the same circumstances, same requirements, same anything.
This is not true in other domains. In home renovations you aren't facing an infinite number of requirements or eventualities. There are a lot more standards, and a lot more common things. Sure, there will be differences but it's simply not in the same degree as with software.
There are similar domains in software. Consider a standard corporate identity website. These have no new challenges and can be estimated very well.
If somebody provides an estimate then they should be able to meet it. Failing to do so is simply bad service. If an estimate is not possible, as there is too much unique work to be done, then a contractor (in any field) should be upfront about that and give possibilities and options. In software the smartest approach here is to have release deadlines without a fixed feature set.
All this aligns with my experience as well. Uniqueness and changing requirements definitely play a big role. But I think that's not all the reasons. I'll write a second article soon with more comprehensive analysis about the reasons.
Project management is hard. I wish more software engineers were required to learn more about it. People assume if you have a dedicated project manager that everything will be okay, but it requires at least one dedicated project manager and that all of the engineers working on it to know how project management works.
I highly recommend this book about how to measure anything: amazon.com/How-Measure-Anything-In...
Reading up on project management models like the Kano model is also useful: foldingburritos.com/kano-model/
I've seen OKRs used effectively in many places as well: amazon.com/Objectives-Key-Results-...
My thesis advisor told me that everything takes pi times more time than you think it will. That's not far off from 3.
Absolutely! It sounds pretty fun and maybe a bit ridiculous, but it works.
I taught several product owners to multiply all developers' estimations by Pi, and they told me it helped them a lot.
...now, I'm starting to wonder if their managers multiplied the product owners' estimates by Pi again.
Interesting article with a nice twist! :)
I love this!