A career across the full breadth of IT.

“Can it work more like Excel?”

An innocent question that can make an engineering team stare quietly into the distance.

If you build software for people who spend much of their day in spreadsheets, you’ve probably heard it.

“Web applications aren’t Excel” is technically true. It also does very little to help someone finish their work.

People bring habits from tools they know. Often, those habits tell us something useful about what they’re trying to accomplish.

The tricky part is the cost. A familiar interaction that feels instant in a spreadsheet can require considerably more work against a large shared dataset.

So, how much extra waiting is that convenience worth?

As engineers, we tend to care about keeping the application fast. Users care about getting their work done. Those goals usually align, but sometimes a slower interaction saves someone several manual steps.

One way to approach it:

• Understand the task behind the request
• Measure the performance cost
• Make the trade-off clear
• Offer a choice where it makes sense

We still need to exercise engineering judgment. But “that will be slower” is only part of the answer. Slower for the application, or slower for the person doing the work?

#CTOThoughts

AI-generated software has changed what “unfinished” looks like.

Human-built systems usually show their missing pieces: the button does nothing, the endpoint is absent, the report is still an optimistic rectangle.

AI can produce something polished, tested, and demo-ready while hiding a much deeper gap. It looks 90% complete until the first real user discovers that the remaining 10% includes the foundations.

That changes the engineering leader’s job. Progress can no longer be judged mainly by visible features or passing tests. We need deliberate adversarial checks, real workflows, and engineers who understand enough of the system to distrust a convincing demo.

How are your teams distinguishing software that looks finished from software that can safely evolve?

Source: The Chasm: The Shape of Unfinished AI Codebases — https://jimmyhmiller.com/shape-of-unfinished-ai-codebases

#CTOThoughts #AIEngineering

Building pricing software: “Make it flexible enough for every pricing model and data structure - but simple enough to use without a manual”.

Configurable software creates an interesting paradox.

It is usually harder for vendors to build, test and maintain. Every additional rule, dependency and exception creates more possible combinations - and more opportunities for something to break.

But pricing is rarely simple

Different markets, customer segments, contracts, currencies and approval levels all introduce legitimate complexity.

So, what happens when pricing software is not configurable enough?

The complexity does not disappear. It moves somewhere else:

• Pricing rules and up in spreadsheets
• Exceptions are managed through email and Slack
• Every change becomes an engineering request
• Critical knowledge lives in the heads of a few people

The goal should no be to eliminate complexity. It should be to put it in a system twhere it can be tested, governed and understood.

Configurable software is technically harder to build, but usually better for pricing teams.

Because if your pricing platform cannot represent how your business actually prices … is it simplifying the work, or simply hiding it?

hashtag#CTOThoughts hashtag#PricingTechnology