If your doing similar work over and over again as a programmer, your not doing a good job.
I've found that without straight up hopping jobs, it's almost impossible to do truly new things rather than settle into a role where you're too valuable to not exploit for the same old crap you've done before.
I'd still call that doing a good job - businesses need people that can pump out good but similar work. People that always need something new once they master the old thing can be liabilities, depending on the context.
They have issues with, let's integrate x product with our product.
Massive amount of very similar work being done. How much shared code?
They have probably spent a lot of time and money paying UX guys trying to optimise for their unique situation.
I would assume they reusing either in house or 3rd parry libraries in their code, but that stuff isn't where estimates go wrong.
It's usually experimentation of trying to get UI right for the user.
I mean could tell you how long it would take to make a html page, if you tell me what tags and elements you want in it.
It's a whole different ball game, if you ask for a estimate of creating a complete feature because it will probably involve a little trial and error and feeback from multiple people. The first few stabs at it won't be quite right etc
> If you're doing similar work over and over again as a civil engineer, you're not doing a good job.
Hmm. Not sure I feel comfortable with that.
> If you're doing similar work over and over again as a small business accountant, you're not doing a good job.
Actually, I'd rather prefer you to stick to the basics, please, no need for discussions of complex derivatives of treasury stock.
> If you're doing similar work over and over again as an orthopaedic surgeon, you're not doing a good job.
Thanks, but I think I'll get a second opinion.
I expect those engineers still gave estimates and were chosen because they had the most relevant experience and expertise.
I'm just saying they are probably way out, and probably arn't that useful compared to other methods of building software.
A lot businesses people who get this, then ask why bother if they are going to be really inaccurate?
Instead focus on small intervals, work out what you should try to build in those intervals. Implement. Gather feedback. Repeat.
Or even better do the implement and feedback cycle continuously.
If you are not happy on the progress of a feature, cancel it.
Because you doing things in small intervals, and then adjusting. It won't go wildly of the tracks, before realising you have to adjust or cancel it.
I absolutely agree with you. I think we're closing on the key difference, which is the scope of the estimation.
I am accustomed to estimating the smallest self-contained unit of user-facing value. I'm used to doing it weekly. I'm used to being in a room with my fellow engineers to do a simple points-based estimate of complexity, with projected dates derived from the velocity of the past 3 weeks. I am used to PMs who understand that sometimes we hit iceberg stories, but that most of the time, the projections are good into the next few months.
What I don't have to do is build a magical estimate of the next three years. If I was asked, I would try to based on historical data and research, but the bands would be extremely wide.
Thinking about the analogy that we often make back to construction, the problem is that classical project management is essentially an estimate of an integral. There is a discrete endpoint, and we can estimate (and re-estimate) leading up to that end point. Funds are committed in large chunks and the cheque-signers need high confidence to proceed.
But software is never finished, only abandoned. Estimation has to be differential and constantly updated. If the software is developed to be releasable at all times, commitment can be incremental and early abandonment due to negative feedback is advantageous.
I'm not saying anything new here. But I understand better where you were coming from.
Software development is construction of the plan. And all industries also estimate how long planning will take but it's a vastly more significant for software as that's the entire thing.
Which means that we're doing it more often, so we have more data and experience to call on when estimating.
And it means it's more important to estimate the design task, since it's vastly more significant.
They're estimates. They're not called "certains", "definites" or "numerical solutions" because they are none of these things.
You can't download the building package. You actually have to build the building again. If it's the same building I would expect them reuse the same blueprints. So that holds true.
Where as in software it's quite easy and desirable to reuse software. Which is why you should not be rewriting the same thing over and over.
As a result, the problems you face are unique. Your not just stamping out the same building again and again.
You also have to factor engineering time into the plan. If you read Industrial Megaprojects, the author shows that projects which don't do a bit of upfront estimating and research tend to go off the rails on a scale that software struggles to match.
If you make a blueprint and give it to 2 construction companies to build the building, you'll end up with 2 very similar buildings.
If you give a software spec to 2 separate software companies you'll get 2 completely different programs.
You can't create a blueprint/spec that is sufficiently detailed so that 2 different companies/teams will build essential the same software.
A blueprint/spec that detailed would be the code itself.
The closest analog to software would be designing processes, or maybe designing a factory or assembly line. And the analog to the code in that situation would be the factory or assembly line itself.
It's that professionals perform similar tasks very often. Including us.