The satire in the title is reminiscent of how Firebase was born.
We were previously working on a chat system called Envolve (https://www.envolve.com), that was 'Facebook Chat for any website'. A game that was using us for in-game chat created channels, used display: none on them, and passed game state through the chat.
We scratched our head, asked them why, and learned they wanted to focus on the frontend, not to deal with realtime message passing.
This led us to create a 'headless version' of our chat infra (re-written in Scala) that became the Firebase Realtime Database.
This is an important lesson - if someone is using your tool in unexpected ways don’t just shut them down; there’s likely a business case that could be identified and specialized in.
Nobody wants the product you want to make. They all want you to make the product they need, and will do things the devs of your product could never imagine with your product.
We make a CRUD desktop app, with a lot of integrations to customer systems. We got a standard set of XMLs, but we'll deal with whatever the customer has if we need to.
We recently got a support call from an upset client. A recent change had broken their integration, halting production.
This lead to some head scratching on our side, as we couldn't figure out what integration they were talking about.
Turned out they had paid some consultant quite a lot to script some tool similar to AutoHotkey to transfer data from their order system to our system. It would emulate copy pasting fields, tabbing along.
Our recent update had introduced a new field, thus screwing it all up.
As an aside, the "integration" used half an hour to transfer a single order due to how it did its work. An XML would have taken seconds tops.
I had a client who wanted to build his business on top of our business via scripting our administrative back end - basically he wanted to be a value added reseller. He'd get angry when we modified our admin console. We offered him API access for a fee, but any fee was too much for his business model. It was quite frustrating and eventually we had to ignore his pleas for UI stability over years of time. All the while he could have had access to the API for less than he was paying the person to script our admin console. This was circa 2007, so perhaps API programmers just weren't the thing back in the day.
I think this is unfortunately what is going happen in the next few years as more tech companies will price their APIs out of reach of small businesses :/
Indeed. Tangentially, there is another side to the coin.
The antithesis of this is the contract model, when a client comes to you and asks you to make something specific, rather than describing what they need. In this case they are almost always wrong. They’ll rarely admit it unless you show them some amazing alternative, though.
Requirements = a set of problems to be solved. More often you get handed a diagram of a 12” tall Stonehenge sketched on a napkin with exceeding confidence that it will be 12 feet tall.
This happens outside development, too. More often than not in IT, when the business has a need, they start with a solution and approach IT asking them to implement it. I've gotten better over the years (although always room to improve) at steering the conversation around to "what exactly are you trying to accomplish?" Let's start there.
The quote is alleged to be Henry Ford, and I've always encountered it as "better horse."
In either case, the customers aren't stupid but instead are using the language and paradigm they are familiar with to describe their needs. Ford did indeed provide a faster/better horse, because the horse was the main means of non-human motive force in the US.
The technologist's job is to understand the universal of possible solutions and to understand the customer's needs and goals, which often includes interrogating and parsing the customer's language/worldview, and craft a product that achieves those needs/goals (and doesn't introduce negatives that overwhelm the benefits).
Regardless of the provenance of that quote, it is quite apt wrt IT clients. They always come asking for a faster horse, ie: something they know that is just better in a specific way.
A lot of the times this might be wrong but I think the interesting part is how that request gets handled.
The horses were themselves a more immediate sanitation problem; in New York alone there was a million pounds of horse manure every day, plus thousands of horses that dropped dead from overwork. Disposing of all the feces and corpses was a challenge.
And to be fair there was a lot of grumbling about the "horseless carriage" for quite awhile.
What's interesting to me is that the oldest streets (ignoring the Main Street) in the local small town are the widest, because they needed to be able to turn around a team of horses and a carriage/wagon even when other wagons are parked on the side. The newer streets (but still 1940-50s) around are narrower because they didn't have to accommodate that.
It is frustrating how often I have to tell my non-techy CEO to rewind a step, and tell me the problem he is trying to solve not the half-baked solution he came up with. One bad idea he has had for over a decade, and I have to keep beating it down since it is an extremely stupid method to solve nothing.
There is another side to this coin, too. It is clients that describe their needs, not some specific and wrong solution, and then either get told they did not do their homework, or their needs getting ignored by a dev who thinks he is smarter than the client in the client's own field.
It is correct that "Requirements = a set of problems", and therefore it does not make sense at all to repeatedly ask the client for a technical solution instead of asking for the problems to solve, and then be surprised that the client does not talk about problems anymore.
The kamikaze was a grim solution to Japan's losing of the carrier offence/defence balance; the rate of pilots returning from sorties was poor, and the rate of pilots returning from tours to be instructors was extremely low, so the solution was to take very young men with minimal training and use them as human guided missiles. Pilots were probably going to be killed anyway, so the focus was on trying to achieve carrier kills at any cost.
(Humans will really adapt anything into a weapon, including human lives themselves, especially in a total war)
Also consider that more than half of the hits to Japanese aircraft in the Pacific were caused by the use of the top-secret VT radar proximity fuse.
The Japanese predicted they were going against "dumb" timer-based anti-aircraft, which was probably two orders of magnitude less accurate and less effective, where their weak armoring would have been a good approach: if you think it will take 200 shots to bring down your planes, fielding twice as many units that could each be brought down by one lucky direct hit makes great sense. But if it only takes two shots, you need to be able to survive the shrapnel.
The strategy they put in motion in 1942 suddenly became obsolete in 1943, and it was too late to pivot.
> This is an important lesson - if someone is using your tool in unexpected ways don’t just shut them down; there’s likely a business case that could be identified and specialized in.
One of the craziest cases of this I've seen was with a web-based survey application I was the principal engineer on in the mid to late 2000's. A big feature we implemented was the ability to create surveys to support multiple languages. To make translation easier for our customers to translate surveys outside of the application, there were ways to export/import the text strings as well as a standalone screen that allowed finding and editing them. Both of these were made easier by the fact that the strings had semantic identifiers like "/survey/question/choice" or similar.
Since this functionality worked so well, we also used it internally for all text in the application. As a convenience, both the import/export and edit screen were capable of editing these strings. One customer figured this out and, due to the naming, was easily able to identify the text for all screens and dialogs. They ended up completely modifying the application interface through this interface by editing text, adding HTML elements, and injecting CSS blocks. They added descriptive tutorial text, guides for users, and branded the application well beyond built-in functionality. It was pretty amazing.
It's amazing with how much creativity users will abuse your creations. ;) And in many cases, something new is born out of it. The problem is getting the information about just how people are using your service differently than you've intended. Sometimes it's impossible to tell from traces, analytics or logfiles alone. But finding out can be quite an advantage, especially if you're a startup probing for PMF.
The best thing that can happen is that you have a channel to your customers that's constantly open. At WunderGraph, we use Slack for that, and it considerably lowers the barrier to just check in and have a quick discussion. The sooner you find out about use cases, the better - and ideally create a product around it. :)
We were previously working on a chat system called Envolve (https://www.envolve.com), that was 'Facebook Chat for any website'. A game that was using us for in-game chat created channels, used display: none on them, and passed game state through the chat.
We scratched our head, asked them why, and learned they wanted to focus on the frontend, not to deal with realtime message passing.
This led us to create a 'headless version' of our chat infra (re-written in Scala) that became the Firebase Realtime Database.