“You don’t have a time machine— you’re living the same twenty-four hours we all are. You can barely make it through your day with all the current things there are to do; when is “someday” finally going to arrive? The answer is, of course, never. Today is it.” – Andrew J. Mellen, “Unstuff Your Life!”
If you’re a software professional, you’ve probably been faced with (or at least affected by) a quintessential architectural decision: Do you take the time hit to do something the “right way” now or do you settle for a less-desirable, “good enough” solution?
I’ve been both an active participant and a passive bystander in many such debates. It always plays out the same way: Everyone wants to do the right thing now, but most acknowledge that there just isn’t time (except for that one guy who wants to “make time” over the weekend). No one wants the “good enough” solution, but they rationalize it by saying that “someday” they’ll circle back and do it the right way. They may even get specific, but it’s usually after or when something – “after this big release” or “when we have more resources.”
Unfortunately, these people are lying.
Now you might be thinking, “that’s a little harsh.” No, it’s not. If I felt the least bit hesitant or apologetic about that sentence, I wouldn’t have given it its own paragraph. Remember that I’m not throwing stones – I’ve been in that spot and said those things, too. But when I think back to every case where I or my team intended to revisit something and do what we should have done in the first place, I can quantify how often that actually happened. Zero percent.
Early in my career, I let myself off the hook by saying that I was naive or there were circumstances outside of my control that prevented us from coming back and doing the right thing. But by now I can be honest with myself and admit that I had my doubts that “someday” would ever come when I said it. Deep down I knew that I was buying into the lie. I was lying to myself and my team.
We could analyze why this “mythical land where time stands still” (as Mellen calls it) never comes, but don’t we already know the answer? Of course, when weighing two choices, “already done” will always win. And that assumes that the topic even comes up for debate again! More often, that thing you were going to do is simply forgotten altogether, or added to the backburner list of guilt-inducing things you’d like to do but never will. If those things accumulate and begin to weigh you down, you might even be tempted to move on to the next job and let them become someone else’s problem.
So my advice must be to do it the “right way” from the get-go, right? Actually, no. You don’t have time for that, remember? I believe you.
But instead of buying into the someday myth, I propose a third option: Plan the someday. Be explicit about what you are going to do and when you are going to do it. “We will come back and write unit tests for that” or “I will fix that concurrency issue.” When, specifically? Don’t wonder it to yourself – ask it out loud and commit to it as a team.
A conditional or relative when will not suffice – it can’t depend on some release deadline or an additional team member that you hope to hire. It can’t be a user story or a bug either – these devices are usually only effective in illustrating the technical debt to your managers. They don’t ensure that the work will actually get done, because your managers are pressured to show value to their managers and other priorities will prevail. At the risk of sounding cynical, a story or bug of this nature is typically only given attention when an important customer (or prospective customer) notices and complains about it.
Enter the calendar.
I believe that there is no resource more precious than time, so it follows that there is no tool more powerful than the calendar. The calendar does not lie. Ever. You may not always like what it tells you, but it does not care. It says, “Tomorrow is your mom’s birthday and you have one day left to figure out what you’re getting her. Good luck with that!” @#F*$%! Thanks, calendar. You’re super helpful.
By putting your intentions on a calendar, preferably one that everyone can see regularly, you are committing to act. You will rework the logging layer of your API, or you will fix the auto-generated documentation bug, or whatever. You will do it, and since you think it will take n days (n + (n/5) to be safe), you put that on the calendar. When sprint or release planning time comes around, you will look at the calendar and plan on accomplishing less because you will be doing that thing.
Keep in mind that I’m a “tell, don’t ask” type of person, and occasionally this can get me into trouble. User stories and bugs effectively ask your managers if you can do this work, whereas scheduling the work yourself tells your managers that you are doing it and that they need to support you in that endeavor. As such, use this strategy with care. It is helpful if your manager was part of the “right way vs good enough” discussion when it happened. Make every effort to bring them into it then (or right after), so that you can remind them that we aaaaaaall agreed on this and that it’s not a surprise.
It also helps if you move your hands in an outward-circling kumbaya sort of way when you say it.
In part two of this post, I’ll explore one of my favorite calendars: Google calendar and its API. Google has thoroughly and elegantly solved the hard parts of a time-management solution (like timezones, internationalization, conflicts, and authorization) so you can focus on the fun parts (like integration and… ooh, colors!). Don’t reinvent the calendar wheel – harness its power to beat the “someday” lie into submission forever. Rawr!
Until then, I hope that I’ve sufficiently warned you of the perils of “someday.” Come to think of it, I didn’t even go into its optimistic flavor – coding ahead (aka gold plating) your application with features because they might be needed someday. This is the opposite of technical debt, where you end up with (arguably) too much code instead of too little. The goal is to strike the right balance between these two extremes, so think hard about what is needed or wanted, and by whom. “We need to add this thing because we might need to do this other thing… someday.” Really? No. Just… stop. Stop overcomplicating. Stop making excuses. Stop starting and start finishing. Stop letting “someday” ruin today.
| Reference: | Someday Is a Lie from our JCG partner Lyndsey Padget at the Keyhole Software blog. |
