I love deadlines. I like the whooshing sound they make as they fly by. – Douglas Adams
One thing I’ve noticed about working in the software and testing industry, is that there’s a lot of hurry and haste, which results in poorer quality.
The haste most often… hm.
No, I’m going to say “always” here. I don’t usually use “always” or “never”, but in this case it’s true: The haste always comes from having deadlines enforced.
And deadlines are utterly stupid.
I know we have them, and we largely have to live with them. But just because something’s ubiquitous doesn’t mean it’s good.
So today, I want to challenge the idea that we even need them.
What Are They For?
There are very few reasons why a particular project needs to get done by a certain time.
Most often, I’ve found that a budget is the reason for a deadline (i.e.: we have this many people that can work this many hours, and we have this much money in the tank–therefore the project has to be done before we run out of money = deadline).
Or, they could be customer-enforced (i.e.: I have this much money for you to complete the project, and as such, I want it done by this time = deadline).
Or, they can be mandated by a crucial third party (i.e.: the stock market is rolling out an upgrade to some of their feeds, and any consumers of it need to retool their code to account for it by a certain time = deadline).
But here’s the thing about software development and testing: It’s not an exact science.
We estimate how long it will take to get a project done, because there are unknown-unknowns.
We don’t always have that whole time to work if there are problems in the environments that we’re working in.
We can have master knowledge of everything in your domain, but if a server goes down at the wrong time, we can’t work.
A deadline is for making sure a task gets completed on-time. The question is though: what does “on-time” mean?
What Do They Do?
Do they cause software to get done? Yes. Unless the deadline gets missed. Then no.
They can imply that your team is not driven enough to get the work done on their own.
They can also cause corners to get cut in code or in testing.
If your company is using deadlines to goad people to get work done, then there may be a problem with the culture or the hiring practices.
People are really passionate creatures. All of us are. We all care about something. So if you have people who are passionate about what they’re doing, then give them something cool to work on, and step out of the way. Magic will happen.
What Are The Results?
- Features start getting cut. Which, in a way is good. Releasing less code will disturb the code base less, and cause fewer problems. But, in a way it’s also bad, because if you’ve previously committed to releasing a certain amount of code, then change that amount, that’s kinda wonky. Do you want to have to cut features that could be good for your customers? Are you overcommitting somewhere maybe?
- Testing starts getting cut. It’s counter-intuitive, because if you’re working faster than anticipated, to meet a deadline, then cutting testing when it’s more likely there are errors in the code due to the speed of work, will make more problems later. Time spent fixing bugs is time spent not writing revenue-generating code. Do you want to spend time fixing bugs that could’ve been filtered out in development?
- They increase complexity. Every line of code you write costs money. There are probably studies showing how much each line costs in terms of time, debugging and maintenance. Deadlines cause code to get “stapled on” quickly, which increases the code footprint, which increases complexity, which increases the chance of a bug, and also increases the maintenance cost.
- The focus changes. When a team is operating in beat-the-clock mode, they are no longer focusing on the code, but rather focusing on meeting a deadline. I’ve seen firsthand that this causes poor code quality, because people start taking the path of least resistance to slam out code and be done. Poor quality = more bugs. Do you want your knowledge workers operating in reptilian brain mode in order to meet a deadline, or do you want them calm and focused?
- People adapt quicker. This is about the only positive side I see to a deadline. It does cause people to adapt faster than normal. Innovations are made, technologies are researched. I get that. But I’ve also see that when you take passionate people, and put them in an environment where they know some stuff but have to learn new stuff too, innovation happens that way too. Do you want your team to adapt inorganically via deadlines, or organically via the drive to learn and achieve?
- They cause stress. Some stress is good. But all of life contains stress. I don’t think it’s a positive thing to allow stress to be manufactured by an arbitrary deadline just for the sake of making sure you’re still fit. People under stress often make poor decisions, because they’re thinking about the stress and not the situation. When software is involved, those poor decisions can also hurt others in terms of time and money being spent fixing those decisions, instead of writing more valuable code.
“Haste Makes Waste”. Who said that, Benjamin Franklin? That was over 200 years ago! It’s a phrase that applies today, although I’m sure he didn’t have software in mind when he said it.
What’s the waste? When you spend less time crafting quality into your product, you will pay for it later in terms of fixing bugs.
Where Do We Go From Here?
You know, when I go to the hardware store, the most common marketing term I see on products is “quality”.
Companies who make physical tools want to be recognized as a company who crafts quality into their products.
They make stuff that doesn’t break, that you can drop off a building and it still works, that works in all weather conditions, has long battery life, isn’t made from crappy parts, etc.
You can probably name a few brands off the top of your head that you’d be more likely to buy from, because you know they have quality, and because they’ve been around for awhile.
So let me ask you this: What do you think would happen to a company that was known for providing high quality code all the time? That when people think of quality [whatever kind of software product], that company name pops into their head?
What if that same company didn’t worry so much about being first to market, but being first in quality?
Would their competitors be able to match that? Wouldn’t customer loyalty be huge? Wouldn’t that raise the bar for anyone else to compete with that company?
If deadlines are a cause of code quality tanking, then wouldn’t dropping them in favor of focusing on quality be an option?
Deadlines are a type of metric. How many do we hit? How many do we miss? How many have to get pushed back?
Instead of using deadlines, either as a metric or at all, try just dropping them.
Not everybody. Not at first. That’d be weird.
But instead, let’s focus on the customer, and focus on keeping the code base stable.
Small releases are least disturbing to the code base. What’s the smallest chunk of code you can release to a customer?
How can you craft quality into the product? Don’t worry about how fast you can do it, but slow down and take your time. What technologies are out there to help you write code that’s easier to maintain?
What ways can you test the product? If it’s not done already, take some time and diagram where your part of the system fits into the rest, and how information flows through it.
What kinds of bugs can you test for? Don’t just write a bunch of smoke, integration, system or feature tests just for the sake of saying you have those kinds of tests, but instead fish for bugs that you expect you may find. Don’t focus just on code coverage either–it’s a good start, but not an end. Look for problems intentionally, don’t hope you find them accidentally.
Listen, I’m not trying to boil the ocean and say, “All companies everywhere should drop deadlines RIGHT NAO!!”. Nope.
I know that the stress that they create, some people thrive on. I’m one of them. It’s exciting.
But it’s not worth the excitement when it affects code quality.
There are plenty of places people can work where they can engage in trench warfare. If that culture is working for your company, and you’re happy with the staff and the results, that’s awesome. I really am glad it’s working for you.
If your company however is floundering and in need of a change, this post is for you. Maybe trying something different would yield different results.
Just try it out. Maybe one department. See what happens.
Is the output better? Easier to maintain? Fewer bugs?
Does your team understand the product better, and how it interacts with different parts of the system?
Are people talking more? Are they smiling more?
It’s a neat experiment, if you’re willing to take a chance!