I don’t know about you, but I am terrible at software estimates.
I’m even worse if I haven’t done that thing before, whatever that *thing* is.
As a recent example, a client (for the near term I still accept project work in .NET and Angular on the side, while growing this business) needed me to implement an editor for their workflow (editor here means a WYSIWYM editor like a markdown editor).
Complicating matters is that Angular is very particular about how you can interface with third party libraries; so you end up needing to use or create a wrapper.
Complicating matters further, if you use a design system like the Material CDK, you also want to wrap that wrapper in something that implements the Material design constraints.
All this for a content editor!
If I didn’t know this, it would have thrown off my estimate a lot. And logically, it’s not something that should ever happen. It’s illogical to require these hoops to implement a text editor in angular, and if you’re not intimately familiar with the issues at play, (as a business person probably would not be), it’s easy to wonder why it should take more than a day to implement a text editor in Angular. Or, as this XKCD brilliantly illustrates:
So what to do?
If your system hasn’t been created through TDD, you’ll get some measure of success in estimating by making the change and seeing what tests break. In the case where you have good test coverage, you lower the amount of parts you have to guess will change, and guessing is what makes estimation so hard.
In a system created through TDD, it’s even easier as your tests will not be coupled to the specific things you’re tied to (like a text editor), rather they’ll be tied to the operations your system makes on that text editor; allowing you to swap out editors and *knowing* for certain if it affects the operation of your system.
I offer team based immersion training for TDD; both online and in person, where you’ll learn just how to do this. To get started, visit https://doubleyourproductivity.io/paid.html.