I wrote a post some time ago about No Hashtags (hashtags on e.g. Twitter which use the #No… prefix). My tweets occasionally mention various #No… hashtags, including #NoEstimates, #NoTesting and #NoSoftware.
I’m thinking it’s about time I delved just a little into the #NoSoftware hashtag. Like most of my posts on Think Different, this one will be brief. #NoSoftware is a deep subject, upon which I could write a whole book, had I but the inclination (or demand).
To whet your appetite, and illustrate the possibilities of #NoSoftware, we need look no further than the story of Portsmouth City Council housing repairs, where an existing, expensive and inflexible IT system was switched off, replaced with manual controls, and only later some limited software support reintroduced, once the needs of all the Folks That Mattered had been fully understood and catered to.
Let’s start with the payback of #NoSoftware.
As Steve Jobs wrote:
“The way you get programmer productivity is not by increasing the lines of code per programmer per day. That doesn’t work. The way you get programmer productivity is by eliminating lines of code you have to write. The line of code that’s the fastest to write, that never breaks, that doesn’t need maintenance, is the line you never had to write.”
~ Steve Jobs
A pretty clear alignment with #NoSoftware (yes, I’m coming to that presently) wouldn’t you say?
Let’s just dissect that statement:
Eliminating lines of code we have to write
We’re not talking about writing denser code – cramming more functionality into fewer lines. Fewer lines of code means we’re done quicker, having spent less time, effort and money on the writing of code. That’s a saving in and of itself.
So the lines of code we don’t write means we don’t have to worry about their quality (no matter whether you use defect prevention or testing as your go-to strategy in that arena). More time, effort and money saved.
Doesn’t need maintenance
By maintenance here, I’m thinking about changes to the code occasioned by the changing needs over time of the Folks That Matter, or changes necessitated by changing technical environments. I’m not dwelling on remediation efforts (bug fixes to production code).
But the payback of #NoSoftware doesn’t stop with the above aspects. In the bigger picture, it’s not just about writing fewer lines of code. It’s about eschewing software-based solutions more or less entirely in favour of considering the alternatives. More payback includes:
It’s an old saw that “folks don’t want an 8mm drill, they want an 8mm hole”. Similarly, folks almost universally don’t want software, they’re looking to have their needs met. And software for many of these folks has too many negative impacts to be their preferred option. Software is generally written to save (suppliers) costs, not to improve customers’ satisfaction. Most people hugely prefer to interact with other human beings, rather than a computer controlled by – generally lame and inflexible – software.
Opening the Door to Changing Thinking
Software systems as generally conceived, ordered and delivered institutionalise – or “lock-in” – the existing collective mindset. Once installed and paid for, the “sunk cost” fallacy undermines any possibility of changing the existing set of assumptions and beliefs about how the works works. In the vast majority of cases the software system locks the organisation even more tightly into its existing Command & Control (a.k.a. Analytic Mindset) ways of working.
#NoSoftware – Definition
When I use the #NoSoftware hashtag, I’m inviting folks to think again about what, often, are near-autonomic responses. In this case, the System One (cf Kahneman) response – “fast, instinctive, emotional, stereotypical, unconscious and automatic” – when faced with some needs of some Folks that Matter, to satisfy those needs with a software-based solution.
I guess some folks assume that I’m advocating zero software. A kind of Luddites’ heaven. This is not my position. In using the #NoSoftware hashtag, I’m basically saying
“Under some circumstances, maybe there are other, more effective means to meet folks’ needs than the default assumption/strategy that we have to do so via software”.
“How about we think about, talk about, and consider those various circumstances, and means?”
In this way, the #NoSoftware hashtag is a metaphor for
“Would you be willing to think again, and maybe join the search for more effective, relevant or alternative means of meeting the needs in question?”
Some years past, I was working with a company that offered a software product to the corporate market. The product had been in the market for some years, and it was clear that one of the blockers to market penetration was the complexity of the problem and the challenges corporate customers faced in dealing with that complexity. The company chose to build more and more software into their product to help their customers handle the complexity. No one ever discussed the options of offering a consulting service and/or a managed service, using human expertise, to replace or augment their software product. Consequences were, customers remained challenged, and the company’s revenues suffered.
As Upton Sinclair’s Dictum tells us:
“It is difficult to get a man to understand something when his salary depends on his not understanding it.”
~ Upton Sinclair
How much more difficult, then, when it’s the revenues of a whole industry we’re calling into question. If the software industry changed tack and stopped writing software, what then? Financial ruin? World collapse?
There’s a multitude of smart people who currently waste much of their time – and lives – writing and delivering solutions to folks’ needs in the form of software. I suggest that to have this multitude refocus and retrain themselves to consider, and deliver, other forms of solution – solutions with less or no software – would make the world a better place for all the Folks that Matter. And “better”, as far as customers are concerned, would mean increased demand and more revenues for savvy suppliers.
Like many of my invitations, I find #NoSoftware has few people willing to consider it as an alternative strategy to the status quo of just getting on with writing (more and more) software. I guess this signifies the general learned helplessness, and lack of engagement, autonomy and mastery, we find in most workplaces and employees today. So be it.
Why Doctors Hate Their Computers – Atul Gawande
Forget your people – real leaders act on the system ~ John Seddon
Dangerous Enthusiasms: E-government, Computer Failure and Information Systems Development ~ Robin Gauld, Shaun Goldfinch
I love this and it’s much easier to get my head round after an initial read than #noprojects was (although now I’m over the PM mindset and doing more operations work, I get that now).
What I’d really like to see is the metaphor extended to the #nowork concept. At a guess 90% of my current workload is waste – largely a result of ERP software which doesn’t work because it can’t handle exceptions due to local country regulations. And since 99% of countries have exceptional needs ….
When I was a student librarian back in the 1970s, and my contact with IT was running statistical packages on a timeshared mainframe on another continent, with input via 80-column punched cards, we were taught some Systems Analysis. And one of the key things we were taught was to find the optimum solution to any problem, and that solution may not be the most complex one.
Isaac Asimov noticed this in one of his robot stories; at one point, a character observes “These days, anyone wanting a doorstop is buying a robot with a big foot.”
And only a couple of years ago, a systems architect declared me to be “a Force of Nature” because I’d done him a clerical job in 40 minutes by cutting and pasting raw data from one app to another which all his developers had said they didn’t have time to do because their instinct was to code up a solution that would have taken them three days to create (when they had the time), even though their solution would have taken perhaps 90 seconds to run.
Pingback: Five Blogs – 24 July 2019 – 5blogs
Pingback: A Definition of #NoSoftware – CodingNova
Pingback: New PM Articles for the Week of July 22 – 28 | The Practicing IT Project Manager
I think that Agile, and Extreme Programming in particular, has always been #NoSoftware. Evidence:
“What software do you use to keep track of User Stories?”
“We write them on 3×5 cards.”
“But how do you keep track of all the details you’ll need to know in order to implement them?”
“We discuss them with the customer right before implementing the story.”
“But what if you lose a card or forget something?”
“If it’s important, someone will remember, eventually. And then we’ll do it.”
“What software do you use to track and manage your defects?”
“We don’t ‘track and manage’ defects. We fix them.”
“But how do you triage and prioritize all your defects?”
“We don’t do that. We just fix them. We have so few of them that when we find one, we just fix it.”
“How do you keep ‘management dashboards’ up-to-date?”
“We write important stuff on large pieces of paper on the walls. If anyone wants to know, they can just stop by, and any team member will step up and explain it to them.”
But also, with TDD — automated regression testing, we do #MoreSoftware than most other people too: Instead of spending half our time manually testing things, we have the computer do it. We’ve got lots of spare computer power to use, and we’re good at writing software. So having the computer do tedious repetitive things makes a lot of sense.
Pingback: Five Reasons Why Agile Coaching is Bullshit - Softwaretestingtools.com