Speed Kills not just on the road, but in software development too.
I remember years ago I was crazy like that. “Gotta get this done, gotta get this out the door.” I was working until all hours of the night, heck I even worked on Christmas day cranking out code. The sales guys said, “we need this feature or this prospect won’t buy, and if they buy they’ll buy big.” But… “The feature is going to take months to implement. The code is a mess.”
Why would anyone code like that? Well, in my first job the schedules were somewhat unrealistic, moreover the scope was constantly changing. Being fresh out of university I had no idea how to estimate properly so I went with the premise that these people have been “out there” 10 to 30 years longer than I have. Also, I was a little too eager to please. With hindsight I can see that my gut feelings were right, but at the time any argument was met with somewhat patronising responses that I was still a “boy” and didn’t know how the “real world” worked. Eventually, I did manage to push through process changes to, at least, formalise things a little better, but by that point most of the damage was done.
What I can be thankful for now is that I don’t have to work like that any more. Schedules are realistic, code is better formed - sometimes a little rushed in areas due to an impending deadline, but not to the overall detriment of the project.
🔄 Follow up - 8th August 2026
From my early days of software development (when I was coding at all hours, through the night, on holidays) two specific incidents come to mind.
During my first job out of university, in the mid-to-late-90s, the sales guy (which I alluded to above) was the kind of guy who’d sell the customer the moon on a plate then leave it to the development team to figure out how to actually deliver it.
One day, after many meetings where he was told off for over promising what we could deliver for the cost he’d quoted he came in all smiles that he’d pushed back and got us an easy project. It turns out his idea of easy was not the same as our idea. He’d pushed back and said we couldn’t deliver the part of the project that was all mathematics, and had promised the customer that we could deliver the “easy” bit. The “easy” bit was was to replace a manual process full of context heavy descisions, many of which may be ad hoc because the scenario was new - something that a human might find obvious, but not a computer running Windows 95. Modern AI might manage it, but he’d over promised again because while he could conceive that part being easy and the maths part hard, in terms of computing it was the other way around.
That meeting was fraught as three people tried to explain to him that computers were really good at mathematics and really bad at ad hoc decision making while he tried to argue otherwise.
The other incident was at the same job where I’d been asked to estimate a piece of work. I came up with three estimates (I’d read about it somewhere, I don’t remember where, but the idea was that you present a optimistic, and a pessimistic estimate and you’d likely end up somewhere in the middle) and in my naïvity I presented my findings after working out what needed to be done in accordance with the suggestions in the book. The book did not go into office politics, and the business decided that - without question - it wanted the optimistic estimate and treated it as a deadline. Within days I could see that things were sliding out from that estimate and we weren’t going to hit the deadline. I let folks know and I was told in no uncertain terms what the deadline was and what I’d “promised”. It was as if they only listened and read the parts they were interested in and completely ignored everything else.
