Take a look at this:

This is in the Museum of the Palazzo Massimo alle Terme in Rome, and it comes from an ancient Roman Villa in Rome. Probably painted in the first or second century CE. There’s walls of this stuff in the museum.

It’s not realism, but minimalistic sketches that, in many ways, outdo realism in artistic quality. To me, this looks more like something that you might find in Leonardo’s sketchbook than on the wall of on ancient Roman Villa from 1200 years earlier.

Back in the 70’s and 80’s there were “Travesty Generators”. You pushed some text into them and they developed linguistic rules based on probabilities determined by the text. Then you could have them generate brand new text randomly created by applying the linguistic rules developed from the source text.

Surprisingly, they would generate “brand new” words that weren’t in the original text, but were real words. And the output matched stylistically to the input text. So you put in Shakespeare and you got out something that sounded like Shakespeare. You get the idea.

I built one and tried running some TS Eliot through it, because stuff is, IMHO, close to gibberish to begin with. The results were disappointing. Basically because it couldn’t get any more gibberishy that the source.

I strongly suspect that the same would happen with Trump’s gibberish. There used to be a bunch of Travesty Generators online, and you could probably try one out to see.

I think there might be a better way to deliver “ballistic missiles to Russia”.

It’s just as much a sport as figure skating or synchronised swimming.

In a way, this question itself is very “un-agile”. Agile should be always forward-looking, “What can we do next?”, “What can we get done in this short period of time?”, “What should we do next?”.

OK, so you found a possible “defect” in your system. Is it a defect, or did someone slide in a requirements change 3 months ago?

This reminds me of playing chess. Sometimes a player will make their move when their opponent is distracted. The opponent hears, “Your turn”, and they look at the board. “Which piece did you move?”. The first player just shrugs.

The point is that you shouldn’t need to know which piece just moved. Every chess position is a “state” of its own, and your best move should depend on going forward from that state, not knowing how the board changed recently.

It’s the same thing here. You have a situation. Does it really matter how, when, who or why it happened? It shouldn’t, and here’s why:

Just because it’s a defect (if it is) doesn’t automatically mean that correcting it moves to the top of your “to do” list.

It’s going to take some non-zero amount of time to change it back to blue. And when you’re doing that, you’re not doing something else. There is always an opportunity cost to doing bug fixes and you shouldn’t treat them in an ad-hoc way. Should you be spending that time, and who gets to decide if you do? It’s not your decision. It’s the PO’s decision to make.

Maybe the PO doesn’t care about the colour. Maybe they do care, but not if it means some other feature gets delayed. Maybe it’s the most important aspect of the whole system, and there’s no way you can launch with it green. So you cancel the current Sprint and start a new one dedicated to fixing this defect! Maybe they regret asking for it to be blue, and now they’re happy that it’s now green.

If it was me, I’d get a quick T-shirt size estimate on the work required to change it back to blue, then put it in the Product Backlog to be reviewed with the PO. Maybe have a quick chat with the PO, or send a memo about it. Maybe the PO will need to check with their SME to see if anyone remembers asking for it to be changed to green. Maybe not. In any event, it either makes its way into a Sprint Backlog or it doesn’t.

Also, if you’re doing Agile right, then your clients are getting constant, hands-on, experience with your system as it is being developed. To go 100 days without some kind of “release” that they can play with and give you feedback is an anti-pattern. If you are giving them the latest version every week or two and after almost three months they haven’t noticed that the footer is green, then it’s probably not important.

On to the actual question. Jira is a potential sand trap of administrative complexity. The answer is usually to keep everything smaller. Smaller features, and smaller Sprints. Smaller teams. A team of 5 or 6, working in one week Sprints, can only do so much per Sprint. If your fundamental unit of work - a story, or a feature, or a ticket - is set to take something like 1/2 day and forms the basis of your Sprint Backlog, then each programmer on the team can do at most 10 SB items (in a perfect world). Depending on the composition of your teams, you’re probably going to have only about 3-4 programmers - which means 30-40 tickets per Sprint Backlog. And that’s a blue-sky number that’s practically impossible in a world with meetings. A team of 5 or 6 is going to complete closer to 20 Sprint Backlog items in 1 week Sprint in the real world.

The point being that 14 Sprints is your 100 days and each Sprint has about 20 easy-to-understand items in it. Whatever your management tools, it’s a failure if you can’t locate those 280 features in a matter of seconds. And it should be easy to eliminate 270 of them as not possible places where the change happened just from the description.

And when those SB items are small, as they should be, it’s not an onerous task to document inside them the requirements that they are supposed to meet.

When you have 1 month Sprints with tickets that take 2 weeks to complete, then everything becomes a nightmare. It becomes a nightmare because it’s virtually impossible to impose some kind of consistent organizational structure internally on free-form stuff that big. But it’s almost trivial to do it with tiny tickets.

And the other thing that happens with big tickets is that there’s tons of stuff that programmers do without thinking about it too much. If you’ve got two weeks to finish something, then there’s a ton of latitude to over-reach and the time estimate was just a wild guess anyways. If you have 3 hours to do something, then you’re going to make sure that what you need to do is clearly laid out - and then you have to stick to it or you won’t get done in time.

Did somebody “fix” the inconsistent footer colour while doing some huge, 2 week, ticket? Good luck finding out. But that’s not going to happen with tiny, well documented tickets.

I always thought of “Briton” in that last sense, while “Brit” has the meaning of anyone living in the UK (almost). But that’s from an outsider’s perspective.

As my English cousin corrected me, though, “I’m English, ‘British’ could be anything!”. She wasn’t, of course, talking about the difference between English and Welsh, or Scots.

Grandma’s on the roof and we can’t get her down…???

There’s two kinds of issues: instance and pattern. The first time or two, it’s instance. You deal with those with specificity. Something like, “I would prefer not to talk about this subject with you, please stop”.

If it persists, then it’s a pattern problem. You deal with the pattern, not the instance. “I’ve asked you not to talk about subjects like this in the pant, but you haven’t stopped. This makes me feel like you don’t respect my boundaries and it’s making it difficult for me to work with you. Why are you doing this to me?”.

You can escalate from there, and this might involve management involvement but at least you’ll have the clarity of having made the situation clear before it gets there.

Honestly though, unless the coworker is actually deranged, they’ll be mortified when they find out they are making you uncomfortable and they’ll stop right away.

I think that a good starting place to explain the concept to people would be to describe a Travesty Generator. I remember playing with one of those back in the 1980’s. If you fed it a snippet of Shakespeare, what it churned out sounded remarkably like Shakespeare, even if it created brand “new” words.

The results were goofy, but fun because it still almost made sense.

The most disappointing source text I ever put in was TS Eliot. The output was just about as much rubbish as the original text.

I looked and Python has the library support for the GPIO and to do background threading to poll pins. My preference would be to go with a JVM language like Kotlin, but then I’m a programmer. Python, from the little that I’ve mucked about with it is really just one step in complexity from scripting. Maybe even easier, because some things in shell scripts are super difficult to do.

Maybe then you need to move one stop up from scripting into something closer to actually programming. I’d be surprised if Python doesn’t have the library support on a Pi for dealing with both serial and GPIO I/O.

the end stop in external to the serial communication

Does this mean that you have some kind of other signals or pin-outs? If so, this is starting to sound like a great project for a Raspberry Pi, because the GPIO pin array can handle that.

Keep in mind that it has been decades since I last used Kermit, but I’m pretty sure the use case it was originally designed for was…

Connect to a serial port, which had a modem attached. Talk to the modem and get it to dial a number. Presumably, the remote end answered and the port attached to its modem would issue a login prompt. Negotiate the login and then issue a bunch of commands to change directories and then launch Kermit on the remote system. After that Kermit to Kermit communications took over until you terminated the session. Finally, log off the remote system and hang up the modem.

All of this stuff could be done via scripts. I seem to remember that it would actually wait for a response, and then parse the response in the script. I don’t remember ever doing polling loops.

If you’re on a *nix box of some type, it’s totally possible to open up a serial port for manual I/O even in something like a bash script. Even if you have to reverse telnet to a terminal server.

Kermit on top of FTP can work really well. Kermit has its own communication and transfer protocol, IIRC, but updates in the 1990’s allowed it to be used with TCP/IP and FTP. So you can write a script to log into a remote system, run some commands and then initiate a file transfer. The scripting allows you to wait for responses and act on them.

As a boomer (at the tail end, admittedly), I too have lived through all of these things. Plus the other thirty years of shit that happened before it.

The world threat that was the USSR and Mutually Assured Destruction. The Vietnam War, two Gulf Wars, and 9/11.

The “Troubles” in Ireland and IRA bombings in London. The Munich Olympics Massacre. The rise of global terrorism. The FLQ crisis. Kent State. Watergate.

Acid rain. Leaded gas and smog.

15%+ mortgage rates. The oil crisis. Wage and price controls. Multiple recessions. The Dot Com bubble.

Police raids on gay clubs. Racial slurs in everyday language. Massive gender inequality.

24" black and white TVs. It took a week to find out how your photos came out. Watching f@#$ing “Tiny Talent Time” on a Sunday afternoon because there wasn’t any else better on the other 5 channels (if that doesn’t traumatize you, nothing will).

You had to go to a library if you wanted to look something up in an encyclopedia.

Cars without seatbelts, crumple zones, anti-lock brakes, traction control or airbags.

F*CK me. “No experience”. Maybe just enough to know how much better things generally are today.

Kids always think that they know more than their parents…until they don’t.

I’m not sure a corvette has ever counted as “major” warship.

If I remember correctly, Objects were introduced in Turbo Pascal 5.5, not version 7.

“Row headers” seems wrong to me. Maybe “row labels”?

I never expected to see a compiler in this list, at least not in 2023.

Back in 1988 I realized how rubbish Microsoft was when I discovered Borland’s Turbo Pascal and Turbo C compilers. I’d previously used the MS compilers and they were multipass, multi-minutes to finish a compile. The Borland ones were single pass and FAST.

Back then, compile times could be huge, and everyone was publishing benchmarks on compiled program performance, which mattered on the hardware of the day. I never even think about that stuff these days.

I always feel this way about tailgaters. They don’t seem to realize that they have given up all the power to the person they are tailgating.