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.
It happens quite a bit - people solve the problem they have with what they know.
Webscraping will rise again.
At this point, wasn't banning him in the cards?
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.
Then they yell at you for doing what they said.
(Probably not a real quote, and probably not even accurate.)
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).
A lot of the times this might be wrong but I think the interesting part is how that request gets handled.
/s but maybe only half
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 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.
(Humans will really adapt anything into a weapon, including human lives themselves, especially in a total war)
* Poor Japanese fighter aircraft design philosophy (weak armoring, no emphasis on pilot survival).
* Poorly trained pilots (all the veteran, experienced pilots are dead because see above).
* Poorly maintained aircraft (insufficient supplies and manpower).
* Insufficient ordnance (insufficient supplies and manpower).
* Insufficient fuel stores (so a one-way sortie out was all they could afford).
* Insufficient food and drink (a pilot going out to kamikaze is one less mouth to feed).
* Fanatical and delusional military brass.
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.