Understand why before how

Imagine that your manager or project manager tells you they are considering making the background of a landing page a video instead of an image. They're about to hire a consultant to make that video. They want to know from you how difficult it would be to embed that video. What is your first reaction? Most engineers start thinking about the how right away, and then diligently provide a timeline estimate. This is a mistake. Your first instinct should always be to understand the why first. Is the goal to increase user engagement? What will the added latency of a video load do to engagement? Are you going to need additional technical effort to make sure that slower devices (e.g. mobile phones on 3G) aren't negatively impacted by that latency? Do they just want the page to feel more dynamic? Is there is a Javascript-only solution to this problem, that can be delivered in a few KB instead of a few MB?

You can't fully understand how until you understand why

In many cases, without understanding the reason for the request, you're going to miss important details about how to perform that request. As an engineer, it's easy to assume your job is just to translate what the business wants into code. Unfortunately, the business doesn't really know what they want, they just have a hazy idea of what problem they need to solve. It's our job to help them figure out exactly what they want. Without understanding why, you can't understand how. Understanding why gives you the best clarifying questions to ask. 

Consider the previous example: once you understand the why, the technical requirements could completely change. You may even realize that the task will do the opposite of what the business wants (video = poor load speed = decreased engagement). In this case, you might have saved the business an expensive video production, an expensive experiment to test the results, and an expensive reduction in user engagement. Without understanding why, many of these details may have been missed.

This applies to all types of tasks

A nuanced understanding of the why behind a request can affect the way you approach all kinds of problems, not just user-facing ones. It affects the naming of variables, classes, and database fields. It affects trade-off decisions between latency, simplicity, and maintainability. Every decision should be made with the perspective of "why does the business want this?" It will help you write better code that better communicates business intentions to future maintainers.

Don't be afraid to ask, it will be worth the time

Unless there's an urgent production issue, I always make sure I understand the why behind a request first. In the long run, it always turns out to be worth it. This style of thinking has saved businesses I've worked for thousands of hours in development on unneeded work, in addition to other costs. Even for simple requests that should only take a few hours, I make sure I understand the why before figuring out the how.

Comments

Post a Comment

Popular posts from this blog

Feature design process

Every time I start work on a new feature, these are the steps I follow to increase the likelihood it will either be a success or never get released. Understand Why This is always the first step I take because it determines all the follow-up steps. You can't understand how until you understand why . It's often valuable to follow the five whys method. Make sure you really understand the root cause, not just the symptom. If it was raining and you had a leak in the roof of your house, would your first step be to mop up the water, or would it be to stop the leak? The answer depends on the size of the leak. Too many solutions fix one symptom without fixing the real problem. On the other end of the spectrum, it's easy to get bogged down in fixing root causes that aren't worth the effort. You don't always have to solve the root cause, you just need to know what it is. Come up with at least two solutions Engineers are often handed a solution instead of a problem. I believe ...
Read more

The many benefits of working in small increments

If you're a software engineer, you've likely heard of the Single Responsibility Principle  (SRP). I believe it's the single most important principle in software engineering. The simple explanation is that one object should do only one thing and do it well. Having a well defined single responsibility makes code easier to understand, change, delete, and test. The complexity of code grows exponentially with size. Two 100 line classes, with proper segregation of responsibility, are significantly easier to understand than a single 200 line one. SRP is the "work in small increments" principle for code, and the same exponential growth in complexity applies to much more than just code. Working in small increments shortens the feedback cycle, which is the best thing any organization can do to increase its velocity. Small Tasks Every task should be small - small enough to complete in less than two weeks, ideally less than two days. Small tasks are easier to write, understan...
Read more

The two qualities of great software architecture

Great software architecture solves a present business need and is easy to change when business needs change. Software architects have developed a number of heuristics: patterns and principles that help to achieve these goals. A software engineer that applies but does not fully understand these heuristics may implement them in situations that run counter to the goal. To write great software, it's important to understand how each pattern and principle contributes to the goal. Entire books have been written on most of these subjects. This is intended to be a brief overview, not an exhaustive list or explanation.  Solving a present business need Most users could look at an application and tell you whether it solves a present business need, aside from some of the more subtle nuances. For example, an application may solve one need but is not secure, which is usually one of the business requirements. Some of the criteria that may roll up to this metric, depending on your business: User ex...
Read more