AI as a mental crutch

(Feature image created with DALL-E, providing feedback on my image proompting skills)

Every couple of years I find myself building a new Linux virtual machine baseline for some project. Even though I’ve documented the process thoroughly the last few times there is always some quirk that has me starting mostly from scratch each time. This time I started off with setting the home page in Firefox to perplexity.ai and using it to find all of those mundane commands I forget three weeks after going back to Windows for my day to day work.

This time I hit a snag pretty early in that I was getting an error that made no sense to me (the specifics of which aren’t relevant to this train of thought). Perplexed, I asked Perplexity “wtf?” in my best prompt formatting (which, admittedly, is a WIP) and it gave me a few things to try. Some (not all) of them made perfect sense and I gave them a try. They failed.

I compared everything I was looking at against a similar appliance and didn’t see any obvious differences. I tried variations of prompts with Perplexity to get a more directly relevant response, which either resulted in what had already been suggested or even less relevant responses (I did mention my prompting skills need, work, right?).

I then tried ChatGPT, which gave me the same answers that differed only in their verbosity and longer pauses between response blocks.

Finally, I ran the same search I started with in Google, which returned the usual multiple links from our old friend Stack Overflow. I did like I did before using GPT backed by LLMs and narrowed the time frame down to the last year to eliminate answers 10 years out of date (and sometimes links to my own past explanations that are equally out of date) and found a summary that looked closer to my actual problem than the bulk of the answers (which were clearly the source of the responses from both GPT sources I had tried earlier).

And there was my answer. Not just to this one problem, but to the kind of sloppy approach I had fallen into using AI. The thread started with an exact description of the same problem, with lots of the same answers that had been of no help. And then the original poster replied to his own thread with the solution (a habit of frequent Stack Overflow contributors I have always admired and sometimes remember to emulate), along with how he wound up in the situation. Again, the specific error isn’t relevant to this tale, but the source is using the the first search result that seems to answer the question rather than reading it all the way through and seeing the subtle difference between what was needed and what was provided.

No AI response will tell you about the screw ups that caused the problem (are they embarrassed for their human creators or just don’t think it’s relevant?) and the path to realizing the mistake and then recovering (and learning). But real people will and that is how we learn from each other.

So having copilot proof your work is great and using promoting to get a start on something you’re stuck on is a great productivity boost. But relying solely on the technology to do all the work is how we wind up forgetting how to think and learn and build better technology to give us time to think and learn. In short, don’t trade the mental crutch for a creative wheelchair.

If you found this interesting, please share.

© Scott S. Nelson

The Real Problem with Hybrid Agile

Featured image by Gratisography: https://www.pexels.com/photo/man-person-street-shoes-2882/

Before SAFe®, most organizations would do “our brand of agile”. IMO, SAFe® takes the most common elements of a plethora of hybrid agile approaches and codifies them in to a “standard” (imagine air quotes). My comments today are not about SAFe® but hybrid agile in general.

The common denominator I see across hybrid agile approaches is that they include the notion of some specific deliverables by a specific date. For the agile purist this isn’t agile because that notion is very not agile. Hats off to the purists that get to work that way, and they have already stopped reading by now unless they share the same mental state of people that slow down to look at a bad accident on the freeway (which I feel is not agile, but I’m no purist, so I couldn’t say for sure).

So, having target dates for a collection of stories isn’t entirely a bad thing, in that there are many organizations that have a legal obligation to appear as if they can reliably predict the future. These target days are where the problems start. And I will admin here that the title of this post is a lie, it is multiple problems, but I wanted to rope in those who really think that there is one thing wrong because I think they may get the most out of this particular rant.

So, first problem (position being arbitrary, I don’t have any stats about which problem occurs most) is that if the target is missed then there will be some people that point at the agile side of the hybrid approach as the blame. It could be, but it is much more likely that it is the behaviors that result for hybrid approaches, such as skipping documentation entirely, which results in longer ramp up time and lack of the DRY design pattern, because if you don’t know what’s been done how would you know if you were doing it again?

The next problem (purposely avoiding making it the  second problem to avoid people thinking this is a non-arbitrary sequence…beyond a order that helps to communicate the concepts) is that when the targets are missed the people that are supposed to know what the future looks like look bad, so they get mad at the people who are trying to hit the target. Most people feel bad when people are mad at them (except people with either experience in such things, certain psychological disorders, or a hybrid of the two).  No one likes to feel bad (except people with different psychological disorders) so they try to figure out how to prevent that in the future.  And we have tons of action-comedies to suggest a way to do this: Lower your expectations…lower…lower…that’s it. So people stop missing their targets and Wall Street analysts think the bosses of these people are great prognosticators where what they have actually done is taught their teams to be great procrastinators.

And the last problem I will point at before running for my life from hip hybrid folks who will want blood and purists that stuck around and are still looking for blood is that the people who try to make it happen still miss the mark because they focus on the wrong targets. The long-term goals have this nice, big, shiny definition,  where agile aims to complete one small, solid solution. The magic comes from being able to look at the big shiny and build a small solid that is good-enough-for-now, and still in the direction of the big shiny. One definition of magic is “some can and some don’t know how”, and in the case of this balancing different paths to perfection, some will focus everything on the small solid piece and forget to thing about whether it will fit into the big shiny vision. Or, they will be so enamored with the big shiny vision that everything they do in the span of a sprint is inadequate for the pieces that are solid, making the next sprint slower because they are still waiting on that piece that would let them move faster. Of course, magic is hard, and expecting everyone to produce it is destined for disappointment, which is why the teams that just lower their expectations are more “successful” (Dr Evil-level air quotes there).

So, at the end of the day, or at least the end of this post, the perception of success is easiest to meet if you succeed at level far below your potential. You can stress out everyone and sometimes hit the target. Or you can start forgiving your teams for their imperfections, cheer them for their successes, and teach them to learn from each other to be more successful every quarter. The problem with that last is that I will have to write another post to find more problems with hybrid until they are all resolved.

If you found this interesting, please share.

© Scott S. Nelson

Virtual Team File Management

(Feature Image photo by Brett Sayles: https://www.pexels.com/photo/stack-of-paper-rolls-in-shelf-3720483/)

The longer version of my contribution to a LinkedIn experts article.

There are so many options and variables that any single recommendation will only be helpful to a slice of the organizations who may be thinking about this.

From a meta perspective, minimizing the number of tools required to get work done while remaining efficient and effective is important to fostering collaboration. The days of avoiding vendor lock-in at all costs faded with the growth of SaaS and other cloud-based options. Choosing a file management option that is packaged with, or cleanly integrates with, tools that are used by the entire team should be a primary consideration. Reducing the number of logins required throughout the day helps keep the team efficient, and an option that can be directly linked to requirements, communications, and quality reviews will help ensure that they are linked and maintained.

Another requirement that should be top of mind is versioning. The ability to restore older versions and compare between versions may not always be needed during any given effort, but it will be sorely missed if it is needed.

As a general recommendation, implementing some redundant and external back up should also be considered. Cloud content should be regularly backed up to on-premise or alternative cloud in the same manner where on-premise solutions should be periodically backed up somewhere off site and secure.

If you found this interesting, please share.

© Scott S. Nelson
Unlocking Salesforce ROI covers

Unlocking Salesforce ROI

I co-authored this eBook for Logic20/20 this year.

Get your copy at https://logic2020.com/insight/salesforce-center-of-excellence-white-paper-download/ for the price of your email address.

If you found this interesting, please share.

© Scott S. Nelson

Move from threads to meetings

(Photo by Johannes Plenio: https://www.pexels.com/photo/spider-web-with-drops-of-water-1477835/)

I’ve always tried to have some basic guidelines around communications to keep myself from straying from the purpose of the conversation. I’ve had a long-standing guideline for how long to wait for someone that is late to a meeting: 3 minutes for non-critical participants; 5 minutes for colleagues who should know better; 10 minutes for people in senior roles that have too many meetings; 15 minutes for executives and customers. After 15 minutes I write it off as a break in an otherwise hectic day and move on to other tasks.

Recently there was a long-running thread of comments in a Jira story between two colleagues that occurred while I was on PTO. Catching up on things, I ran across it and, as someone outside the conversation, identified that the length of the discussion was because there were different core understandings of the story that neither was aware the other had. Because it had gone on so long, it took longer to come to consensus in the meetings that followed that comment thread.

This is not the first time I have run across such diverging threads, and I am sure you have seen as many or more. I once worked with a very good Project Manager who had a rule that if the thread went more the two responses it was time for a phone call or meeting. As a developer-turned-architect, most of my work is with people that would rather go to the dentist than a meeting. As senior director, I know that both are annoying when unnecessary and you always feel better afterwards when useful (though not always immediately).

I’m will probably revise these in the future, but for now, here is the guideline am adopting and recommending around written threads (IMs, DMs, texts, or comment sections):

One message is a question
Two messages is a conversation
Three messages is an asynchronous meeting
Four messages probably needs a meeting to complete

For the sake of this discussion, let’s consider a meeting of any type of verbal exchange over written, i.e., treating phone, video, and in-person equally (because otherwise we are off on a different topic, and I do that easily enough without help).

Like any guideline, these are not absolutes. For a silly-yet-accurate example, consider “can we talk?” as the first message. In general, that should go straight to meeting. But sometimes the recipient is busy (maybe even in another conversation) and some discussion is required to conclude a time an channel. Another example is when assisting someone with a task where the understand the basics and need help with some advanced or nuanced aspects. Such a thread could go on for dozens of exchanges and be the right way to communicate asynchronously as both parties work on other things in between. In the same context but a different circumstance the thread may be inefficient, and meeting should be called after the first question. So, no absolutes, just some guidelines to think about when you find yourself in an extended written exchange online.

What’s your approach? Yes, I’m now encouraging a thread that is longer than four messages and no meeting 🙂

If you found this interesting, please share.

© Scott S. Nelson