Are missed deadlines common in programming jobs?

Question

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?

Completely depends on the environment. For example, my last job was at a digital agency that charged clients based on estimates. If you missed the deadline there the business lost money. My current job is so dynamic that there are no real deadlines at all.. if my attention is required elsewhere I am given appropriate time to dedicate to it. Perhaps including this in your question will help with answers. — Simon Whitehead, Jul 30 '13 at 05:39
possible duplicate of What is the most effective way of communicating potential delays in software development? — gnat, Jul 30 '13 at 05:46
I really hope you were communicating with the client about the missed deadline. Missing deadlines happens, but it shouldn't be unexpected when it does - you should be able to see it coming and communicate about it. It usually makes it easier than just going "Nope, not ready yet." — Bobson, Jul 30 '13 at 19:52
Why are estimations off by a factor of 2-3? http://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3 — WernerCD, Jul 31 '13 at 01:18

Tulains Córdova · Accepted Answer · 2014-08-07T15:20:17.993

44

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:

Frederick Brooks, author of 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.

edited Aug 07 '14 at 15:20

answered Jul 30 '13 at 12:03

Tulains Córdova

39,449

11
Good answer, but having had some exposure to mechanical and civil engineering, it's amusing how programmers make facile comparisons to building bridges and other things, when they haven't the faintest idea how those are built.

Mike Dunlavey

Jul 30 '13 at 12:18

3

I would subscribe to the idea that the software is plan (in terms of plan in engineering - describing every detail of project). In case of engineering the time of physical construction dominates so large variance in planning doesn't play a role. However as software consist of only plan... "The state of the art in software development hasn't reached the point when software projects are repeatable and almost risk free" - in those cases why do the project at all? If something is repetitive and can be automated then it does not need to be done at all multiple times but can be done once and copied. – Maja Piechotka Jul 30 '13 at 12:38

@MaciejPiechotka By repetitive I didn't mean identical, just as no bridge is identical to another, but since bridges have been built for thousands of years some solid base exist. I don't agree with you in that software is only plan. You have to code, test, integrate, etc. – Tulains Córdova Jul 30 '13 at 12:47

2

@user61852: You misunderstood me. The 'plan' to engineering is as 'source' to computer science - i.e. detailed description of every component - but once we have it we can build it (enter make or whatever).What is 'plan' in computer science would be a 'plan of plan' in engeneering. The difference is that make in computer science takes at most few hours while writing source code (including tests and integration) takes months while in engineering the planning can takes months (including structural calculation) while building takes years.So the variance of planning have lower impact on latter. – Maja Piechotka Jul 30 '13 at 13:04

1

@user61852: Regarding the repetitiveness - one thing computers are great at is automation. Say you need to build a simple blog - at the point when you would have accurate 'estimates' you will get a wordpress (or any other blogging system) in place so you don't need to do any of it (in case of bridge you still have different environment so you need to adapt more carefully as the rock might be different or there might be a bird habitat or it might destroy the view) - the programmers might be more responsible for creating the tools (the standard bridge model). – Maja Piechotka Jul 30 '13 at 15:04

1

For example in game industry the programmers don't do the tasks considered standard 10 years ago (say - models, materials) but create a tools for artists to do those tasks. So once we reach a 'solid base' programmers are not needed any more (or at least not in a sense we are using them today). – Maja Piechotka Jul 30 '13 at 15:07

1

related question: Does software reuse preclude process repeatability – gnat Jul 30 '13 at 16:51

If your bullet points are direct quotes from the book, formatting them as block-quotes would be better. If not, it might be more clear to replace "According to" with "To paraphrase", and I can help with some grammar mistakes in the bullet point text. – Mike Partridge Jul 30 '13 at 19:33

1

@MikePartridge They are not direct quotes. I will add the "paraphrase" thing. – Tulains Córdova Jul 30 '13 at 19:56

2

Bonus for quoting the Mythical Man Month; Frederick Brooks holds up after all these years because he focuses on people not technology. – Michael Shopsin Aug 05 '13 at 21:44

score 3 · Answer 2 · answered Jul 30 '13 at 06:03

3

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.

answered Jul 30 '13 at 06:03

TJ Trapp

31

2

I always give 20% room when doing estimate. 5-10% is too little. I guess it depends how much distracted you are. Solo developer may not be distracted at all – BЈовић Jul 30 '13 at 07:30
I am a solo developer and i usually take 10% margin for my projects. – Konsole Jul 30 '13 at 10:14
Hmmm... see Hofstadter's_law – Philip Jul 30 '13 at 19:52
1

Compared to 5-20%, I think a 100% margin is better. Seriously. It allows you to explore your options much better. And answer more questions on Stack Exchange. – Asclepius Feb 01 '14 at 03:15
Oh yeah, it's the developer's fault when a 15-year veteran project manager pressures a 1.5-year-in rookie software engineer to give him an estimate then adjusts it be be even more aggressive and acts like the developer is slacking when the project is boned. I have never worked for a manager or PM who could write software at all, and you're telling me missed deadlines shouldn't become common practice if you want to keep getting jobs? Missed deadlines are endemic because most PMs are literally incompetent at their jobs. My best manager still wasn't a software engineer, just knew his limits. – downbeat Nov 02 '17 at 18:26

score 3 · Answer 3 · answered Jul 30 '13 at 12:12

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.

score 2 · Answer 4 · answered Jul 30 '13 at 16:28

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%.

Meredith Poor · Answer 5 · 2013-07-31T17:47:48.980

1

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.

edited Jul 31 '13 at 17:47

answered Jul 31 '13 at 07:11

Meredith Poor

568

1

What does NASA has to do with my question? – Jul 31 '13 at 07:51
1

More to the point, what does human evolution have to do with your question? NASA is a clearly documented example in the public record of trained and experienced people underestimating large projects. In short, your experience is 'natural'. – Meredith Poor Jul 31 '13 at 17:46
While I agree that most people's estimates are off by at least double, but the next unit of time...hmmmm. Anyways, NASA is very good at estimating tasks which they already know how to do. The problem is that people are not very good at estimating tasks when they don't know what they don't know. Being that NASA does a lot of truly pioneering work, it is no wonder that the don't know a lot about what they are doing until they start doing it. Thus, the reason for initial underestimation. Also, some people are predisposed to be optimistic and others pessimistic. Not sure evolution is involved. – Dunk Aug 01 '13 at 13:05

Are missed deadlines common in programming jobs?

5 Answers5

Linked

Related