We are at the half-way point in this series and I thought I’d try to fit in this post while I wait for my 9GB of Halo 5 updates to be downloaded to my XBOX.
Experience and Understanding the Problem are two of the four pieces to being good at estimating what you are trying to do. The third? Knowledge.
You might say – “Well isn’t experience knowledge?” – no it’s not, experience is the act of gaining knowledge through doing estimation. But knowledge can be garnered without experience, i.e., I can pick up a book and read all about Ruby on Rails or I can go to a blog and learn about PHP or attend a seminar and learn about .NET. I haven’t used them in any real context but I have learned about them academically.
I know them, I know how it works.
Experience drives your knowledge over time, you get a project that has to use WCF? You learn about WCF, probably more than you need for the project, and that is yours forever.
Beyond the technical where most of our experience might be focussed, is domain knowledge. I can sit down and have someone explain a problem to be and I can genuinely understand the problem but have no surrounding domain knowledge or business context about what is trying to be done. Domain knowledge is knowing the context around what you are trying to solve – “Oh you are trying to get this client to talk to that back-end, yeah the problem is that this legacy app that has no interface to it” or better yet – “You can’t talk to that application, not because you don’t know how to figure it out, but because it would violate our business compliance rules”.
Whereas experience opens the door for what you can do and understanding the problem shows you the path – knowledge, specifically domain knowledge, gives you the frame for you how you get there. This is where you’ll start to hear the conversations around the whiteboard that go like – “I’m pretty sure that is not supported” or “We’ll have to talk to accounting before going forward” comes in.
Knowledge is, at many times, an additive component to your estimates as you trigger on work that will have to be done and built into your estimates to ensure they are completed, people you will have to talk to, etc. The only time knowledge serves to reduce your estimates, is when you raise the issue and scrap the task completely out of some logic for which you already have.
We’re 3/4 of the way there and the last component might just surprise (or might not, that is completely possibly).
Want more? Check out my book Code Your Way Up – available as an eBook or Paperback on Amazon (CAN and US). I’m also the co-host of the Remotely Prepared podcast.