I am working as software developer and struggling with this problem time and time again for almost thirteen years. There seems not to be any way out of the following problem.

And it happens with small projects as well.

For example, I plan to write an extension for Microsoft Visual Studio. I dowload learning materials, get some book on the topic and allocate time for learning and development.

However, during the development, many seemingly trivial problems arise, for example:

  • Why the script refuses to delete the file?
  • Why Visual Studio does not register the extension?
  • (after two days) OK, it registers it, but now it got broken. How to fix it?

each of these "small" obstacles usually take 1-5 days to resolve and the project finally consumes several times more man-hours than planned.

Maybe it happens only because I am working on Microsoft platform and many of their Frameworks and architectures are bit confusing and badly documented.

I would like to have most problems resolved by finding answer in a book or official documentation (MSDN), but the only answer I usually find is on some weird forum or personal blog googled after desperately searching for any relevant information on the topic.

Do you have the same struggles? Do you have techniques on how to prevent these problems?

I was thinking of simply multiplying projected time for a given project by some factor, but this does not help. Some projects get done briskly and some take months and the guiding factor here are these small "glitches" which take programmers whole weeks to resolve.

I have to admit that lots of these obstacles demoralizes me and drains me of focus and joy of work (who likes to get back to work when he have to resolve some stupid registry problem or weird framework bug instead of doing creative work?)

After the project is finally done, I am feeling like dying from thousand cuts.

closed as not constructive by user8, TMN, Walter, gnat, ChrisF Oct 20 '12 at 10:36

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Is your question about the general nature of the software development process, or is it the more specific one of "How do I get Visual Studio to remember my extension?" Anecdotally, much of the material I've read about programming Visual Studio extensions suggest that it is an enormous pain in the ass. – Robert Harvey Oct 18 '12 at 19:42
  • 1
    @RobertHarvey It supposed to be a general question. And yes, this particular area - Visual Studio extensions - is a real pain. – Libor Oct 18 '12 at 19:59
  • I submit that the problems in this particular area of software development don't necessarily extend to the rest of the field. – Robert Harvey Oct 18 '12 at 20:01
  • I'm pretty sure this is why we're considered professionals. We can succeed despite the unexpected. – M. Dudley Oct 18 '12 at 20:06
  • @emddudley: With failure rates being what they (supposedly) are, project slippages in every field, by every company, I don't think you could be farther from the truth. The only difference these days is that companies just keep cutting features to make ship deadlines. – Steven Evers Oct 18 '12 at 20:10

Imagine you're doing creative work: creating a new Boeing, larger, more powerful, etc.

  • One day, you're waiting for truck which should deliver bolts for a part of the aircraft, but it appears that there was a human mistake, so instead of arriving in your city, the truck is stuck in the middle of nowhere and will be late.

  • Another day, some very important and very experienced worker is hit by a bus. To continue the work, you need to quickly find another such experienced person.

  • You also discover that the wiring shipped from different countries is incompatible. You should rewire a large part of the aircraft and expect important delays.

  • When the aircraft is finished, it appears that the tail is rubbing the runway during the takeoff while it shouldn't. You need to handle this situation and explain to your customers why you're three months late because of this.

The randomness you have with IT projects exist everywhere. This is risk, and you can't avoid it. You can still reduce it:

  1. By reusing code written by skilled developers only. If you take a piece of code which is written by some unknown, underpaid programmer, you can't be sure that it will be painless to use it. It may work, it may fail.

  2. By choosing the technologies you already know. If you start a web application and never used Ruby but have ten years experience in Python, don't pick Ruby if you need to avoid bad surprises. There is nothing wrong in trying something new for the first time, but don't do it on a business critical project with tight deadlines.

  3. By asking help. Stack Overflow is for people who are stuck in front of a problem some other developers may have experienced before.

  • Thanks. The cases you mentioned are always somehow solvable. The software got so complex today, that I am really afraid that there may be glitches and problems that may not only slow down development terribly, but completely deny us from delivering high-quality product. Even if it would work well on our machines, some percentage of users may struggle to even run our application or extension. The slow-downs may also be killers if you have limited time and resources. – Libor Oct 18 '12 at 20:09
  • Some of the problems you are describing are major planning fails which are avoidable, even in software development. – Robert Harvey Oct 18 '12 at 20:14
  • @RobertHarvey: I agree. But despite being avoidable, they still exist and quite frequent even for projects with huge funding, made by large companies. – Arseni Mourzenko Oct 18 '12 at 20:27

... consumes several times more man-hours than planned.

Sounds like you're planning things where you or your team don't have sufficient experience or knowledge to understand the potential pain points. This is common, and the best way I've seen for solving or managing this is a Proof of Concept (POC).

That is, in a POC you are given a well defined amount of time - say 2-3 weeks - and you are tasked with seeing what can be done to solve a particular problem or use a particular technology. The result isn't necessarily the work that you did, but a report on what it's like using the technology, the pain points, the efficiencies gained, and now your estimate of how long it would take to develop the solution.

This estimate still has a strong likelihood of being wrong... but much less wrong than it would have been otherwise.


This is a problem with predicting development times. I think I've read somewhere a fancy term for this situation, but I can't remember it now.

The bottom line is, when predicting how much time will it take for a certain project, if you haven't done a similar project before, be sure that you can't have a reliable prediction. If you are going to work on a new platform/work with a new framework for the first time, there will always some relatively minor problems that will set you back for hours/days/weeks.

That's why, at least around where I live, people working in software industry never gives certain estimates, and tend to exaggerate a lot.

  • Hey I know about this :) I did many similar projects before and it repeats time and time again. The problem is that the area is something like a desert filled with pools of quicksand. You never know where you get stuck. For example, I have 12-year old experience with .NET Framework and still getting surprised with parts of it. – Libor Oct 18 '12 at 20:49
  • The desert analogy really fits well. It can't really be avoided, unless you are following your own/somebody's footsteps. – Hakan Deryal Oct 18 '12 at 21:05

Not the answer you're looking for? Browse other questions tagged or ask your own question.