Numerous Unexpected Obstacles Ruining any Project Plans [closed]

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.

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:

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.
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.
By asking help. Stack Overflow is for people who are stuck in front of a problem some other developers may have experienced before.

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

Filed under: softwareengineering - @ 23:46

Thẻ: planning, project-management, project-planning

Thiết kế website giá rẻ

Danh mục

Numerous Unexpected Obstacles Ruining any Project Plans [closed]