I made the following post on LinkedIn the other day that basically said: “If you only document your successes and not your failures, everything looks like success.” I have long been a believer that failure teaches as much as any education, as I blogged about 15 years ago in a blog called What Counts For a DBA: Failure. Failure is is a great teacher, probably even better than someone teaching you something. Humankind didn’t learn to fly because it was handed down, it took a lot of trial and a lot of error.
But let’s face it, failure alone is not the best solution. People still have to relearn how to fly to this day, and learning by failure is still important. But the best learning is from being taught a concept, and then trying it over and over. It is kind of like playing a video game. If you don’t know the trick to a level, you can cheat and see what the technique is. In work, that isn’t cheating, that is sound practice.
Repetition is key
But repetition is the key because you aren’t going to get it right the first time, and if you do, you may not the second or third. Failure, even many failures can be involved before you solve a challenge.
Just like a video game, when you repeat the task over and over, you are learning things. Some is problem solving, and some is muscle memory. The next time you go back to a game that was hard the first time, many times, even months in the future, you are still able to solve the problem is almost no time at all. And weirder still, similar challenges become easier to accomplish. Getting over that one hurdle gets your brain trained to solve that type of problem without the large learning curve.
In computing we definitely learn from failures. You have a query that runs long and it gets you noticed, your learn to make sure to do some performance testing. And then later you learn to make sure that you are watching query performance at peak times and as data grows. If you are lucky you have a mentor who says “make sure to check performance this way” so after you fail to do what your mentor told you the first time, at least you had it in your head so you learn faster than just poking around like walking around a pitch black hotel room half asleep and discovering the leg of the chair that just broke your toe..
So what about deadlines?
Why aren’t deadlines like this? Lest I contradict my post on deadlines from a mere 5 years ago where I quoted Walt Disney as saying:
Everyone needs deadlines. Even the beavers. They loaf around all summer, but when they are faced with the winter deadline, they work like fury. If we didn’t have deadlines, we’d stagnate. ― Walt Disney
I still believe we need deadlines. But has there been anything that has failed more than deadlines? In work, home life, etc, we always want to know how long things will take. But over my life I have seen so many deadlines fail it amazes me.
A current semi-public case in my theme park life is a new attraction at Dollywood called “Nightflight Expedition” State of the art, first of its kind attraction, the link is to the press release and this is going to be a great attraction. Very excited about it.
But they set anticipated opening “Spring 2026” for completion. That seems okay, but then it was printed on billboards “Coming Spring 2026.” This is no longer an anticipated date, but seemingly a promise.
The only problem with this (in my mind), is that they set a shareable date before they were sure. It isn’t clear when it will be open, and I feel the same way with it as I do with software, it will be ready when it is ready, and when I hear a date, I will be using vacation to go up and ride this. But that Spring date has taken what could be an even longer buildup to a gossip excuse.
Dollywood is far from the only theme park to have done this, and having worked in marketing some, I get it. You don’t get the same kind of buzz from “it will be done when it is done and done well for your safety and entertainment.
Of course, neither does the department head who has to get things ready for a big rollout with new software, new databases, all new reports, etc. It is freaky hard. Managing a project is the second hardest job in IT (first is analysts, as they have to learn the business, document it, and then put it into language that says “build it like this.” There is a lot of nuance and different methods of doing this, but it all boils down to that. Computing is a lot of math where the answer to the equation is always numbers, reality is a lot more complex and software and theme park attractions can be easily plagued by problems with weather, sickness, unexpected issues, whatever.
‘
So why do we keep putting deadlines on things if we always fail
I suppose, just like Walt Disney was noting, they motivate people…in good and bad ways. Despite the fact that they never seem to actually be met, we keep making them. I mean we do it to ourselves “I am going to lose 10 pounds in a week”, our kids, “you have 30 minutes to do that homework”, and our work “I need to finish this in 2 hours”, all before really knowing exactly what it will take.
We do it over and over, people pick dates and then see how much work it is. Probably the only people in the world who won’t seem to do this are people who actually have a good idea how long their work will take: service people. “How long will it take to fix my washer?” “I will just have to see.” Even when it is a fixed price, and you promise you won’t yell at them if they are wrong, they straight faced say “I don’t know.”
Mind you, this even when they do actually know how much time they expect because they have another repair scheduled after you, and they showed up to your house on time.
Let’s change the name of deadline
I submit to you that there is a better name for deadlines and that is target. We are “targeting next spring” is different than “coming next spring”. And everyone know that targets change. (And in the weird world of marketing, people checking for changes to the target dates, looking for that firm date that you get when you are into the final testing and staffing stages of a project… well those people see your other marketing material too.
Deadlines are so hard because they require time estimation. When I was a green programmer and was asked “how long will this take?” I often thought about the process and tasks and said something like “2 hours.” Sometimes it might be shorter, or sometimes it is a month later and you are still not quite sure when you will ever do any other task in your life. Sometimes you think you are finished and it fails all the tests. All of them.
So as you progress in your career, you start to realize that 1. You could do the task you THINK needs done in 1 hour. You guess that it will take 4 hours plus a bit of discussion, and you guess the entire task will take 20 hours. And you answer… I think I can get that done in 30. But if this is treated as a deadline, you know your reputation is put on the line, so now you think “what is safe? 200? Maybe that’s too high. 300? That’s the wrong direction, but let’s try that.” All because of the fear of the deadline.
I can easily target 10 hours, but if you make me promise, well, I am never going to be that sure.



Leave a Reply