I was sitting on a call the other day.

We were going through a list of requirements for a project my team has been working on. I had called the meeting to let stakeholders know development was going to slow down.

The senior architect on my team had left in the middle of the project. So I, of course, had to inform the people that care that the date was going to slip.

The answer I received was "that is a hard deadline, we still need all the work by that date."

So I still had to get the same amount of work done with 1 less person.

Great.

In some cases, this would actually be a good thing. I'm sure we've all seen this saying:

Programming Wisdom

@codewisdom

"What one programmer can do in one month, two programmers can do in two months." - Fred Brooks

22:54 PM - 02 Mar 2017

In my situation, the team was already running a little thin, so I had to remind all the stakeholders that you can have software fast or you can have it right, but you can't have both.

This refers to the timeless battle of quality over speed.

How do you balance it? What can you do to deliver more software faster?

Finding a Balance

If you left it up to developers, software would never ship. They'd always want to add "one more feature" or tighten up some css on a webpage.

SPOILER ALERT:

There is no such thing as perfect software.

Think about that from any lens. There is no software without bugs. You will not have 100% satisfaction across all your customers. There won't be a time when developers do not want to refactor something.

Software is constantly evolving. You must get it to your customers at some point.

On the other side, if it was up to the sales department, the software would have been done yesterday.

"Does it solve the business problem?"

"Kind of, yes."

"Ship it."

Unfortunately, the quality vs speed graph isn't linear. One would hope that for each week you move up a deadline, the quality just gets a little worse.

Nope.

Moving up dates means taking shortcuts when it comes to building software. If you start adding shortcuts on top of shortcuts, you are going to get exponentially worse results.

The software will appear unstable. It won't look as nice. You'll get intermittent behavior.

If you don't want to dig yourself into a hole, err on the side of quality.

Be Consistent

One of the biggest principles I follow when building new software is iteration.

Get through the business process end to end via the happy path. Then make another pass and improve everything just a little bit. Then do it again. And again.

This is going to provide you with a consistent feel throughout your app and also maintain the highest quality possible if you're asked to go fast.

I often see teams that build one section of their app completely before moving onto the next. By the time they reach the end, it either took too much time or they were asked to speed up a bit, leaving the results....somewhat to be desired.

What happens when you focus on one area before you move onto the next

This doesn't always happen but it doesn't mean it can't happen to you. Be sure you are generous with your estimates and give yourself some padding on the timeline.

It is always harder than you think.

Do's and Don'ts

When it comes to speed vs quality in software, there are a few things you should do and a few you should definitely not do.

DO: Have a Plan

When people inevitably ask you how quickly you can do a project, be sure to have your trusty development plan handy.

Reference all the pieces of the plan and be ready to identify the areas that can and can't be shortcutted.

DON'T: Throw More Resources at a Problem

There's a saying that 9 women can't make a baby in one month. Some jobs are meant to be done by the resources you already have.

Adding more developers to a team oftentimes will slow the team down at the beginning as they bring the new hires up to speed. Be intentional about the people you add to a project.

DO: The Minimum

The middle of a big push is not the time to start "gold-plating" features. Start tossing out features you were planning that aren't part of the requirements.

You can and should come back to those after you get your initial release to the customer.

DON'T: Work Without a Timeline

On the opposite end of the spectrum, don't do work without a set date in mind. People need deadlines.

When I was in college, I would get a project at the beginning of the semester that was due at the very end. I had the entire semester to work on it.

Every single time, I would ignore the project and start it a few days before it was due. I would do a mad scramble at the end and get it in last minute.

Don't let this happen to your software. With no deadline, you'll be lazy and have no reason to finish it. Always work toward a goal

DO: Be Intentional

You're going to cut things that shouldn't be cut. Quality is going to suffer because of a ridiculous date. These things we know.

There's no avoiding them, but you can mitigate some of the risk to your future self by being intentional about how you cut scope and feature sets.

At my job configuration is a bad word. It takes extra development and adds complexity for the customer. It frequently isn't even needed. If you intentionally hardcode areas of your app, you speed up development while avoiding the complexities of configuration (for now).

Maybe that piece of config wasn't needed after all?

Thinking with intentionality will open up ideas to powerful shortcuts that maybe should have been the solution after all.

DON'T: Give Up

It can be hard to stay motivated when you're asked to do "unforgivable things" to your software. You feel a sense of pride and ownership in the software you build and somebody is asking you to cut corners.

There's a point on the fast vs right scale that you cannot go past. Things won't work, your app simply won't be your app.

Push back.

You're in the position you're in for a reason. There's trust in your decision making and reasoning. If you're asked to do too much, tell them it won't work.

As with everything in life, software is about compromise. Negotiate some give and take. People are almost always willing to work with you.

Conclusion

Software is a delicate balance of too much/just right/not enough.

It really depends on where you are in the lifecycle of a product. Startups should do as little as possible as fast as possible to get their product out on the market. They are highly iterative and responsive to the feedback of their customers.

Other companies who have made their way with waterfall development tend to be on the opposite side of the scale. They hone and build until it's done before sending it out.

There is no right or wrong way to all of this. But what you need to remember is the more shortcuts you take, the more quality will suffer.

So which report do you want to see yourself in? The report saying your company missed a date but delivered solid software or the one saying you hit the date but delivered an unstable product?

The choice is yours.