
Ask HN: How do you explain to non-technical people that bugs happen in software? - jcgr
I work in a software agency, and we have some clients that don&#x27;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?
======
davismwfl
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.

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.

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.

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.

------
dundercoder
Imagine balancing a checkbook with 10,000 transactions where if you’re off by
a penny the account shuts down and becomes inaccessible.

------
illwrks
Perhaps making a sponge cake?

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.

------
demygale
If you buy a brand new house, you do a walk-through and make a list of
problems you want the builder to fix.

These are bugs.

No one would skip this step when buying a new house because there are always
bugs.

------
SmushyTaco
You could say "Our product reacted in a way that wasn't intended and we are
currently working on a solution."

~~~
greenyreeny
I like it. It's plain and simple.

------
simplecomplex
> bugs tend to happen most of the time.

They do? Software not working most of the time is indicative of poor quality
software and untested requirements.

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.

“Bugs tend to happen most of the time” sounds like someone is not taking
responsibility.

~~~
hluska
"They do?" sounds like someone doesn't have a lot of experience. Bugs do
happen most of the time, even in high quality software (whatever that is).
Sometimes they're the result of sloppy code, other times, they're the result
of sloppy requirements and other times, they're the result of poor
communication.

~~~
simplecomplex
In my experience, bugs do not happen “most of the time” (OPs words). I’ve been
a software engineer for 12 years. High quality software is software that
works, for the required use cases and devices.

> ... _most of the time_

> ... _for the required use cases._

