Step 1: Developers Agree to Deadlines

Imagine you wanted someone to build you a house and they told you that it would take a year to build. “Unfortunately”, you tell them, “I already told my family that we’d be living in our new home in 3 months”. Of course they tell you they can’t build it on such an aggressive timeline. But, lets say, hypothetically, you had the power to convince this person to agree to your deadline. Would you feel comfortable living in that house?

Imagine the amount of corners the builder would have to cut to meet your deadline. Building a house that way would probably break all sorts of laws. Yet, we do this on a regular basis in software: A manager tells developers about a deadline that they don’t believe they can meet and the development team has to scramble to try to meet it anyway.

Developers have to have a say in deadlines or you will never be able to build high quality software. This is step 1. I don’t use the phrase “step 1” lightly. I literally mean that this is the whole foundation that quality software is built on top of. You must tackle this first.

If developers don’t have a say in deadlines, any attempt at quality will be undermined by unrealistic schedules. Corners will have to be cut to meet these deadlines (AKA technical debt), but the developers will never have any time to go back and pay off this technical debt. Quality can only get worse in such an environment. No process, including Agile, can overcome this.

The only people that know how realistic a deadline is are the people that know the inner workings of the project: The developers. And if they aren’t involved in setting deadlines, an unrealistic deadline will be picked most of the time. That’s because, all things being equal, delivering a feature sooner is better than later.

Now you may be asking, what if the developers don’t agree with the deadline? At this point the managers and the developers should negotiate.

One thing to negotiate on is scope. e.g., “What if the building didn’t have AC by the deadline but we installed it later?” This often goes back and forth many times as the manager and the developer come to some agreement.

Another thing to negotiation on is the deadline itself. e.g., “Realistically, we’d probably complete that 2 weeks after the deadline. Is that ok?”

And third, quality can be negotiated on. e.g., “These windows are poor quality but they’ll save me a ton of time to install at first. Then we can go back and put some better quality windows in later.” Technical debt is an example of this. But quality can only be negotiated on if there is trust between management and the developers. The trust needs to be that the developers will be allowed to go back and put some better quality windows in later.

By the way, this shouldn’t be unquestioned trust. The manager should ask why the developers won’t meet the deadline. Maybe the developers will say, “Because it takes 5 weeks to lay a foundation for an apartment complex”. Then the manager could say, “We don’t need that. We only need the foundation for a single family home”. This communication is very important.

But, this whole system falls apart when developers have no say in deadlines. The end result is poor quality software every time.

“If it ain’t broke, don’t fix it” only makes sense for finished products

If it ain’t broke, don’t fix it: Leave something alone; avoid attempting to correct, fix, or improve what is already sufficient (often with an implication that the attempted improvement is risky and might backfire). –Wiktionary

A lot of developers avoid improving the code they work on and if you ask them why, they’ll say, “If it ain’t broke, don’t fix it”.  I understand their perspective: Every little refactoring could introduce a new bug and they “know” that the code works right now.  Well, in my experience, when people have this attitude their project is usually broken in some way they just don’t know yet.  But, that’s not the point of this article.  The point of this article is that the, “if it ain’t broke, don’t fix it” attitude only makes sense on a finished product.

You can have the luxury of this attitude when it comes to your car, your TV, or your watch.  When a watch is shipped, if a “version 2” comes out, it completely replaces “version 1”.  Both “version 1” and “version 2” are finished, physical products that do not effect each other.

But, software is a different beast.  Very rarely is software “finished”.  Usually it is actively maintained for years and needs to be changed by a developer constantly.  In this situation, you can’t have an “if it ain’t broke, don’t fix it” attitude because, working or not, it needs to change.

Continue reading

Are you “risk adverse” or just “improvement adverse”?

It is my firm belief that you can be risk averse while constantly improving.  I worked with someone a long time ago who said that they were “risk averse”.  What this meant is they didn’t like the way that I would refactor code I had to maintain (after I put it under automated tests).  They pushed back on my suggestions to improve deploy times because it would require changing things that “already worked”.   These deploy times were taking up to thirty minutes and sometimes occurred multiple times a day.  That got me thinking, “are you risk averse, or are you improvement averse?” Continue reading

The “there are more important things to do” fallacy

Occasionally when people are discussing the merits of software quality, someone will chime in and say something along the lines of “if it isn’t billable, there are more important things to do”.  In this article I’m going to break down why this argument is a fallacy.  It’s my belief that improving the software quality is just as important as billable hours and new features.  I’m going to tell you why:

Continue reading

Developers should not have to interact with human beings to set up a new environment

It’s typical for a developer to have to wait on some person to be able to get a new environment set up.  For example, when the new project has its first acceptance test, a new server will probably be needed to run that test on.  At your typical company, this developer will depend on another team to set up that server.  Usually, that team is very busy working on more pressing matters (e.g., a production server seems to be low on RAM), so the developer’s needs are relatively low priority.

This type of situation should not even exist.  Developers should not have to interact with human beings to set up a new environment.  Continue reading