This article was first written for Zigi's blog on the subject of developers happiness/noise/career/productivity https://www.zigi.ai/blog/why-developers-dont-like-etas
You can be the most skilled and experienced developer on the planet but even this title won't help you when you find yourself in a situation that requires you to meet a specific deadline. Such a challenge is the bane of every developer. It is the question that you try to avoid when it comes up in a conversation. Almost akin to a bad word or a name best avoided like the one that begins with a "V" in the Harry Potter series. What becomes quite apparent when you have worked on a couple of projects is that life just does not go as smoothly as you expect it to be. Uncertainties can occur when you least expect it and no plan is foolproof.
Distractions can and do occur in the field of work as do the odd random things that just seem to pop out of nowhere and make you wonder what exactly is happening and what kind of day you are going to have. The reason why it's so complicated to give a concrete ETA for a product that you are working on is because you just don't know how long it's really going to take and you most definitely can't look back on a previous project and use that as your baseline. No project is ever the same and life is wild and wonderful at its best.
What becomes quite apparent when you have worked on a couple of projects is that life just does not go as smoothly as you expect it to be. Uncertainties can occur when you least expect it and no plan is foolproof.
Unrealistic expectations
It's all good and well having an idea in your head of how you believe a project will go but unfortunately in the real world, we are forced to deal with different variables which do not align with our perfect world. Recently I was working on a project for the company that I work for which at the time seemed like it was going to be super smooth with few if any blockers to get in the way. I could not have been more wrong!
You see you need to factor in the unexpected like in my case I lost a few days of work because of some unexpected admin work that needed to be completed which was bad timing. And there were some problems with the codebase which required lots of investigation. This is something that I never imagined would happen because I had this picture in my head with everything planned out nicely and the deadline was so far away that I did not stop to think about unforeseen challenges that might come my way.
It is also a given that other people on the project are likely to have their own ideas and expectations too. So while they might assume that it will be easy to build an element for an application the reality is that maybe it takes a bit longer and requires some research so you might not actually be working on it the whole time there is a whole different side that needs to be deconstructed too.
Too many client requests
A huge talking point is how developers should deal with client requests. Giving an accurate ETA requires a significant amount of thinking and planning. It is not ok to just say the first thing that comes to mind because work environments tend to have many changing variables, nothing is fixed. In some situations, you might find yourself working on multiple projects that cross over, so that is another thing that must be considered in your thought process. Furthermore, working for large organizations tends to give you far more opportunities for projects.
Having both an internal and external resume ensures that your profile is readily available for when a project that matches your skillset is secured for the business. More opportunities lead to more events and alternating between various contexts. Taking all of this into account it does not take long for a developer’s calendar to become full of meetings and calls which have to be factored in as one of those variables and time constraints.
Another less often realized subject is the fact that having meetings and events is part of the job. They can show up unexpectedly and this can cost you valuable coding time. Nobody likes to break their working streak because this distraction can take you an average of 23 minutes and 15 seconds before you get back into the flow of things. Throughout a project, priorities can change all the time so it can start to become quite complicated to give accurate estimates as you can’t say for certain how many hours you will have free for coding in a day.
Deadlines
It is not outside the realm of possibility that you have already agreed to a deadline for when the project should be in the minimal viable product (MVP) phase. But you see the thing is that changes can happen despite you believing that it has already been set in stone and you know what you should be doing.
In another example, I can recall various other issues related to the deadline on the same project which I mentioned earlier. Concerns were raised when additional feature requests, design changes, and new copy flows were introduced. The app was barely close to production-ready and my workload had tripled in a short amount of time while the deadline remained the same... Truly it can be described as insanity giving you more work to do than days available to do them.
Where did that bug come from?
A global pandemic
External factors can be absolutely detrimental to a project. Let's talk about the elephant in the room "coronavirus". In 2020 a long overdue and highly anticipated computer game was released to the world. The game had been delayed for months which was already a huge red flag. The developers continued to give excuses for the delays while convincing everyone that it was going to be ok. Well, the game finally launched and it was a disaster. The game had so many bugs it was almost completely unplayable on games consoles.
We are only human and we cannot predict the future. I bet when they were working on this game they could never have anticipated a global pandemic which changed the shift of work from offices to remote working. It came at a bad time because it disrupted their whole project cycle leading to delays as the team could not work efficiently on the codebase at the time.
Unforseen delays
I can think of dozens of examples when I was working on a project at a company which unfortunately got delayed because of some unforeseen bugs that just came out of nowhere. In my mind, I knew the code that I wanted to write. I had done it many times before. But then some random bug shows up and instead of you completing a feature that you had planned to have done in about 1 hour. You have now lost half a day trying to debug something that is behaving unexpectedly and throwing you off your game.
As of writing another high profile computer game has been delayed because of the pandemic The development studios released a statement saying that the global pandemic had created unforeseen challenges for their development teams. And that they would need the extra time to complete it so that it would be at the level that the fanbase expects it to be at. I for one welcome the delay because I think the gaming community has learned from previous failed launches because there is always a large backlash.
A better solution
ETA's are just difficult to contemplate; there is no "one-fix" that will immediately give you a solution to this dreaded problem. Although that may be the case, all hope is not lost if expectations can be tamed and adjusted right from the beginning so that everyone is on the same page. And it does no harm at all explaining the problems that can arise and letting the client know that developers are not wizards like Merlin from King Arthur and Gandalf from The Lord Of The Rings series. We don't write spells, we write code, and sometimes it breaks.
While it may not be possible to alleviate all doubts if you have good planning, project management, team meetings, and a well-defined architecture setup from the start. It will go a long way to giving yourself and the client confidence that you can get something working eventually.
Top comments (1)
It comes all down to the triangle of doom: good, fast, cheap: can't have all three. Want a set of features in a given time? The only thing that can be bent into submission to allow this is quality. Devs become sick when forced to deliver inferior quality.
But it's only a prototype, management will say. Fine, says the developer, but if we don't throw away the code and start from scratch afterwards, it'll cost us even more time. Sure, sure, says management, only to break the promise after the success of the prototype. The developer's prediction soon comes to pass, but now, the developer is fed up and looks for a new job.
I've been that developer. I know that 99% of deadlines only exists because management has bonus goals that are fulfilled if feature X is out by date Y, so my friendly advice is: choose meaningful goals that actually advance your company over those damaging it. For example, reduce customer and developer churn by 5% until end of year.