I got this the other day: "there seems to be a lot of buzz out in the general public regarding software bugs".

Attached to this was an article from The Economist in 2003 plus one from 2010. To me, this doesn't seem to be a "lot" of buzz. But what …

Happy birthday, mom. Glad to see you're still doing well, avoiding the complications of COVID-19.

You asked what it was I did for a living. Emphasis on the past tense, now that we're both fully retired old people.

I have to confess that it's not easy describing high-tech work. There's …

See Why HATEOAS is useless and what that means for REST.

The article provides a background leading up to these observations:

• There are very few good tools to create a REST API using this style
• There are no clients widely used to consume these types of APIs

The "useless" in …

https://www.meetup.com/DC-Web-API-User-Group https://www.meetup.com/DC-Web-API-User-Group/events/245014240/ Nice bunch of people. Nice facility. Good discussions.

I write Microservices. And not-so-micro Services. API's.

I got this email recently.

"Goal: get you to consider adding Gooey to your Python tool set" "Gooey What it's for: Turn a console-based Python program into one that sports a platform-native GUI. Why it's great: Presenting people, especially rank-and-file users, with a …

Once upon a time, when today's old folks were young, we'd debate the two project strategies: Hard Part Do Later (HPDL) vs. Hard Part First (HPF).

The HPDL folks argued that you could pick away at the hard part until -- eventually -- it wasn't hard any more. This doesn't often work …

See this short discussion on a Stingray Reader feature:

https://sourceforge.net/p/stingrayreader/discussion/COBOL/thread/d2132851/?limit=25#2a3a

This turned into an exercise in pure TDD.

<rant>

I'm not a fan of applying TDD in a strict, death-march fashion.

I see the comments on Stack Overflow that …

A single poorly-made decision can have profound ripple-effects. Once your stuck with it, you make accommodations, hacks and work-arounds. Eventually, things work, but the result is less than ideal.

Changing tack requires sometimes pervasive rework to the application. How can we reduce the risks and improve the value created?

Read this first: "There is something I find interesting about online discussions around performance issues..." It's about Stack Overflow, specifically. Apparently, someone didn't get their question answered and decided it was better to gripe than to rewrite the question.

Let's look at their response in pieces.

"people try to gang …

Imagine that we've got a collection of applications used by customers to provide data, a collection of applications we use to collect data from vendors. We've got a third collection of analytical tools.

Currently, they share a common database, but the focus, use cases, and interfaces are different.

Okay so …