18
votes

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?

6
  • 1
    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, 2013 at 5:39
  • possible duplicate of What is the most effective way of communicating potential delays in software development?
    – gnat
    Jul 30, 2013 at 5:46
  • 3
    missed deadlines are common in all jobs
    – Steven A. Lowe
    Jul 30, 2013 at 18:40
  • 2
    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, 2013 at 19:52
  • 6
    Do it fast, do it cheap, do it well: pick two.
    – Reactgular
    Jul 30, 2013 at 20:47

5 Answers 5

Reset to default
44
votes

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.

10
  • 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, 2013 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.
    – Maciej Piechotka
    Jul 30, 2013 at 12:38
  • 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.
    – Maciej Piechotka
    Jul 30, 2013 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).
    – Maciej Piechotka
    Jul 30, 2013 at 15:04
  • 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 5, 2013 at 21:44
3
votes

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.

5
  • 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, 2013 at 7:30
  • I am a solo developer and i usually take 10% margin for my projects.
    – Konsole
    Jul 30, 2013 at 10:14
  • Hmmm... see Hofstadter's_law
    – Philip
    Jul 30, 2013 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 1, 2014 at 3: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 2, 2017 at 18:26
3
votes

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.

2
votes

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

1
vote

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.

3
  • 1
    What does NASA has to do with my question?
    – user88873
    Jul 31, 2013 at 7: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, 2013 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 1, 2013 at 13:05