A personal blog transitioning into an exploration of the intersection of design, technology and ethics
This year, during my family holiday, I discovered how Hertz – and many other car hire companies – have crafted a process involving dark patterns to trick stressed travellers into paying far more than necessary for their car hire.
I’ve used Hertz several times over the years, particularly in the 2000s, so I expected good service, a decent car, and straightforward business.
Continue reading “Hertz doubled the cost of my car rental. Here’s their process design trick.”
I lived in a range of places as a kid, partly because my father was a bit of an itinerant who didn’t know what he wanted in life, other than that I mustn’t live with my mother. Go figure.
Eventually I got to settle down with my grandmother, but in the process I learned a lot about life as a child in different places. Where I felt safe and where I did not.
I did not feel safe in large council estates surrounding cities. I did feel safe in a caravan park. I did not feel safe in a city centre. I did feel safe in a built up part of a large city, living in an apartment block.
Continue reading “Taller buildings let us design better towns”
You know that friend, the one who always promises to help you move flat, or help you fix your mower, but then doesn’t turn up? Yes. Or the guy who goes on a date and pays for the meal and somehow that comes with access to your body? Or the airline that makes you think you have to pay for a seat upgrade in order to take any baggage on board when actually you don’t?
The first two are obvious red flags. We all know people like this, and once we’re done excusing their behaviour we tend to move on. They’re often charming people at first. They have to be. They keep needing new friends and new partners, so they get really good at the introductory gab. But as I always say, the only perfect people in this world are people you don’t know very well yet.
Continue reading “Don’t design in customer traps on your systems”
This blog post has now been re-arranged with the manifesto at the top, and the reasoning that led up to it beneath. Because, after all, placing the important content six or seven hundred words in is hardly being pure, is it?
Content First. All articles, images, and graphics must be there to serve a purpose. Superficial or filler material is forbidden.
I hope you haven’t missed the big AI revolution going on right now? No? Yes? YES? You have no idea about it? Where do you live? On Mars? Ah OK, you were kidding. AI is being talked about everywhere, new devices like the Humane AI Pin or the Rabbit R1 are very much about it, and everyone involved is scrabbling around like mad for venture capital to fund their incredible ideas.
Having access to these language models is immense, right? We can sit down, whip out our AI, and enjoy a better than life experience. We can ask it questions and often it can come up with remarkably lucid explains. It seems intelligent. Here’s a conversation I’ve just had with ChatGPT’s latest model, after I asked it to settle into a British conversational style:
In the world of transgender rights, the battle for the bathroom has reached fever pitch, especially in the USA. Now, I’m not here to referee in this brawl – because on one side of the debate you have the ‘TERFs”, and on the other, the trans rights activists sometimes labelled “handmaidens”. Both are terms about as socially acceptable as weeing all over the toilet seat, and on the extreme fringes of both you find calls for violence. It seems every modern campaign group needs its villains and its sycophantic followers.
Continue reading “Design Dilemmas: When bathrooms become battlegrounds”
In the past, this website was sort of my place to keep family and friends in touch. I first set it up in 2005, just before going away to Peru on travels. It was a great. Facebook had been invented but wasn’t generally available or popular yet, other platforms weren’t well thought through or scattered, Twitter didn’t exist. But installing WordPress on my cheap Yahoo web hosting turned out to be one of the easiest ways to publish content and share it with the world.
Being very old (or at least, that’s how I feel being in tech!) means that after coming up to nearly forty years in technology, I’ve seen some changes.
My first computer at home, that I owned, that I could truly call my own, was a Dragon 32. It was a small, 32KB computer using the rather lovely little 6809 processor. This CPU ran at 2MHz and the system as a whole allowed me to learn a heck of a lot about computer science as a geeky teenager who was busy ignoring sports.
Continue reading “The astonishing power of modern computing”
I came across this chart recently and it gave me pause for thought as someone whose life work is designed to improve productivity. It shows that from 2008, although we know technologies have been growing in power, productivity growth suddenly dropped away from the trendline following the global financial crisis. Why?
This is where I fall back on an old story as a developer trying to make things more efficient. I worked with my colleagues to bring a client company the equivalent of about ten hours a day of labour saving due to using a well structured database for better data integrity over their previous ‘loose’ system. As they expanded, each branch would save at least an hour of time, and they were no longer capacity bound at each branch where more customers would linearly increase administrative work in a difficult recruiting environment. This would provide a return on investment (ROI) of less than a year.
It worked exceptionally well and the person we’d worked with said their staff were even worried redundancies might be on the way! This was never going to be the case in a growing company, because there’s an infinite amount of work to do.
All was good.
Then for some reason, our contact’s role was diminished and they eventually left the company. And the knowledge of the improvement left as well. The board’s innate distrust of anyone and their perception of us as no more than a cost base resulted in a great difficulty for us to help them without dramatically increasing costs by gold-plating every spec and decision.
This left the client unable to gain for advantage by exploiting our skills. It was difficult for us to see, and we could do little for them other to look for cost savings when, in reality, they needed to implement cost savings by using us more. Instead they opted for a recruitment based strategy to feed their growth and we parted ways as they shifted the system to a maintenance partner.
In all my thirty years of development experience I’ve seen this again and again. Instead of sticking with a solid set of developers who have learned your business details, chop and change to save money. Treat developers as a cost base and you lose so much knowledge that you’ll fail to gain productivity nearly as quickly as you could treating it as a partnership.
I don’t feel this is unique. I see lots of projects following an arc of big development then a cost reduction period which ends up losing the momentum of ongoing improvement.
A strategy I now suggest when selling is to spend 60% of what you thought of on your project in year 1, then 40% in year two, 30% in year three, and then 20% a year throughout the product lifecycle. Software isn’t like building a bridge where things stabilise then stay them same for thirty years, sadly.
Fundamentally, I think corporate culture around custom software became both cautious and speculative following the global financial crash of 2008 and only invested in technology if it felt like it would create some impressive unicorn of an offering. We saw lots of developers tied up with venture capital chasing big things like blockchain and AI whilst ignoring the importance of daily incremental improvement that adds up to a huge return over time.
The answer then, is that if you have access to capital, you should stop chasing unicorns and start thinking about continuous pragmatic development aimed at dealing with all the little productivity blocks in your firm. Look to Kaizen style methodologies to help with structuring your processes around this.
What do you think? Feel free to comment!
The Heroku platform is an absolutely fantastic way to have to not bother with devops within a small development company. We’ve been using it at interconnect for years now, and whilst it’s not entirely perfect, it takes away one set of headaches and does so at a reasonable cost.
All the services offer backups, and the VMs are built from scripts and are essentially read only. So if something catastrophic happened to one of our databases, we can roll back a day and be OK. Except… let me explain my fears around data.
In our very earliest years we used a VPS provider that used Plesk. Everything was solid and stable until one day, we got a report that a site had been hacked. Then another. It turned out that a vulnerability had exposed our sites to being hacked. And they were. This resulted in a big old clean up operation and restoration from backups. Except the daily backups we’d been paying for turned out to be weekly. So the backups we had were three days old. Ever since then, I’ve preferred to have a way of pulling backups separately to a server under my own control, unless the provider is Kumina, because I know the people so well that I’m 100% certain they’re as paranoid as I am and they’ve never ever let me down. But in the era of hustle culture bros who move fast and break things, you need a safety net.
My next fear is corruption you don’t notice immediately. I can well imagine that if all the meta data for the posts on a site before a certain date got wiped out, most people wouldn’t notice for ages. Imagine you’ve got a site with 200,000 posts, and various elements of the first 100,00 were damaged – the long tail matters to these sites and suddenly it’s all gone. Well, thank heavens for backups!
Except, of course, most cloud providers don’t provider substantial generational backups. Instead, they keep a few days or a week or so. And that’s your lot. If you need to go back months you’d better hope a developer in the company left a dump on their laptop somewhere – except of course that very very few developers keep dumps of production systems on their laptops – it’s bad practice and only tends to happen in exceptional circumstances and should be deleted soon after use.
In the end, I asked one of my Linux oriented colleagues, Gianluigi, to create a service that would connect to Heroku’s API and then download every database, and sync every S3 bucket. It worked, with some limitations. More recently, because he’d left but remains a good friend, he helped me with a crash course in Linux sysadmin basics and I was able to extend and improve some bits. The system is a service written in PHP that does all the work. I then asked another colleague internally, Jack, to extend things to cover the PostgreSQL databases we also now used and to create a dashboard so that I could monitor the backups easily without resorting to logging into the backups servers.
The dashboard also doesn’t run on the backups servers. I needed to keep the backups as safe as possible – they’d be a great honeypot for a hacker, so they’re onioned away, and the backups service isn’t reachable from outside. Instead, it messages the dashboard with information about the backups taken. The dashboard also provides details on application and framework versions, for security monitoring and making sure updates have been applied appropriately, and it also sends me a daily summary email showing me storage space available and what was backed up in the previous 24 hours.
Here are a few screenshots of the system, with some censoring, but I hope you catch how it works from what you see.
And now to one of the reasons why I’ve decided to write about this. In the past, I created the first version of Search Replace DB – a quick script and algorithm I knocked up to parse a database and search and replace items in it. A fast, dangerous tool that I released as free open source code. Other people took it and commercialised it into successful products. We didn’t. And with the code being integrated into wp-cli and most devs would use that in preference (myself included!), except in those tricky situations where command line access wasn’t possible – mostly on cheap hosts. I think we were right to release the code, but where we failed was in realising the commercial possibilities. And that’s left me a little torn.
So now I’m torn – it’s not easy to set up services in Linux, but once you do, these things just run and run. It’s also not going to be the easiest thing to work with, so I anticipate support costs being quite high. It’s proper server level work. And I certainly don’t feel inclined to build a SaaS that acts as a conduit for people’s backups. It’s just too risky to have a central pool of lots and lots of backups, and people find them lurking on S3 buckets all the time. So I want to put this out to the community. Is this something you’d find useful? Let us know in the comments below. If we did release it, the code would be open source, but access to the latest versions would be restricted.
I’m looking forward to hearing your thoughts!
