I've dealt with various contractors for things like home renovations, and the original estimates for time and cost are basically worthless in that case.
For something simple, like replacing a sink or fixing a leak, they'll generally stick with the original estimate.
Just like software development, isn't it? Simple things are easy to estimate and do. When complexity increases - everyone fails to estimate correctly. However if a contractor offers you to replace your floor for $10000 and then suddenly it turns out you have to pay extra $25000 because your house on the southern side of the hill and it's a leap year and it turns out it's a full moon the week when they will finish and they charge extra for this or you will have to wait another 3 months, then you will be really pissed.
So you wouldn’t pay a plumber in your home if (s)he didn’t predict the end result and budget, is that what you’ trying to say?
If yes, I fully agree. The reason why this anti-pattern exists is that something complex (software development) is modeled after something complicated or simple (like plumbing).
In case you‘re open to learning about that, check out the Cynefin model.
Your analogy highlights something else: software delivery - like plumbing- is often seen merely as an investment, while in today’s digital age, return on investment should be considered.
Finally, there are cars and fighter planes built with Scrum. So it’s possible to apply agile practices to engineering as well.
My point was - you should be able to estimate efforts. And customer should be aware that any scope change basically returns you back to the beginning of the entire process - more or less. I am fully aware, that one can't predict everything and like a plumber who first needs to break the wall to see where exactly the pipe is broken, and how bad the problem is, then tell you what you have to do next and what your options are. This is the agile part precisely, but nevertheless we are professionals and we should be able to estimate how long it will take to do something.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If an electrician or plumber or any engineer starts talking to you this way you will never hire him.
I've dealt with various contractors for things like home renovations, and the original estimates for time and cost are basically worthless in that case.
For something simple, like replacing a sink or fixing a leak, they'll generally stick with the original estimate.
Just like software development, isn't it? Simple things are easy to estimate and do. When complexity increases - everyone fails to estimate correctly. However if a contractor offers you to replace your floor for $10000 and then suddenly it turns out you have to pay extra $25000 because your house on the southern side of the hill and it's a leap year and it turns out it's a full moon the week when they will finish and they charge extra for this or you will have to wait another 3 months, then you will be really pissed.
So you wouldn’t pay a plumber in your home if (s)he didn’t predict the end result and budget, is that what you’ trying to say?
If yes, I fully agree. The reason why this anti-pattern exists is that something complex (software development) is modeled after something complicated or simple (like plumbing).
In case you‘re open to learning about that, check out the Cynefin model.
Your analogy highlights something else: software delivery - like plumbing- is often seen merely as an investment, while in today’s digital age, return on investment should be considered.
Finally, there are cars and fighter planes built with Scrum. So it’s possible to apply agile practices to engineering as well.
My point was - you should be able to estimate efforts. And customer should be aware that any scope change basically returns you back to the beginning of the entire process - more or less. I am fully aware, that one can't predict everything and like a plumber who first needs to break the wall to see where exactly the pipe is broken, and how bad the problem is, then tell you what you have to do next and what your options are. This is the agile part precisely, but nevertheless we are professionals and we should be able to estimate how long it will take to do something.