0

When I buy a house or a car, the product is already completely ready. It's very seldom that an error will be noticed later by the customer.
In software engineering, on the other hand, errors (bugs) are normal and occur frequently. Even in production bugs can be found, so that software receives updates regularly.

Suppose, I'm talking to a child. I explain that fixing errors, even in productive software, is an important part of my daily routine. He might think, that I'm a bad programmer, who delivers flawed products.

How to make it clear, that bugs are normal?
Is there a simple analogy from the real world?

Improve this question
4
  • see How do I explain ${something} to ${someone}? Commented May 31, 2021 at 12:32
  • 1
    I think this is offtopic, but honestly except for very simple things, almost any product can have a bug in a similar way to a software bug. I mean, for extreme cases, a non well built house might collapse or the brake system of a car may fail. I think it's easy to link with that. Commented May 31, 2021 at 12:32
  • 2
    "When I buy a house or a car, [..] it's very seldom that an error will be noticed later by the customer." I think that is really not a correct statement. Pretty much everyone who didn't build their own house tends to find some shoddy craftmanship, and there is a significant recurring pattern with finding hidden damage in a car that proves it was in a serious crash before - even if the seller claims it hasn't been. Commented May 31, 2021 at 13:26
  • I knew a guy who had a house built for him, and unfortunately someone drilled a hole through a water pipe. What did they do to fix it? The wrapped a plastic bag around the bit with the hole, with a really good knot. Some time later the wall started to go black and mouldy. Sure, no bugs when you buy a house. Commented May 31, 2021 at 15:44

1 Answer 1

Reset to default
5

When I buy a house or a car, the product is already completely ready. It's very seldom that an error will be noticed later by the customer.

That’s a wrong assumption. In all the countries I have lived so far, there is a mandatory requirement to subscribe a construction insurance to cover bugs discovered up to 10 years after construction. Because a house is a complex system. Moreover Courts have plenty of examples of malfunctions.

The quality of cars is higher nowadays. But I got a car a couple of years ago that I had to stop and restart on very cold days, for the engine to work well. Again, garages are full of such cases.

How to make it clear, that bugs are normal? Is there a simple analogy from the real world?

Very simple: making software is like constructing a castle of legos for someone. At first one need to agree how the castle should look like. And sometimes there are misunderstandings, that we notice only when the castle is build. That’s a castle-bug. Sometimes the castle is so complex that it does not work in the end: a wall breaks, a door can’t be opened because there is no room to get to it and so on. That’s also bugs.

Of course we make everything possible to avoid the bugs. But when it happens, it’s the occasion to make it better so that everybody is happy on the end. And that’s what makes software as funny as building lego castles.

(P.S: Some kids prefer castles, some prefer zoos, houses or spaceships. Chose the subject according to the demonstrated interests of the kid. And I have no lego stocks: any other construction set, including the sandbox will do)

Improve this answer
9
  • Not to forget about the bugs in the software of most modern cars ;-) Commented May 31, 2021 at 15:58
  • I would distinguish bugs from poor specification. Your castle example sounds more like poor specification. Commented Jun 1, 2021 at 18:21
  • @KevinKrumwiede I did not mention "specification" because it's narrowing down the issue and raises new questions. You can have a good specification but later discover that there is a case that is not covered. Perhaps it existed already when specs were written. Perhaps it's completely new. People would nevertheless call it "bug". A lot of bugs also occur independently of the specs, due to misunderstanding between developers or between different versions of yourself, or misunderstanding of the problem. This is why I insisted on misunderstandings. But you're right poorly crafted code exists. Commented Jun 1, 2021 at 18:47
  • You didn't mention "specification" by name, but you described it. "At first one need to agree how the castle should look like. And sometimes there are misunderstandings, that we notice only when the castle is build." That is NOT a bug. Commented Jun 1, 2021 at 19:38
  • 1
    @KevinKrumwiede What's your definition of bug? Many definitions (see 3 examples here) see it as a deviation from expectation and not as a deviation from specification. There is hence a lot of room for interpretation and I can ensure you that court rooms are full of parties accusing each other of bugs when in the end it's only a set of misunderstandings. Not to speak about the case where the upfront agreement is just a vague outline (far from a spec), that is then refined iteratively with stories during the construction process ;-) Commented Jun 1, 2021 at 21:23

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.