I’m working on a project whose deadline has already passed. I wish I could say this is unusual, but it’s not. I’ve been in this situation many times before, on multiple projects, at multiple companies. Whenever it happens, my reaction always starts out the same. I feel stressed and the need to work harder. Then the rest of my brain catches up and I start to think about how to deal with the situation.
My approach to this has changed over the years. I used to focus on how to get the work done at all costs, using tactics like working extra hours and testing my changes in smaller increments. As I gained an appreciation for maintainable code, I added refactoring to my arsenal of reactions. Today I pause to look around a little before diving back in. I want to be very aware of how my work fits into the bigger picture.
Many employers publish a list of their company values. These are often vague documents that talk about positive ideals like “teamwork” and “excellence”. Sometimes people add “fun” to the list, which has a nice human feeling quality to it. In addition to the company-wide values, there are also values associated with the smaller groups of people who work together. These values are occasionally enumerated in a team wiki but usually just shared verbally like tribal knowledge.
In theory I should be able to compare my work to the list and see everything line up. Teamwork? Check. Excellence? Sure. “Welcome changing requirements, even late in development.” I guess…
The trouble comes when business needs conflict with engineering realities. A product-driven business needs a working product. The market has a temporary sweet spot, where a certain feature set delivered during a specific window of opportunity will provide a significant amount of value to a select group of people. All of this translates into a deadline for me and my code.
Engineering is hard work. It’s difficult to predict how long it will take to build a complex system. Even if my team and I execute perfectly, the project cannot be reduced beyond its minimum viable product. Either the business waits for its completion or it continues on without it. Someone gets to choose.
Given this pressure, it’s very tempting to start cutting corners. Once a few teams start doing that, it quickly becomes the company culture. We need to finish by a certain date, so let’s skip the unit tests. We had planned to build a continuous integration system, but now we’re out of time, so let’s skip that too. We had intended to automate a tedious process, but it’s easy to do it by hand, so we’ll save that for another day. These decisions have huge future consequences.
Everyone knows this, but what can we do about it? One method is to be very careful while planning new work, so potential risks are identified early. Another method is to frequently reevaluate the status of a project and keep stakeholders in the loop, so the backlog of work can be kept accurate. Drop tasks that aren’t strictly needed. Prioritize. Make it obvious when a task is blocked and proactively address it. Don’t neglect technical debt. But all of this is beside the point. At the end of the day, we have to acknowledge the differences between our culture (get stuff done soon) and our stated values (get stuff done right).
So as I chase after my arbitrary deadline, I ponder where my Git commits are going. I can see that they’re changing text in a source code repository. That’s a good start. Those same commits are also consuming disk space, using electricity, racking up licensing fees, saving time, earning revenue, moving Gantt charts, and impacting the culture of my coworkers. I have a responsibility to make sure that everyone impacted by the change is aware of how it impacts the whole ecosystem.
Someone will choose whether to wait for my project to be completed or not, based on whatever information has reached them by that time. If I do my job well, that will be an easy decision. I’m not sure who it will be, but someone gets to choose.