Groups | Search | Server Info | Login | Register
Groups > comp.lang.misc > #11394
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Newsgroups | comp.lang.misc |
| Subject | Re: simplicity / complexity |
| Date | 2025-10-09 14:19 +0000 |
| Organization | To protect and to server |
| Message-ID | <10c8g90$1h6i3$1@paganini.bofh.team> (permalink) |
| References | (8 earlier) <108vuu7$2sngv$7@dont-email.me> <10c5r04$172ul$1@paganini.bofh.team> <early-20251008154832@ram.dialup.fu-berlin.de> <10c73oj$1engi$1@paganini.bofh.team> <10c74vi$227mh$1@dont-email.me> |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 09.10.2025 03:39, Waldek Hebisch wrote:
>> [...]
>>
>> But IMO in most cases releasing early makes sense.
>
> LOL, yeah! - Let the users and customers search the bugs for you!
Maybe you think that you can write perfect software. There are
widely available statistics which show that software of nontrivial
size have bugs. Developer may plan things (FYI I spent a lot
of time on planning befor I start coding), test things but after
some time arrives at point of diminishing returns: finding new
bugs takes a lot of effort. If you have paying customers you should
have money a hire testers. You should hire multiple developers
and do code reviews. But within reasonable resource bounds and
using known tecniques you will arrive at point where finding new
bugs takes too much resources.
If your customers need/demand higher quality they should pay
appropriatly to cover needed cost. But expecting no bugs is
simply unrealistic. I read about developement of software
controlling Space Shuttle. Team doing that boasted that
that have sophisticated developement process ensuring high
quality. They had 400 people working on 400 kloc program.
Given that developement was spread over more than 10 years
that looks as very low "productivity", that pretty high
developement cost. Yet they where not able to say "no bugs".
IIRC they where not even able to say "no bugs discovered
during actual mission", all that they were able to say
was "no serious trouble due to bugs". Potential effects
of failure of Space Shuttle software were pretty serious,
so it was fully justified to spent substantial effort on
quality.
What I develop is quite non-critical, I am almost certain
that "no serious trouble due to bugs" will be true even if
my software is full of bugs. And similar thing applies to
substantial part of open source software. I wrote above
about hiring testers. Non commercial open source projects
typically do not have money to pay for testing. But
there are people who are willing to do testing for free.
More precisely, given not critical nature of software
bugs are just inconvenience and frequently there are
folks who consider inconvenience due to bugs as small
compared to benefits offered by software.
When I wrote about releasing early, I mean releasing when
stream of new bugs goes down, that is attempting to predict
point of diminishing returns. More conservative approach
would continue testing for longer time in hope of finding
"last bug". Some people may use formulation like "do
all what it possible to increase quality and after that
release", but there is always something more that could
be done. So one need to decide when it is enough and release.
I have a problem (and tone of your message suggest that you
may have this problem too), I really would prefer to catch as many
bugs as possible during developement and due to this I
probably release to late. Note that part of my testing may
be using a program just to do some work. Now, if program
is doing valuable service to me, there is reasoble chance
that it will do valuable work for some other people.
Pragmatically you can view this a a deal: other people
get value from work done by the program, I in exchange get
defect reports that allow me to improve the program.
I see nothing wrong in such a deal, as long as it is
honest, in particular when provider of the program
realistically states what program can do.
BTW: Some users judge quality of software looking at number of
bugs reports. More bugs reports is supposed to mean higher
quality. If that looks wrong to you more detailed reasoning
goes as follows: number of bug reports grows with number of
users. If there is small number of bug reports it indicates
that there is small number of user and possibly that users
do not bother reporting bugs. Now, user do not report bugs
when they consider software to be hoplessy bad. And user
in general prefer higher quality software, so small number
of user suggest low quality. So, either way, low number
of bug reports really may mean low quality. This method
may fail if you manage to create perfect software free of
bugs with perfect documentation so that there will be no
spurious bug reports. But in real life program tend to have
enough bugs that this method has at least some merit.
--
Waldek Hebisch
Back to comp.lang.misc | Previous | Next — Previous in thread | Next in thread | Find similar
Algol 68 / Genie - opinions on local procedures? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-18 04:52 +0200
Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-08-18 16:54 +0100
Re: Algol 68 / Genie - opinions on local procedures? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-18 18:30 +0200
Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-08-19 00:45 +0100
Re: Algol 68 / Genie - opinions on local procedures? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-19 02:44 +0200
Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-08-20 00:47 +0100
Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-20 00:43 +0000
Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-08-20 23:58 +0100
Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-21 02:59 +0000
Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-08-23 00:42 +0100
Re: Algol 68 / Genie - opinions on local procedures? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-23 02:29 +0200
Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-23 02:36 +0000
Economizing resource requirements (was Re: Algol 68 / Genie - opinions on local procedures?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-21 21:02 +0200
Re: Algol 68 / Genie - opinions on local procedures? antispam@fricas.org (Waldek Hebisch) - 2025-10-04 01:11 +0000
Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-04 03:37 +0000
Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-10-07 22:03 +0100
Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-07 22:04 +0000
Various digressions (was Re: Algol 68 / Genie - opinions on local procedures?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-08 01:27 +0200
Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-10-10 01:11 +0100
Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-10 01:39 +0000
Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-10-11 12:47 +0100
Re: Algol 68 / Genie - opinions on local procedures? antispam@fricas.org (Waldek Hebisch) - 2025-10-08 17:04 +0000
simplicity / complexity Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-08-26 18:42 +0000
Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-27 00:28 +0000
Re: simplicity / complexity Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-08-30 19:10 +0000
Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-30 22:43 +0000
[OT] NetBSD vs. Linux(-based systems) Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-09-04 18:50 +0000
Re: [OT] NetBSD vs. Linux(-based systems) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-05 00:03 +0000
Re: [OT] NetBSD vs. Linux(-based systems) Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-09-07 15:55 +0000
Re: [OT] NetBSD vs. Linux(-based systems) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-07 21:17 +0000
Re: [OT] NetBSD vs. Linux(-based systems) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-09-05 12:02 +0000
Re: [OT] NetBSD vs. Linux(-based systems) Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-09-07 16:30 +0000
Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-27 07:53 +0200
Re: simplicity / complexity Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-08-30 19:39 +0000
Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-30 22:45 +0000
Re: simplicity / complexity Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-08-31 13:35 +0000
Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-31 22:40 +0000
[OT] free software Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-09-04 18:25 +0000
Re: simplicity / complexity antispam@fricas.org (Waldek Hebisch) - 2025-10-08 14:03 +0000
Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-08 16:21 +0200
Re: simplicity / complexity John Ames <commodorejohn@gmail.com> - 2025-10-08 08:08 -0700
Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-08 21:18 +0000
Re: simplicity / complexity John Ames <commodorejohn@gmail.com> - 2025-10-08 14:31 -0700
Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-09 00:09 +0000
Re: simplicity / complexity John Ames <commodorejohn@gmail.com> - 2025-10-09 08:44 -0700
Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-09 21:52 +0000
Re: simplicity / complexity John Ames <commodorejohn@gmail.com> - 2025-10-09 15:21 -0700
Re: simplicity / complexity antispam@fricas.org (Waldek Hebisch) - 2025-10-09 00:34 +0000
Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-09 03:48 +0200
Re: simplicity / complexity ram@zedat.fu-berlin.de (Stefan Ram) - 2025-10-08 14:53 +0000
Re: simplicity / complexity ram@zedat.fu-berlin.de (Stefan Ram) - 2025-10-08 15:24 +0000
Re: simplicity / complexity antispam@fricas.org (Waldek Hebisch) - 2025-10-09 01:39 +0000
Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-09 04:00 +0200
Re: simplicity / complexity antispam@fricas.org (Waldek Hebisch) - 2025-10-09 14:19 +0000
Re: simplicity / complexity ram@zedat.fu-berlin.de (Stefan Ram) - 2025-10-09 14:48 +0000
Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-10 12:36 +0200
Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-10 12:09 +0200
Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-31 08:32 +0200
Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-31 08:34 +0200
csiph-web