I’m going to touch a sensitive matter, estimating development times of a feature.
I’m not going to discuss how to estimate, there’s much to say about that and so more on that topic on a future post. What I do want to talk to you about today is what to estimate.
That’s sounds like a silly question, right? We estimate the development time of the future.
Well, the answer,somewhat surprisingly, is no. We do not estimate just the development stage, we estimate everything we need to get done.
What’s the difference you may ask, and I reply with a question: What are you estimating ? When are you done?
What does done really mean
If you were like me, you may not have realized how much additional work there is, I won’t list everything, but to get the idea:
- The code have unit tests written with a high code coverage
- The code passed QA, integration tests, acceptance tests etc’
- Code past CR and was refactored accordingly
- Code and feature are documented, in code and externally
- Feature was deployed! (wait what?)
I’ll first address the last point, code is actually deployed,why is this here? Code does not help anyone when it’s in source control, it only worth something when it’s deployed. If deployment would take you a day of work (preparing the version, editing configuration etc’) then this day of work must be estimated as well, otherwise you’ll end up saying “yes, it done! That is.. I need another day, but I’m finished”. If you need another day – you are NOT done.
The previous matters are important too!
You may be unconvinced that refactoring and documentation are important. You might also think that unit testing and integration tests are a waste of time. You’re here to write working code!
I say this – in 2017, working code just doesn’t cut it anymore. Code changes, we add new features and modify existing behavior. Thus, code must be readable (to others too) and easily modifiable (e.g have the safety net provided by tests)
Why estimating everything is important
Imagine the following conversation between Joe the developer and Bob the manager:
Bob: we need to do X, how long would it take you?
Joe: about three days, another two days for writing unit and another day for an integration test
Bob : Do we really need unit test
Joe: [start talking about testing…]
What’s wrong with this conversation? Who knows best how to write reliable code? Who have the professionalism and responsibility for writing tested working and reliable code?
You were hired based on your knowledge and expertise, you are expected to take the calls and how to do your job. You do not need to ask permission to to a good job, its expected of you.
The responsibly is your! Only you know what to do and how to do it.
The conclusion to be drawn is that it is you, the developer, should decide what you include in your estimation, you should do this based on your definition of done, don’t let yourself be micro managed by given estimation for each of the things you do, but make one estimation that includes everything