https://jalopnik.com/honda-clocks-are-stuck-20-years-in-the-past-and-this-mi-1848306970
Honda Clocks Are Stuck 20 Years In The Past And There Isn't A Fix

https://www.theverge.com/2022/1/2/22863950/microsoft-exchange-y2k22-bug
Microsoft issues a fix for Exchange Y2K22 bug that shut down company emails

 

Wherever possible and appropriate I plan for 99999 years.
My dates and times are written 02022.01.06 23:59:59, for example.

I took this lead from the Long Now Foundation.

https://longnow.org/

 

https://jalopnik.com/honda-clocks-are-stuck-20-years-in-the-past-and-this-mi-1848306970
Honda Clocks Are Stuck 20 Years In The Past And There Isn't A Fix

https://www.theverge.com/2022/1/2/22863950/microsoft-exchange-y2k22-bug
Microsoft issues a fix for Exchange Y2K22 bug that shut down company emails

Indeed, software is becoming a pain for most of us.

The rapidity with which its developed, the reluctance to do any serious design work, the increasing reliance on "agile" all help to create a world of unreliability.

 

Indeed, software is becoming a pain for most of us.

The rapidity with which its developed, the reluctance to do any serious design work, the increasing reliance on "agile" all help to create a world of unreliability.

Then I hear the words, "We'll fix that in software" as a hand-wave to paper-over some serious electrical or mechanical problem, I want to scream.

 

I have mixed feelings about agile; mostly negative.

Agile is a developers solution. NOT a systems solution. Sure, one can develop faster but at a cost. An old model of software development required that developers should not test their own software. Agile provides a shortcut to this concept.

I was the operations manager for a 24x7 eCommerce site. We/I maintained a five 9s availability until a new VP took over and implemented his vision based on agile. Sure, he cut devrlopmeht time by 70%. A development cycle went from three months down to a month. But our availability stats suffered. At best going from five 9s to four 9s.

And it resulted in my undeserved termination. A new release caused a client to lose a lot of business. It was effectively a 24 hour downtime for one client, because QA resources were denied.

You cannot and should not cut independent testing short by even an hour. With our lives increasingly dependent on software, proper testing is more critical than ever before.

 

It all boils down to being too stingy with the bits, really.

Now let's see. The "known universe" is thought to be approximately 14 billion years old or 14000000000×365×24×60×60×1000 = 4.41504×10²⁰ milliseconds elapsed since the Big Bang. The number of bits required to count that high is roughly ln(4.41504×10²⁰) ÷ ln(2) = ~68.58. So choosing a 64-bit number would give us almost a billion years of millisecond accuracy timing. Done!

Now the only question is how to create a truly robust relativistically adjusted "Zulu Time" system... =)

 

Its interesting (well it is to me) how those who are skeptical of stuff like "agile" are from an engineering, physical systems, background.

There is a great deal of often vocal support for "agile" and "scrum" and so on within the software community. The focus on delivering "something" early on is highly valued, gives visibility to management about "progress".

I think that it's precisely because software is a very very hard thing to manage that agile etc. has crept in to make it easier, or appear easier.

There's rarely any formal design these days, rarely any dispassionate, objective requirements gathering and without these you get uncertainty and uncertainty is the enemy here.

So many documents I see that claim to be requirements are often expressing aspects of design, for example rather than speaking in terms of business concepts and processes, they quickly start talking in terms of databases and apps and patterns that might exist today in the IT systems.

Yes a database might be suitable or relevant here but it might not, there might be alternatives. Yes some app might be a good idea here but again might not.

The mixing of solution domain abstractions to describe the problem domain is a huge source of problems in my view.

 

Its interesting (well it is to me) how those who are skeptical of stuff like "agile" are from an engineering, physical systems, background.

There is a great deal of often vocal support for "agile" and "scrum" and so on within the software community. The focus on delivering "something" early on is highly valued, gives visibility to management about "progress".

I think that it's precisely because software is a very very hard thing to manage that agile etc. has crept in to make it easier, or appear easier.

There's rarely any formal design these days, rarely any dispassionate, objective requirements gathering and without these you get uncertainty and uncertainty is the enemy here.

So many documents I see that claim to be requirements are often expressing aspects of design, for example rather than speaking in terms of business concepts and processes, they quickly start talking in terms of databases and apps and patterns that might exist today in the IT systems.

Yes a database might be suitable or relevant here but it might not, there might be alternatives. Yes some app might be a good idea here but again might not.

The mixing of solution domain abstractions to describe the problem domain is a huge source of problems in my view.

What agile “is” versus how agile is “practiced” are two very different things. I’ve seen it lead some developers to justify poor practice.

Your requirements descriptions are but an example. I’ve often found a slip-shod approach to integration. And regression testing. All justified by “agile”; any process that slows down development is ignored or given short shrift.

 

Its interesting (well it is to me) how those who are skeptical of stuff like "agile" are from an engineering, physical systems, background.

There is a great deal of often vocal support for "agile" and "scrum" and so on within the software community. The focus on delivering "something" early on is highly valued, gives visibility to management about "progress".

Agile was not designed to work for hardware, or hardware engineering.

We are skeptical because we can't even think of 'fix it in the next release' as a financially feasible answer to a fundamental design screw-up.

 

What agile “is” versus how agile is “practiced” are two very different things. I’ve seen it lead some developers to justify poor practice.

Your requirements descriptions are but an example. I’ve often found a slip-shod approach to integration. And regression testing. All justified by “agile”; any process that slows down development is ignored or given short shrift.

Yes the term "slows down" or "slows us down" is often used liberally in meetings I've attended!

The metric is never defined, or is defined poorly, making some task in some project longer does not automatically push the end date out, this is not understood by people today because they have no grasp of what a project plan is because they don't believe in planning.

The emphasis is on "visible" progress, something that gives an impression of progress and productivity rather than a deeply measured meaningful progress that one can only really get with a project plan.

The last time I argued this was in a job I left soon afterwards where it was insisted that "waterfall is dead" yet when I pointed out that waterfall is not the same as a project plan, it was not really understood, when I said "You'd never be able to estimate the time, resources and cost for developing a jet airliner using agile" the room fell silent.