Groups | Search | Server Info | Login | Register

Groups > comp.lang.misc > #11405

Re: simplicity / complexity

Show all headers | View raw

On 09.10.2025 16:19, Waldek Hebisch wrote:
> 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. 

No. (What makes you think that I would think that one could be
sure to write [non-trivial] software error-free and perfect?)

But there are methods to write more reliably reliable software!

Also, that software has more or less bugs doesn't justify, IMO,
"early releases" as principle, and especially not as principle
to obtain software quality; this was the inherent point of the
statements in previous posts.

> [...]  But within reasonable resource bounds and
> using known tecniques you will arrive at point where finding new
> bugs takes too much resources.

And this is also no rationale for "early releases".

> 
> If your customers need/demand higher quality they should pay
> appropriatly to cover needed cost.  But expecting no bugs is
> simply unrealistic. 

This is again the same straw-man; no one said or implied such
a thing.

> 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.

And sometimes it doesn't help if the methods aren't applied
consequently! (Since you mentioned a space technology example
you may want to read about the Ariane 5 incident; the
post-mortem report is very enlightening concerning errors in
demanding software projects that are basically extremely good
organized!)

> 
> 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. [...]

I've no insight in your projects and methods. (That's not my
business.)

From the professional projects I participated in in the past
we could not risk having lots of bugs or severe bugs. So we
either had or installed the necessary methods and provisions
to achieve the high quality we needed; and that worked well.

So probably you have other projects in mind; but even then,
the costs for fixes of problems appearing later are much
higher than detecting them early in the development process.
(In your area maybe "only" loss of reputation, not money, or
lives.)

> 
> 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. 

The problem with that is that bugs - assuming we speak about
those reported; mind your "early release" approach! - appear
too late to be fixed cheaply. (And predictions need numbers
and project context information! And experience.)

> More conservative approach
> would continue testing for longer time in hope of finding
> "last bug". [...]

That is not a "conservative approach" but nonsense, and I've
never heard such procedure to be established in professional
contexts; unless you could apply a formal verifier you cannot
say when there's no bugs any more.

No. Conservative, or standard approach, is to apply all the
methods of software development, from formal specification,
tools testing specifications, designs, tests on the various
levels, supporting tools, experts on the respective QA and
project management tasks, and of course trained programmers.

> 
> 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. [...]

Yes, I try to reduce the cases where bugs may slip in. For my
personal toy-projects that's not critical, but if I want to
(sort of) "publish" anything I spend yet more effort. For the
professional projects I was engaged in it was non-negotiable,
though; the quality measures were a must!

> 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.

Personally I don't want to publish in a quality that results
in a lot of feedback that requires a lot of time to handle.
And it's not only about coding-bugs but also about software
design. (My rants often have a strong focus on "lousy design"
and on bugs only as a secondary factor; my experience tells
me also that lousy designs are also a significant source of
implemented bugs.)

> 
> BTW: Some users judge quality of software looking at number of
> bugs reports.  More bugs reports is supposed to mean higher
> quality. 

More bug reports primarily suggests that the software is of
inferior quality (presuming all other factors for comparison
are equal or appropriately normalized).

> If that looks wrong to you more detailed reasoning
> goes as follows: number of bug reports grows with number of
> users. 

This is not necessarily the case.

> 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. 

This is not a given consequence.

> 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.

It is always sensible going for high quality early in the
development process to create less bugs and less bug reports.
Frankly, to say that a lot of bug reports (thus bugs) is good
or useful in any way is completely erroneous. You can draw
quality conclusions also from no or "too few" bugs and focus
on these.

Mind also that fixing bugs often is also "patching" software;
with many bug reports you have to do a lot of changes, in a
way defined by the time scale as they arrive, not by design.
In well-designed and well-written software that may be a
less critical factor, but to achieve that quality state in
the first place you'd have to install some quality measures.

Lots of bugs and bug-reports is nothing you sensibly want to
achieve to obtain software quality.

Though you should track all numbers you can get from your
development process to be able to draw conclusions and act.

Anecdotally, to give an impression of contexts I worked in...

We had a client server component architecture, each component
with one dedicated person responsible for it. We measured the
errors from tests on various levels (unit, system, integration,
acceptance tests). We also measured check-ins, and number of
changes of the requirements (for example). I installed the QA
measures I found to be necessary, and we had the best outcome;
best outcome means quasi-zero bugs!

In another context I took responsibility for a refactoring of
governmental software, software that evolved over years before
I joined. Here the refactoring not only reduced LOCs but also
restructured the code. The number of bugs reduced linearly with
the reduction of code, and yet more with the better structure.
(But of course that needed the QA infrastructure and processes
we had invented, it's not a given.)

PS: You wrote quite some hypotheses about open source and the
user community there; I'm positive that the principles we got
from the commercial professional software development are also
valid for the area you were focusing on. But YMMV, of course.

Janis

Back to comp.lang.misc | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

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