Have I Actually Tried That Yet?

Almost every software project involves something new. This may be at a pure programming language level. But mostly I am thinking of APIs and libraries and frameworks and servers and applications. You've invested in a SOA offering like Oracle OSB, or an ECM system like IBM FileNet P8, or a web app framework like JSF, or an app framework like Spring, or some security implementation like Apache Shiro, or an app server like Glassfish, or bet the farm on writing your desktop apps with C# 4.x, or gone with NoSQL instead of SQL Server.

You made all those choices because you've done some research, you played with all of them on your own time, or you know people who use them.

But now you actually have to do X and Y and Z in a certain API furnished by a certain library that you chose, or configure security with that security implementation you picked along with that app server they picked, or customize certain features in the ECM system that everyone committed to (way too early), or build a certain integration with the ESB you picked out of a hat.

And you find out that Spring LDAP in conjunction with Apache CXF doesn't work as neatly as you thought for authorization. You find out that a lot of custom work is needed to implement those ECM features (not what the vendor docs suggested, is it?). You find out that everything is taking much longer with Oracle OSB than you thought: you are getting it, but your junior co-workers are struggling to make those few critical things work. You invest weeks in writing up most of your C# desktop app just to find out that it's going to be bloody difficult to code up a certain feature. You block on a certain set of methods in a library that turn out to be buggy - Defect #14156 in Jira.

Common theme: you assumed that things would work, or that they would be relatively easy to understand from documentation, or that since the library or application clearly supported feature X that there was no way it would not also do feature Y.

Bad mistake.

You usually commit to major software quite early in a project. Once committed it is very difficult to justify backing out of a choice. And quite frankly, you can almost always make something work eventually. The problem arises in not accounting for the unknowns.

Rule of thumb: if you have to do something with a library or framework or server or application, and you have never tried it before, estimate the initial potential effort at one-half work-week - 20 hours. This does not mean the finished implementation: this means the Proof of Technology (PoT).

This may seem extravagant. This translates roughly into 10 untried capabilities per person-month. I do not mean major capabilities either: it is not going to take you just 20 hours to figure out how to implement SAML for the first time. No, this twenty hours per is for unit tasks at a fine granularity...like already knowing Spring LDAP, and already being conversant with Apache CXF, and even knowing how to combine the two to implement LDAP authentication for a web service, but not knowing yet how to do authorization. If you have never implemented authorization with that combination, estimate the initial PoT at 20 hours.

Any given new fine-grained PoT task may take more than 20 hours - it might burn a week. That's balanced out by those that take 4 hours.

Any experienced developer has spent a week or two - a solid week or two - on one little thing that was supposed to work. But it had never been tried before. Who knew? Come to Google time, evidently nobody else had ever made it work either. Or even better, you find a project committer explaining shamefacedly in an obscure thread that yes, while the feature is documented, it doesn't work correctly...yet.

How to explain this extra time to the manager or to the customer? Well, here's the thing. Ideally this estimated PoT time is not more than 25% of your total implementation effort. If it is, then the entire nature of your project is different. You've now got an experiment. There is nothing wrong with this, but you need to communicate that information to your manager or customer as soon as possible.

How to estimate? How to locate these PoT points? This should not be that tough. Once you've got your detailed design, and you know what software you're using, work through the combinations and list off each fine-grained task. Make it as fine-grained as you can. Ask yourself the question: have I, or any team members, done exactly this before? If no, it's a PoT.

I hope this helps.