Are missed deadlines common in programming jobs? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

Closed 7 years ago.

Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.

It was my freelancer job at oDesk. I have done several jobs earlier in given time, but is was the first time I missed the deadline. It was a very lengthy job and I tried my best but I still missed the deadline. Now, I am very scared. Because it's my fault that I missed the deadline.

My question is: Is this is a big concern or are missed deadlines common among programming jobs, so I shouldn't worry too much about this?

Answer 1

Yes. Missed deadlines are common in software development.

Many freelancers meet deadlines by incurring in technical debt or hiding the dirt under the rug.

Paraphrasing Frederick Brooks' The Mythical Man Month:

• Deadlines are often missed because project leaders continue to estimate software tasks the same way they do civil engineering tasks, which is a flawed approach because software is a novel, handicraft industry with no clear body of norms. This is so true that you cannot revoke a programmer's "permit" to code for malpractice, nor you can sue someone for programming without a title.

• Software development has inherent complexity that other disciplines lack. A big program can have more components than a car, and these components can interact in more, different ways.

• Software is hard to visualize, so different kinds of diagrams are used to see different aspects of a project, and these aspects may not be orthogonal. Civil engineering, on the other hand, has blueprints allowing you to see plumbing, wiring etc. all in the same chart (or layers) in an orthogonal way.

• It's not common, after a bridge or building is half built, for the client to completely change the scope of the project. This is often the case in software projects.

• The state of the art in software development hasn't reached the point where software projects are repeatable and almost risk free. Even the largest software companies like Microsoft can miss deadlines by months or years.

• Most vaporware is nothing but software projects that were cut because of these kinds of problems.

In conclusion:

Bad estimates and underestimation of complexity, due to the handicraft nature of the software development process, mean it remains an immature discipline.

Answer 2

Missed deadlines should not become common practice if you want to continue to get jobs.

With that said, you typically want to leave yourself some extra "wiggle" room in your estimates in case stuff happens (and it always does). You don't need to disclose that you've added in extra time, just don't make it unreasonable. Maybe between 5 - 10% of total time? The only way you'll find out is to do it a few times.

In order to get really good at estimates, you have to know how long it takes to code a certain type of widget... for example, let's say you have to create an infinite scroll widget for client X. If it takes you one week to deploy it into production without bugs, you can use that as a baseline for your infinite scroll estimates.

Answer 3

Missing deadlines isn't uncommon in software development. It is almost impossible to accurately estimate how long a software project will take.

Professionalism is shown in how you deal with it. When you know you will miss a deadline, inform your client as early as possible about it so they can plan accordingly.

Answer 4

It's fairly common, but you can get better at it. You might want to look into estimating using something abstract like story points, and keep track of your velocity to calculate your actual estimates. Those concepts are most commonly associated with scrum, but can be used even if you don't do scrum.

The amazing thing about velocity is it encompasses all the intangible things like interruptions and unexpected complexity that developers have a difficult time accounting for in their estimates. All the probabilities average out over time. Averaged over 10 weeks, our velocity estimates have been accurate within about 5%. Yet when we estimate the same tasks in hours, the exact same team consistently underestimates by 30-50%.

Answer 5

My theory (unproven) is that humans have evolved to underestimate complicated jobs by two or three to one. Any time Congress asks NASA something like: what will it cost to build a shuttle or travel to the moon they come back within a week with a number. After they run out all the expected costs they discover it will cost three times as much.

We had a joke in the 1970s: take any programmer estimate, double the number, then move it to the next unit of time. Therefore, if a programmer says it can be done in two weeks, he will finish it in four months.

If anyone has remodeled a kitchen they generally think 'Well I'll have this done in two weeks'. They finish it about six weeks later.