The rule of credibility in project delivery

The first 90 percent of the code accounts for the first 10 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

So someone can quickly mock-up 90% of the project in just 10% of the time. Don’t mistake the time spent on total work done to be directly propositional to the time to be spent on the total work remaining.

Many times I get the call “Can you please complete this project, its ‘just’ remaining, ‘just’ a few finishing touches, ‘just’ here and there”.

A client once told me, “All the front-end has been done within a week, you just need to attach a back-end. That should take you just one week I guess”.

It’s tough to explain that the back-end is actually the main work and will take way more time, the front end is basically a well thought out guide.

Truth be told, the amount of work remaining to get those ‘finishing touches’ complete is the reason the project wasn’t completed in the first place.

[ follow me on medium.com/@daveozoalor ]

Everyone falls for this temptation at one point or the other.

During agile software development projects, a project may be marked-off as “relatively done”, usually, there is one more tough task that will drag on the deadline for a much longer time than expected. So “relatively done” projects can be miss leading.

Outside development, a software project can be completed in 2–4 months but the project cannot kick off because there is this one document that the government needs to stamp on. Funny, that stamp can take another 2 years before it touches that paper.

When estimating the total time a project will take, there is a devil in the estimation process that tricks the estimator into giving a uniform timeline for all tasks. This makes the estimator grossly under-estimate the time the hard parts of the project will take. Some tough tasks in a project are just sink holes waiting to gulp 900% of the time already spent on all the other parts put together.

[follow me on medium.com/@daveozoalor]

This concept of task and time is usually hard for people without coding backgrounds to understand, especially when they are the project managers or managing the project manager.

“Is it not just to add a payment gateway that automatically pays lenders, why can’t you guys just add it for the past 2 weeks? I want it added within the next 10 mins!”

In some fields of study, many tasks take uniform time, picture someone filling up excel sheets. Its easy to estimate how long the rest of the project will take by estimating how long the first task took to complete. But not in programming and some other related fields, every new task presents completely new challenges. Who knows, the library that is to be used may have been broken in the release candidate and there is no mention of it in the docs.

So the developers have to investigate their whole family tree and village people to find out why something is not working as stated clearly in the docs.

The 90/10 rules is called the rule of credibility in computer science and was first observed in the early 1980s by Tom Cargill. The thing questions your credibility :D

In summary, tasks should be treated with the respect they each deserve and the time they might take. Potential time sink holes should be spotted and put into consideration during project planning to avoid the unsettling embarrassment of having projects drag out far beyond the initially estimated deadlines.

follow me on medium.com/@daveozoalor