Slow Down, Finish Faster

This piece is geared more towards those starting their career in software development. And I’ll start with the conclusion.

S L O W . . . D O W N !

Okay. Now I get to rant a bit on the importance of slowing down in order to finish faster.

First of all, let’s define what “finish” means. Finish means done. It means that you handed over the homework to your teacher, and there’s no going back. When a sprinter finishes a race, the race is over. It’s done. There’s no going back the finish line to sprint another meter or so. No, it’s done. That’s it. There’s only going forward. There’s no turning back. There’s no “90% finish”. Finish is boolean: it’s either finished or it’s not. In short, when you finish a task, it means that you’re eventually open to take on another task…now.

Whew.

Now, what I mean by “finish faster” is that the flow of working and delivering a task should be acyclic. There too there’s no going back. Basically, you deliver a task once, and the overall result is accepted by the client. This means that there’s no “opportunity” to fix a bug, because there’s not supposed to be a bug in the first place. If there is a need to go back and rework the task, it’s only because the client is changing his or her mind about the initial request AFTER seeing what you’ve successfully delivered that meets 100% of the initial requirements.

Now that we have a baseline for “finish” and an understanding for “finish faster”, let’s see how to get there.

Understand all the variables at play

Software development is pretty much like working on a puzzle. Each piece in a puzzle is a component that collaborates with other components in order to produce one big result: an image of a river flowing down a valley. Or something close enough. In order to achieve the objective, the first thing one must do when working on a puzzle is making sure that each piece is facing the proper way up so that you can see what you’re working with. In software development, a piece in the puzzle is akin to a requirement. You must make sure that you can “see” the requirement for what it is, and how it fits in the overall puzzle, which is normally the system to build.

In other words, a piece in a puzzle is akin to variable in a requirement.

When working on a puzzle, we try a piece in different places and in different angles. “Does it fit here?”, “Will it fit there?”, “Does it goes with that piece?”, “Isn’t there something better to watch on Netflix than trying to work on this puzzle?”. So many tries. So many failures. Yet, we continue and don’t give up. It’s the same thing about requirements. You need to ask questions in order to understand them. Some questions will sound dumb (those are sometimes the best questions actually). Some questions will sound redundant (those questions assert that you actually get the same answer from different viewpoints). Some questions will sound like maybe they shouldn’t have to be asked…but you ask them anyway, because of this reason: you don’t want to assume anything. Don’t assume. Stop assuming. Stop guessing what the variables are, and work towards finding out their values by asking all the questions of the world regarding the requirement to the right people. That’s right…people. Plural. Try to understand the requirement from diverse point of views: the end user, the UI architect, the business analyst, your fellow developers.

I once was at a meeting with a dozen of people during a grooming for a future sprint. While people around the table were discussing about the estimation for a particular task, I started to ask questions that haven’t been asked before, because in my head the requirement was understood at 85%. And I tell myself that if I didn’t fully understood a requirement, chances are that others around the table haven’t either. A requirement must be understood at 100%. If it’s not, chances are that the requirement is not clear, nor concise, nor complete. There’s no point in starting a race if we don’t know when or where it’s supposed to finish. Running without an objective is a waste of time and energy…well, unless you’re doing cross-fit. Anyhow, some of the questions I asked were so simple, that a five year-old could have asked them too. The funny…or sad part about this is that I couldn’t get an answer for my simple question because simply no one had the answer. How can we go about estimating something that is A) not fully understood, and B) that is not clear, concise and complete?

In short, don’t start the work unless, and until all the variables are known…as much as possible. Look at it this way: how would you feel working on a 1,000 pieces Lego or puzzle, and just when you’re about done, you realize that there’s one piece missing. Or maybe two. Or three. Would you say that the Lego or puzzle is complete? I wouldn’t. I’d be frustrated. It means that I wasted time and energy that I could’ve directed somewhere else. Sure, you might say “Well, it’s 98% done”. But I don’t want a 98% done Millennium Falcon Lego. I want the whole thing. Why? Because it’s supposed to be whole. It’s that simple.

Understand who are the characters involved

A requirement starts somewhere. Most of the time, it starts in the head of someone while he or she is hand washing the dishes after supper. That idea in the mind then flows through communication and collaboration with a string of people. If you want to properly understand a requirement, you need to put your detective hat on and seek the people in that string. Go and meet each one of them. Politely ask them for their time. Remember that in order for you to help them, they need to help you too with the understanding part of the requirement. Start by asking them the most important question of the universe: Why?

“Why do this?” “Why is it important to you?” “Why do this now?” Try to seek the reason, the root cause of the requirement. Going back to my earlier example of the sprinter, imagine that he or she finishes a race and breaks the world record…at a qualifying practice for a championship. There’s no medals being award in the event. There’s no NBC camera crew filming the thing. So the sprinter just broke a world record, and it didn’t make an impact. It should’ve made an impact in the news, but it didn’t because the context prevented the impact from taking a full effect. That being said, nothing sucks more in life than working on something that turns out to be useless.

After asking the why’s, it’s time to ask for the “who’s”. Who are you doing this for exactly? At the City of Montreal (where I currently work), the who is normally the citizens. So that’s good…now that I know whom I’m doing this for, it gives me an affirmation, a purpose to do this work well.

The “who?” amplifies the “why?” by giving it purpose. Where the “why?” gives a reason, the “who?” gives a purpose.

Understand the requirements for the requirement

At this point, you haven’t written a single line of code. And that’s okay. There’s no point in writing code unless you know why you’re writing it. Every requirement in a software project requires two things from the people that will develop it: business domain knowledge, and technical knowledge.

The former deals about knowing how your business domain works. The latter relates to the tools you’ll use to implement the requirement in code. Whereas you can always ask a business analyst to help you understand something about the business, you’re pretty much on your own when it comes to implementing the requirement with tools and technologies. You want to make sure that you’re comfortable in using them, and much more comfortable in taking the time to read the documentations when necessary. Don’t just Stackoverflow everything. Instead, question everything. Take the time to think for yourself how you should go about solving a problem. Avoid copy pasting things because you read that it works. Stop that. If you’re new in the industry, that awful practice will hinder your credibility faster than lightning.

Remember this: it took almost 14 years to complete the work of the Twin Towers in New York (World Trade Center). However, it took just a few minutes to tear them down to ashes. That’s how credibility works too. Don’t go so fast that you risk ruining your credibility. It’s one of the most important possessions in your career. And it should be treated as such.

When you don’t understand something that you’re doing, stop. Don’t go further. Stop and ask for directions. Stop and re-evaluate your progression. Did you miss a turn? Remember that software is one of those things that is easy to undo and redo. But there’s a catch: it gets harder the further you’re down the line. So if you catch a mistake sooner, stop and take the time to correct it. If you think or feel like there’s some kind of mistake, stop and take the time to find out about it.

Wrapping up

If you want to finish fast and avoid going back fixing bugs, you have to slow down. If you’re pressed for time to finish something, raise the issue with the project manager. We don’t always make the best decisions, but we each have the power to say so, to talk about it when a problem arise. Though your fingers are important to write code, your voice is the best tool in your kit. Remember this: the absolute worse investment that comes out from software development is your body. Your physical body. Your neck. Your back. Your wrists. Your legs. Your eyes. Your body will suffer in this line of work. It’s not physically exhaustive, but it is sometimes physically painful. And whatever causes pain to the body after a long time can also cause issues with the mind, the spirit, in such a way that a burnout isn’t too far ahead. Don’t race yourself to a burnout or a weaker desire to work in this creative field. Slow down. Know what you’re doing before you start typing the first line of code. Make sure that you understand what needs to be built. If what needs to be built isn’t 100% sure by anyone, then accept the reality that it might have to be built incrementally. It’s not the ideal, but sometimes it’s real. So when that happens, make sure to understand the foundation of what is being built incrementally by applying what I’m recommending at each increment.

If you want to finish faster, slow down.

Slow down.

Slow.

Down.