Things were very hand-to-mouth when I started as the third developer in a startup I used to work at. There were fires to put out for myriad reasons almost every week, and any seasonal uptick would put us on our toes.
Notably, all inbound cash flow was dependent on selling copy-protected products on our website, which required a license purchased from our self-hosted online store. So, that group message from our support engineering during one weekend was not trivial:
How long have our product download links been down?
Not less so on another occasion when he asked:
How long has our online store been down?
We didn’t know. After putting out the immediate fire, we would gather the data by feeling our way through the history that no one had made explicit in any way.
This went on for a few years.
The startup holds discount sales biyearly: Easter and Black Friday sales. They account for a significant share of the yearly sales, and thus, we used to have these evenings of half-paid time to stay at office and be alert in case anything broke down. It was a relaxed evening of hanging out together for most parts. On one occasion, as I didn’t have any fires to attend to and had recently witnessed one of those link outages, I wondered how hard could it be to have an automated integration for link checking - a heartbeat mechanism. I endeavoured to create it in a language I didn’t use, on a cloud platform I was unfamiliar with, within an hour or so during the evening.
The little heartbeat service ran smoothly on a free-tier Heroku instance for several years. It was very scruffy. Had we been more meticulous about addressing the downtime - calling in a meeting and planning session to address the issue properly - it would not have met the critical threshold for action. Instead, it would have been pushed back for months or even years, as seemed customary with anything that was not an immediate priority. Timeboxing it for an evening resulted in a mostly working system while I was socialising, and I finished just in time to hit the sauna!
The haphazardly assembled service provided data and validation for when it was replaced with a more thought-out and robust system. Similar integrations and processes eventually smoothed out the fire hazards, making them a thing of the past. Inadvertently, those after-work hangouts also withered away as the startup grew in size, changing its structure and eliminating the semi-paid time; now, no one attends them.
The team I worked with was highly competent, but simultaneously fresh out of university, and at times we would beat around the bush arguing for the same point using different words. Communicating my intentions got easier when I realized that this pattern is commonly known and used in software development as Timeboxing. As a counterpoint, imagine estimating a task to your superior: “I’m not going to do a proper job on this task, but instead just wing it and see what sticks for an hour or two, and leave it undone if that doesn’t work”. It can be taken the wrong way, while it’s probably quite straightforward going with: “I’ll timebox it for the afternoon and let you know how it goes”.
Terms like timeboxing, sandboxing, or prototyping are handles for methods and processes. Without them, the Osmo Wiio laws can get unruly: misinterpretations are nigh. It’s like music theory in the sense that knowing the nomenclature and jargon helps communicate intentions accurately without accidentally sounding uninterested or incompetent. Giving in to or resisting these word games is not about integrity but clear communication. It helps to centre around a concept and elaborate your version of it when needed - the trade-off threshold pivots on weighing whether the loadedness of the term overburdens the gains of concise communication.
How unambiguous is timeboxing? Like most terms in software engineering, timeboxing is subject to various interpretations. Agile principles describe timeboxing as a sequenced time-allotting method, and even Scrum sprints can be referred to as timeboxes. Furthermore, some refer to personal daily timeboxes as time-blocking. The spelling changes according to the author as well. What remains is a fixed time frame.
To distinguish itself from these unrelated connotations - more specifically, by allocating long time frames or sequences of timeboxes - adlib timeboxing redefines timeboxing with specific traits. Adlib timeboxing is typically a personal and case-by-case coordination pattern, considering that prioritising feedback over task completion is an option.
Adlib timeboxing originated from witnessing summer interns completing, or at least evaluating, tasks with their happy-go-lucky innocence, while a senior developer was still considering the complications the details might entail. It is best used sparingly as a lightweight strategy for low-hanging fruit or intermediary validation steps that are on the cusp of gaining critical weight to become actionable. In other words, for tasks that are beneficial or necessary but don’t have an immediate deadline.
Timeboxing has caveats as it trades off resources or scope for a fixed time frame. First, it introduces specific cognitive load, and second, it is delicate to delays. The mental load of reconsidering trade-offs and consequently reordering subtask priorities can lead to overall progress stagnation in fine-grained project plans or multitasking, particularly in the face of compounding complexity. Additionally, delays can disrupt the flow of a timebox, for example, when waiting for responses or other cooperative actions from parties whose schedules are unknown.
My focus here has been to introduce the concept of a specific timeboxing practice, adlib timeboxing, which overcomes hesitation and validates requirements through action, rather than just planning. Furthermore, I don’t consider timeboxing extensively an efficient practice, as it essentially sets hard deadlines on everything. Having hard deadlines for everything leads to not having any real deadlines; it is “the boy who cried wolf” in a corporate setting. Having some slack is very beneficial for progress.
Context
Decision making in software development in the face of blocking uncertainties. It could be that it can be done in a burst, or it could take a while if it gets complicated.
Problem / Message
- Wasting time with second-guessing and unnecessary planning.
- Getting stuck with a task feeling it’s almost done, and it stretches on for far longer than anticipated.
- Giving an impression of either lacking interest or competence.
- Being too fastidious about overpromising and underdelivering.
- Good enough, fast enough.
Try timeboxing. There are other ways, too.
How it works
- Setting a time limit mitigates
- Sunken cost fallacy type “just one more thing” sequence
- Approaching just what’s necessary
- Evaluating implementation details
Why it works
- Allows complete focus on the task without losing track of the time and deadlines
- Let’s you experiment and try the quickest route, the smallest stab
When has it worked
- Abstract
- Benchmarking
- Prototyping
- Brainstorming
- Studying
- Concrete
- Trying things for this blog
- Non-critical bug hunting on an unfamiliar platform
- Evaluating optimization options
- Routine groundhog day tasks without immediate deadline
When has it not worked / does not work
- The scope is tight allowing no slack
- For example, it’s a “must” priority that has to be finished without compromising quality
- When cognitive overhead compounds hindering progress
- For example, using it unnecessarily for every task