I work in a software agency, and we have some clients that don't understand that bugs tend to happen most of the time. Also that those bugs will lengthen the estimated time of the project. Any useful analogies that some of you use to explain all of this sort of stuff?
I generally try to make it relatable to them. I have yet to find any other industry that doesn't have similarities where things go wrong no matter how well the plan was at the start. The way I found was best is to ask a lot of questions up front about their industry and typical delays, "issues that comes up etc before anything has even happened. Then when the nearly inevitable delay and inevitable bug comes up it is easier to explain it to them.<p>In the event you didn't do this up front and don't know their industry well enough, you can use common analogies of building a house, and the delays and cost overruns that are so typical there. Many times caused by clients wanting changes or items which were not spec'ed correctly up front etc.<p>In the end I have always found it is best to not get defensive, and not be dismissal like this is just normal, but to explain that there are a lot of challenges to engineering anything, whether it is a website or a PCB. Also know your audience. Some people want all the details and that makes them feel better that they understand. Others just want the new date and a reason why it is more solid than the last, or want to know you are handling the bug and it'll be complete by X. Don't try to explain details to the person who just wants to know when it will be fixed, and don't try to dismiss the person who wants to try and understand the details.<p>One other example I have used for people that are less technical, I will ask them if they ever wrote a multipage term paper or something to the sort in school (everyone has usually). And I'll ask, did you ever make a grammar mistake? How about a spelling error? Ok, now imagine that paper isn't 10 pages long (~600 lines) but instead 100 or 1000 pages long, what do you think the chances are we will find some mistakes when we start proof reading it? What about after we have proof read it 10 times? Do you think there still might be some issues 5 days later when someone else has read it? Usually this helps people.
Perhaps making a sponge cake?<p>You can know all the ingredients and know how long each step takes.
You may have made it successfully before too.
However if the yeast is bad then the sponge won't rise, if the eggs are not fresh or not at room temperature then you will have more problems... you need to go back and make the sponge again.
If you buy a brand new house, you do a walk-through and make a list of problems you want the builder to fix.<p>These are bugs.<p>No one would skip this step when buying a new house because there are always bugs.
> bugs tend to happen most of the time.<p>They do? Software not working most of the time is indicative of poor quality software and untested requirements.<p>Yes, poor quality software has lots of bugs. Yes, many companies are selling poor quality software. But, high quality software does not have any bugs for the required use cases.<p>“Bugs tend to happen most of the time” sounds like someone is not taking responsibility.