I have experienced something in my career that is by no means unique to me. When a project goes wrong and there is a real struggle to hit a deadline, things that are supposedly important get pushed aside for the temporary expedience of hitting that deadline.
Hitting a deadline is important, but so is having a quality standard, so is having principles, ethics, and most of all so is having the respect of your team.
When you slip a deadline, you are letting down your client or whoever you are shipping for, but when you put your team in a crunch time situation, you are letting your team down.
Working late nights, pushing the team to work faster, and allowing quality standards to slip is disrespectful to the craftsmen that you work with. It basically says that their long term well being is not as important as the short term well being of the client.
More importantly, when you push a team hard to hit a deadline, you are putting the long term well being of the client at risk for the short term gain of hitting the deadline.
Why do I say that? Well, what happens when you push hard for a deadline? Your team works more hours, this is obviously unsustainable, but in the sort term it seems like a good idea right? No, it’s not. Not even close.
I’ve personally seen co-workers who loved a project start to hate it because they put in too many hours and got burnt out. It was bad enough for them to switch jobs. I’ve seen other people work enough that I’m surprised they didn’t switch jobs. They certainly didn’t enjoy the job they had at the time.
I generally enjoy my work, but I’ve been pushed past the breaking point before. It makes you start to look around and wonder what else is out there. Even if you usually love your job, long hours and terrible deadlines on a regular basis make you start to think that working at a more boring job with no deadlines would be better than working at a job that doesn’t have a certain level of respect for your time.
This pattern of burning out employees and having significant turnover is something I think I’ve seen at just about every place I’ve worked in some form or another. Even at the best places to work, there is a very real lack of awareness of this issue, even though they struggle constantly to keep employees for more than a couple years.
Now, if you care about your clients or the company you work for, you need to understand that losing great employees every couple years is not good for the long term viability of either. Every time you lose someone you aren’t losing their skill, you are losing their project knowledge, which in some cases is basically impossible to replace with a new hire.
Burnout is not the only reason why pushing hard towards a deadline is a bad idea. Quality standards seem to always slip when a deadline comes around. In software, the first set of things to go are quality related, things like unit tests, QA testing, and so on are instantly devalued when a deadline comes up.
I say this because I’ve seen this happen over and over again. Deadlines happen, quality suffers, and project managers don’t seem to connect the dots until it is too late.
Quality problems are rarely short-term either. Once you start shipping low quality code using a low quality process, that becomes the standard.
Now, this is not a malicious march toward low quality software. No, in almost every case I remember people saying things like, “We will go ahead and write those tests in the next sprint when we have more time.” or, “We’ll get back to test driven development once we get past this big milestone.”
Do teams really go back and write those tests and get back to their previous quality standards on code that they already shipped? What do you think?
In my experience, the answer is no because as soon as things are shipped, the #1 priority is either fixing bugs or building the next feature. During the bug fixing process, rarely is a test suite added, because you’ve already written the feature, why write the tests after the fact? When you move on to the next feature you basically forget about the previous one.
In either case, quality standards slip and very rarely are they ever restored. Instead, programmers are human and the code becomes the new quality standard. How?
Well, it sits around and when the next programmer comes along, there is no flag saying this code is terrible and needs tested and/or replaced. Nope, instead the code probably looks reasonable and will be used as an example, copy/pasted, etc.
You might not think that your coding standards or quality standards are some document sitting in a wiki or something, but in reality the code that you have today is your quality standard. Let that sink in for a minute.
The code you have today is your quality standard.
So, when you cut corners and skip out on silly little things like design, testing or quality assurance, your quality standard goes down instantly.
When quality goes down, bugs go up and the attitude of running fast and loose catches up with you. When you skip out on design or planning up front, the end result is worse code, worse product. It’s just worse.
It’s not just the manager’s fault either. Every team member is equally responsible for code quality.
This all might sound a bit overdramatic to you, so I’ll use an analogy from a similarly craftsmen oriented field in the real world. Let’s look at roofing. Imagine a house project is taking too long. The contractor is under pressure to hit a deadline and starts pressuring subcontractors, including the roofers.
Now, if you’ve ever put on say an asphalt roof before, you know that a roof needs the plywood on there first to provide the basic structure, then you nail down the felt on top of the plywood, and then you nail down the shingles themselves. In some parts of the roof you might need to put down tar around chimneys and air vents so that they don’t leak.
Ok, so what happens if you skip the felt installation? What if you skip the tar around the chimney? Well, you could certainly put up a roof without felt, but it would leak. Yes, from the outside it might look like a nice new roof, but on the inside it would leak. What is the point of paying for a brand new leaky roof?
Back to software, bugs in the code are like a leaky roof. Your clients or customers don’t care if you hit a deadline if the software is buggy and broken. Why would they continue to pay you for brand new broken software?
So, do you think that pushing a team hard to hit an arbitrary deadline is still a good idea?
Are you willing to give up your team’s time, happiness, and longevity on the project for that deadline? Are you willing to give up on quality for the deadline?
Is is really that important?
That is the question you have to ask yourself when you ask a team to dig deep for a deadline.
The answer to that question is where people show what they really care about. Do you really care about your team? Do you really care about quality? Do you really care about the process?
If you really care, then there are ways to adjust the deadlines to be reasonable. Change the scope, talk to the client, talk to your boss, adjust expectations. In almost every case, changing the expectations to something more reasonable is a better choice than sacrificing your people or your quality.
If you don’t care and want to just push through to that deadline, I ask that you stop pretending. Stop pretending that the longevity of your team is a top priority. Stop pretending that quality matters.
If you want employees to last and be happy, don’t delude yourself into thinking that they enjoy working long hours, nights, weekends, etc. to ship code. If they are married, have kids, have pets, or have a social life, they probably don’t want to be around past 5:00 pm. You shouldn’t want them around past 5:00 pm. If you gladly let them work extra time, you should expect that they will be gone in a year or so. Don’t pretend that you expect them to last any longer than that at the pace they are going.
If you suspend or perhaps just frown on vacations during crunch time, please don’t pretend you have a flexible vacation policy. It is disingenuous. You clearly don’t believe in a flexible vacation policy, you just want people to believe that have one.
If you do test driven development, but set it aside for a deadline, you should just stop doing TDD in the first place. The value from doing the process, not from saying you do the process. You obviously don’t believe the process is that important.
If you do agile development, be it scrum or kanban, or whatever else, but you put it on hold to hit some deadline, you should stop pretending to do agile development. Maybe you are willing to give up a retrospective or a stand up or a planning meeting to hammer out some bugs for a few days. Okay, what you’ve just done is show that agile isn’t that important, so please stop doing it. You don’t really believe in it.
I could go on, but I’m sure it’s sinking in by now. If you are willing to throw something aside during crunch time, you shouldn’t waste time doing it at all ever. You will end up probably doing a better job because you won’t waste so much time pretending that you believe in things that you really don’t.
Honesty is a better deal for everybody than “faking it ‘til you make it”.
Honesty sets up real expectations. Honesty is backing up your beliefs with actions. Honesty is hard.
If you want to know what someone really believes in, look at their actions. See how they spend their time, their money, their energy. Is it honest? Is it a facade?
What do you really believe in?
It doesn’t matter if you are a manager, team lead, or just a programmer. If you really care, if you really believe in something, then stand up for what you believe in. Otherwise, don’t waste your time with a part-time belief.
P.S. Have you subscribed to Code Career Genius yet?