You want to paint a wall. The fastest way to start is to open the paint tin and start rolling out the color. Except that’s not the quickest way to paint a wall, as expert painters know. If you give a professional this job, they won’t touch the paint until the surface has been prepared.
This involves removing previous wall coverings, filling holes and divots in the wall, and carefully sanding to achieve a perfect surface. When you apply paint to a prepared wall, it goes on smoothly, it looks great when it dries, and you need fewer coats (we amateur painters tend to use additional coats in attempts to disguise all the problems we left when we didn’t prepare).
The preparation checklist:
- Fill holes and cracks
- Sand the walls
- Clean the walls
- Let the walls dry
- Apply paint
You may need to add additional tasks to the list, such as removing mildew or priming the surface, if these are required in your expert judgment. This is the model professional decorators have refined over decades. It’s not glamorous, but it works.
So far, so good.
Enter the robot
No matter what you do for a living, someone wants you to do more of it in less time. In the software industry, we have scrummy marketing to blame for the overwhelming presence of demanding “twice the work in half the time.”
So what happens when we decide we want to paint faster? Someone buys a great big paint-spraying robot.
The paint-spraying robot is 10x faster than a human at painting. It can cover 100 square meters per hour, while a human can only do 10 square meters an hour. It completes projects 60% faster, and it can run 24/7, unlike those pesky humans who want to see their family and sleep. Of course, you need to input floor plans and designate non-paintable areas. Additionally, there’s a 20-minute setup time, as well as a 30-minute post-painting clean cycle.
Side panel: There are clues in the claims for the robot that tell us things are more complicated than they first appear. The robot is 10x faster, but projects complete only 2–3x faster. Something outside of blasting paint onto the wall is at play here. I’ve worked in enough organizations who purchase based on the 10x claim and then tripped and fell down the stairs of their own excitement.
Oh, and there’s one more thing. It doesn’t prepare your walls.
If you’ve ever painted walls without preparing them, you’re familiar with the kinds of problems it causes. The finish doesn’t look good, it’s not long-lasting, and your modern lighting turns the wall into a three-dimensional topology map of past picture hook holes. Over time an odd dark patch emerges. A reminder of the time little Lily missed her mouth with the Calpol and made an impromptu purple Rorschach test across the wall.
Painting, it turns out, is a complex process. We may long for a reality where painting is easy, but we live in one where it’s not.
Rediscovering the wheel, one bruise at a time
And that’s why the robot-first painting team is currently providing a fountain of incredible insights as they try to maximize their return on investment.
They’re discovering that asking people what color they want to paint their walls results in happier customers. An idea about setting windows to be non-paintable is emerging. Some bright spark has worked out that filling cracks before painting achieves a better end result.
Of course, they haven’t discovered everything on the simple checklist used by every professional decorator. It will take time for them to work it all out. It took professionals time to work it out in the first place, and these pioneers have decided to start from scratch instead of building on existing knowledge.
Eventually, they’ll have a pre-robot preparation checklist that looks something like the one we had in the first place:
- Fill holes and cracks
- Sand the walls
- Clean the walls
- Let the walls dry
- Apply paint
We’ve seen this movie before
Of course, this isn’t about painting at all. It’s about software delivery.
We spent decades refining the best way to build software. It’s called Continuous Delivery. We have even expanded this into the DevOps model, which combines practices and capabilities that work well with Continuous Delivery, such as generative workplace culture, lean product management, and transformational leadership.
We literally have diagrams that show how all these things come together to improve software delivery. That’s right, “software delivery”. Not feature development time. Not coding speed. The whole darn thing.
And right now, I’m witnessing the most surreal déjà vu of my career.
Many people using AI are discovering Continuous Delivery practices through bruising experiences. The barrage of social posts from AI-first developers who are finding out from scratch why version control is a good idea, or why they ought to work in small batches with changes frequently integrated with the main branch, or why their builds shouldn’t take an hour.
It’s funny, while also being not at all funny.
In the 2000s, as I was first finding my way through Agile, Extreme Programming, and Lean, we drew on books and articles to inform our continuous improvement process. I worked on a team that ditched Scrum and developed a method that made sense for our work. We rapidly went from 6-month cycles to having always-shippable code, with a new version deploying every 3 hours or so.
Therefore, there’s a whole generation of lean/agile software developers for whom AI doesn’t provide a significant boost. To us, AI is just another tool, like auto-complete or a compiler. Helpful; not transformational.
We refined the elements of high-performance software delivery through numerous iterations and adjustments.
The paint dries on this one
Continuous Delivery remains the best-known way to deliver software.
A team using only Continuous Delivery will beat a team using only AI, because any benefit you get from AI will be lost to the first bottleneck it encounters on its way to production. Teams that start with Continuous Delivery will be more successful with AI, because they are already more successful than other teams. They have fast builds, automated deployment pipelines, and solid technical practices to enable the fast flow of work.
Essentially, AI has enabled low-performing development teams to experience some of the speed that comes with Continuous Delivery, but without the enabling practices. They’re getting paint on the wall, but they skipped all the prep work. So far, this hasn’t led them back to Continuous Delivery, but if they want to succeed, that’s where they need to start.
If you’re looking at seriously improving your productivity, it’s likely the answers that are proving so elusive with AI have been waiting for us all along in Continuous Delivery.
You can buy the robot if you want. Just don’t be surprised to find your windows painted over and your wall covered in lumps, bumps, and cat-shaped silhouettes.
Top comments (2)
I genuinly liked the analogy. thinking also in terms of refining software requirements in an architecture brainstorming phase, and only afterward starting with the actual programming, is the same as preparing the wall then painting. Skipping architecture to just code any idea that may look like the solution may seem faster, but this imho comes at the cost of entering some hamster wheel of bug-fixing and regressions.
This is something that Agile folks get irked about. They said not to do "big design up front", they never said "do no design up front". There was just a stronger demand for a reason to stop doing planning and design than people realized :)