Listen to this article:
One of my favorite parts about doing this blog is the regular opportunity to explore ideas. It is called the Reservoir of Ideas after all. Some have found their way into articles. Others were either too short or off-topic, or just needed more development than I wanted to invest. Sort of like the nine seemingly half-finished songs the Beatles mashed together into the classic Abbey Road medley. So, in that spirit, here is today’s closet-cleaning idea assortment.
Your Assignment: Be Bored
For the past year I taught introductory computer science to mostly college freshmen and mostly non-majors. While I’ve done innumerable trainings, conference presentations, and guest lectures, it had been more than thirty years since I had my own college class. I taught the first-year sequence to majors for four years in graduate school: three years as a teaching assistant and one as a full-time lecturer. It probably doesn’t come as a surprise to hear that in many ways students in the 1990s and the 2020s are similar, and in many ways they are very different. But that’s a subject for another time. As the last session before Spring Break was winding down, I gave the class an assignment; optional, but for extra credit:
Set aside a half hour and be bored.
Put down the phone. Turn off the computer and the TV. Take out the earbuds. Go outside if you can. Look up. Look around. Sit. Or walk, that’s OK, too. Call it meditation if you want.
Let your mind breathe.
If anybody asks why you’re just sitting there staring off into space, I told them to say that it’s a class assignment. Because it was.
The feedback I got back from the couple students who actually did the assignment was that it was hard at first, and the half hour passed very, very slowly. Some people even sleep with the TV or radio on (not me) and are on the phone or computer the rest of the day. That’s 24 hours of input. Some withdrawal was expected. But after a couple days one person told me that she looked forward to her walks. They say that if you can reach one …
Now, you try it.
Chicken Lunches
I frequently use “chicken lunches” in my blog, lectures, presentations, and the Rock Bottom Data Feed podcast as a metaphor for project success. Sometimes seriously. Oftentimes sarcastically.
For example, from the May 6, 2026 article, “Data Rabbits“:
With apologies to Rush, choosing to not manage data is itself a strategic choice. It’s understandable. It’s self-reinforcing. And for a while the strategy appears to be successful. Results are delivered faster. Chicken lunches all around!! The siren song is heard by leadership in other areas and they want to complete their analyses and deploy their applications just as fast. So, they imitate the pattern, creating their own data feeds and their own repositories. Now I have numbers I trust and I got them fast. More chicken lunches!!
Someone recently asked why, and if there’s one person wondering, there’s probably two.
The reason is that at the conclusion of a major project or in recognition of some success, management often takes the project team out to a nice restaurant, private dining room, or country club for lunch.
The main dish is almost always chicken.
I first heard the expression from a DBA friend (who also played minor league baseball) shortly after I started working at a major transportation and logistics company. We would be in a meeting and the manager would be introducing an interesting new project. He’d lean over and whisper, “Smells like chicken.”
Unmanaged Data and Entropy
I’m going to get a little Physics on you for a minute, but the metaphor is apt. A company’s data environment is a physical system, and like any physical system it necessarily drifts toward entropy (i.e. disorder). Maintaining order requires work. Ongoing work. Work both in the thermodynamics sense and the somebody has to do something sense.
Data Quality takes effort. Living with poor data quality takes more effort.
I guess if everybody’s OK with wrong answers, it’s OK. I once had an executive tell me that he didn’t have a problem with numbers that weren’t exactly right as long as they were directionally correct. How would we know? It amazes me sometimes. When the grocery store clerk forgets to apply a fifty cent coupon or the customer buys the wrong size item and doesn’t get the discount they will argue and plead and stand in line at customer service for ten minutes to get that fifty cents. Spending time to ensure that corporate data is correct? Don’t worry about it.
But consider the fire drill when something comes up later. Most, if not all of the team members have moved on to other projects. They now have to be recalled to resolve a problem that should never have happened. Probably need to spend some time coming back up to speed. Now, the new project is delayed. How many of those working on the problem weren’t even proximate to its development in the first place.
What about other analyses that used that data? Do they need to be revisited? What a mess! It’s often said, to the point of triteness, but it’s tragically true: there are never enough resources to do it right the first time but there always seem to be resources to repair the consequences later.
Leapfrogging at the Speed of Technology
The pace of technology change, especially AI, reminds me of time dilation approaching the speed of light. I feel like I’m running faster and faster, but as soon as I am up to speed on one thing, something else has surpassed it. It goes faster and I go (relatively) slower.
In situations like that, I prefer the leapfrog approach.
You can spend all your time evaluating better and better tools. There will always be a better tool. You can spend all your time migrating from one platform to another. I’ve talked before (here and here) about the executive allure, high cost, and questionable value of these projects.
The fact of the matter is that I don’t need state-of-the-art, cutting-edge technology for everything all the time. I need to use the technology that solves the problem that I have today and that I anticipate tomorrow. And I don’t mean tomorrow as in three years from now. I mean tomorrow as in like the next quarter. Find something and get value from it. Use it for as long as you can. At some point the value associated with making a change will justify the cost of the migration. Only then does it make sense.
Flying Cars
When I was growing up my mom gave me a book that she had growing up about the history of flight. The last page contained a glimpse into a future: a family having a picnic with their flying car nearby. It was a typical 50’s design with fins and bench seats and everything. (It probably didn’t have seat belts.) It’s been more than seventy years and while a few prototypes have been built, we’re still not there yet. I’m not surprised, though. People have enough trouble maneuvering in two dimensions. Can you imagine what would happen if a third was added? You couldn’t just pull off to the side of the road after a fender-bender.
I believe that fully autonomous cars are a prerequisite for flying cars.
It seems likely that people won’t be allowed to “drive” flying cars, at least not outside of certain designated spaces. This means that self-driving technology on the ground must be perfected first. Once that happens, though, I do believe that flying cars will follow relatively shortly thereafter.
Minimum Viable Product (Again)
I don’t make a secret of my dislike for the term Minimum Viable Product (MVP). If you only recently started reading this blog, or haven’t attended one of my presentations or classes where I’ve mentioned it, there’s a whole section about it in my book 6 Secrets for Delivering Impossible Projects.
I frequently hear Skateboard – Bicycle – Car as an analogy for minimum viable product. Supposedly, it illustrates how an MVP evolves into a finished product. To me, it just pours salt into the wound.
The reasoning usually goes like this: if all you need is a skateboard to get from Point A to Point B, then a skateboard is sufficient. Don’t build more than you need. That’s fair.
But what happens when a skateboard isn’t enough? What is it about building a skateboard that provides the foundational knowledge required to build a bicycle? Very little, really, except how wheels work. The bicycle is not an evolutionary improvement to the skateboard. It is an entirely different product. It’s the same leap from bicycle to car.
A better analogy would be “Skateboard – Soap Box Derby Racer – Motorized Go-Kart.” Each step intentionally builds on the previous one. The Soap Box Derby racer extends the axle length, adds a shell around the seated driver, and introduces steering and braking. The go-kart builds upon that foundation by adding a motor, more sophisticated controls, and a stronger frame. Each iteration preserves what was learned and extends the design.
My favorite analogy comes from NASA.
The Mercury, Gemini, and Apollo programs were deliberate stepping stones toward a single objective: landing humans on the moon. Each mission built upon the previous ones, incrementally adding knowledge and expertise and experience. The critical point is that each mission wasn’t simply “good enough for now.” It was designed to answer specific questions and reduce the risks of the next phase. Knowledge, capabilities, and experience accumulated.
Instead of asking “What is the minimum we can get away with building?” we should ask “What is the next increment that teaches us something essential while moving us closer to the final outcome?”
Those are two very different philosophies.
One optimizes for delivering less.
The other optimizes for learning how to deliver more.
Her Majesty’s a pretty nice girl.
