martin.burnicki@burnicki.net said:

That sounds like poor software engineering.  Or poor engineering management.

The wk860 is supposed to represent the build time of the software so it will
work for 20 years from when it was built rather than 20 years from when the
10 bit week counter last rolled over or 20 years from when the constant was
last updated.

That magic constant has to be pulled out to a module where it is visible
rather than buried deep in some large module.  Then the recipe for releasing
software has to update it, either by having a step in the checklist where the
human does the edit or by running a script that does it.  (Yes, you have to
start by having a formal procedure for releasing software/firmware.)

--
These are my opinions.  I hate spam.

Hal,

On 02/26/2016 09:39 PM, Hal Murray wrote:

It's easy to say, but as work progresses over the years, it is hard to
revisit all aspects of the code and re-evaluate it. One has to adapt
humbleness to the task, try to check as much as possible, but still
accept that you can't find all the bugs. Often the need to finish new
products on time comes before, flushing out all the new bugs.

Indeed. Just not quite the full 20 years.

That assumes one can foresee this to become a problem. Most doesn't
consider it to be a recent problem. However, just updating the constant
won't work for the type of products we have here, as the boxes we now
see have problems was never updated. A battery-backed RTC clock would
have helped, but the battery would probably fail around now. EEPROM
updates in the boxes would have helped, but 20 years back EEPROMS
wheren't too happy about many updates.

I think it is better to realize that the solution was good enough for
the expected lifetime of the product.

I've made some design choices like this. Some of them have survived the
complete re-writes and still not greatly failed the assumptions. Some
have faired less well. Some of the design decisions I make can easily
live for 20 years, and the one thing I've learned is that it is hard to
balance longterm with practical design for the expected lifetime.

I think they did fairly well. For most systems, the remaining problem is
showing the time as being exactly 1024 weeks off, but all other aspects
working correctly. We can apply prior knowledge to correct the 1024
weeks offset and keep these receivers running way beyond their designed
lifetime. That's actually quite respectable in my book.

Best Regards,
Magnus

On 2/26/16 12:39 PM, Hal Murray wrote:

for something which has a design life of <1024 weeks, I don't know that
this can be described as poor software engineering. The software meets
the requirements. It doesn't have extra complexity (needed to deal with
rollover) that is not required.

For all we know, they have some process at the mfr which would trigger
an update on new releases of the software (for new models of receiver).

20 years is a very long time for most electronics made in large
quantities. The people who get "bit" by this kind of thing are folks
using old surplus equipment (time-nuts, etc.) and deep space missions
(lots of inheritance, long mission durations).

Hal,

Hal Murray wrote:

Do you know this, or are you just assuming this? ;-)

There are also approaches where the proper extension of a week number
doesn't just work within a single 1024 week cycle with some hardcoded
limit, like this simple example:

if ( wn < 860 )
wn += 1024;

There may always be pieces of code which generate a faulty result under
certain conditions, and no stumbles across this even in reviews until it
really happens.

I'm not aware of any project where each single line of code is checked
once again whenever a new release is rolled out.

Martin

On 02/29/2016 11:31 AM, Martin Burnicki wrote:

Rather, in all projects I've seen there is a tendency to trust existing
code and only extend it. Re-validating it is usually regarded as money
in the sea. That old code can have incorrect assumptions that you
eventually expose as you change its environment is a re-occurring
learning experience. Modern approaches to testing helps, and working on
the backlog of testing can help to disclose such problems, but only if
the test-code writer has the mindset that covers the problem at hand.
It's easy to make bold statements, reality is much more humbling
experience in the long run. Good test-benches will aid you as you want
to make larger clean-ups of old code. Larger clean-ups helps to expose
old bugs as you actually look at the code as a designer again. It is
also humbling to see what errors a younger yourself did and how you now
don't do such design anymore as you have been bitten badly by the bug.

Cheers,
Magnus

Hi

Take a look at math libraries and things like printf libraries. Each time somebody
writes one, there are a group of bugs that come up again and again. Yes, you
would think each group would come up with creative new errors … not so much.
There are always obvious assumptions that turn out to be wrong in corner cases.

Bob

On 2/29/16 10:56 PM, Magnus Danielson wrote:

Ariane 5...

Modern approaches to testing helps, and working on

Hi Jim,

On 03/01/2016 03:24 PM, jimlux wrote:

Indeed. Most of the cases the failure isn't as spectacular.

Cheers,
Magnus