About Software Estimates
Published on
There sure is a lot of talk and work about estimates in software development. Whether you are in a big company, a small agency or a “one-man army” project, the idea that you can predict how long will it take to build a system is widespread and adopted by all.
Any management principle or project schedule has it as a bare minimum to operate. This is useful so you can plan in advance, and tackle the projects in a sane order, avoiding obvious trap holes and business errors.
Edit 17/05/2025: I’ve built a Spring Boot Starter using JPA to enable a simple leader election process. Click here to check it Edit 17/10/2024: if you want a real lock mechanism for jobs, your best bet is probably Shedlock
Warning: technical post ahead. You may want to take the children out of the room!
Spring-boot took the market by storm in the last years. Spring, as is, with MVC dependency had already bitten a huge chunk of job posts and online questions, but with the Boot simplicity, it practically set the new standart for frameworks in Java language.
So, there’s this thing about your system.
It’s born to die.
I’m talking more specifically about the Web Systems, because that’s my area of expertise, but it’s valid for several areas of software development. Systems are created to be destructed in the long run. And that’s okay.
I’ll explain myself.
If you already worked in some big project, or for some years in a company, you already saw what people call Legacy Code.
In recent past, Orkut was the main social network in my area. Everybody used it, and everybody loved it. I believe it was the first “real” social network that was massively popular here and there were no signs that it would be replaced by Facebook.
When launched, the first iPhone revolutionized the industry of smartphones. It was something new and everybody loved it and bought one. Today Android has a bigger market share (talking about number of devices).
When I started my career I quite never understood the idea of settling down with some language/technology. It always sounded wrong to do it because you have to “use the right tool for the right job” and “if it doesn’t look like a nail, don’t use a hammer”, but today I think that, as always, the reality is a bit more complex.
I still think that, as a developer, I am more capable and productive learning more and more languages/platforms/tools/frameworks/etc.