How long is two hours? How big is a block of two hours? Is time really shaped like a block? Is your first fresh hour in the morning the same length of time as the last hour of a long day? What exactly makes a day long, anyway? Hit the treadmill for five minutes. Now I’m giving you five minutes to fix a bug. Which five minutes will last longer?
We tend to treat time as if we understand it, as if we’ve wrangled it and confined it into neat little boxes. We’ve parceled time out into equal and measurable chunks in our planners and organizers. The impression of the clock misleads us into thinking that we could highlight a given slice anywhere on its face and it would always be treated equally.
There is a problem in software consulting, and that is the equation of units of time to units of labor. They do not share a 1 to 1 relationship, yet we surround ourselves with time-based estimates and contracts, we track our time in itemized hours, and measure this time spent on a given project. We conduct our work as if a linear relationship between the two exists.
Reports, estimates, and contracts certainly serve their purpose, but they too often distract us from the value of our talent, and refract our attitude about true productivity. Managers and developers alike begin to believe that the goal is to fit more tasks into less time. Or, similarly, if X amount of work can be done in six hours, then imagine how much could be done in two more hours. Never you mind the state of the developer’s mental energy after a solid six hours in the zone.
This is often mislabeled as efficiency and productivity. The mentality encouraged by these misomers is harmful to the developer, the product, the developer’s relationship to management, and the way clients think about the value of software.
We should not merely be spending our time on tasks, squeezing a maximum completion rate per unit of time, but investing our time, as much as we can, into each task.
Douglas Rushkoff, an established media theorist, wrote about what he calls overwinding and spring-loading in his book, Present Shock, in 2013.
Overwinding is the act of trying to load as much information into as little time as possible for rapid, instant gratification.
Spring-loading is the investment of time into a product or process, as preparation for future use. All of the time and quality invested is released upon execution in crucial moments.
An example Rushkoff gives in his book is about disaster relief teams that have fully equipped, pop-up medical facilities that they can deploy in hours, anywhere in the world, in the heat of a crisis.
So what are we doing to invest our time in our tasks? The primary value of software is its ability to change. Its secondary value is its ability to function according to customer specs.
Read that again. The primary value of software is its ability to change, not its completion to spec. Why? Because the spec is constantly changing.
It’s so easy to treat code as something we’ll just knock out, throw up on a server, mark ‘complete’ in a task manager, and move on, trusting those lines of code to go on and on forever doing what we wrote them to do.
As long as someone is using the software, then someone will ask for changes to it. We must be vigilant of our system design choices such that they can anticipate change.
There are lots of general, best practice guidelines out there. Acronyms like SOLID, CQS, SOA, DCI, and so on. They’re helpful strategies for identifying code smells and developing your own methods for pruning your code. It doesn’t matter so much which ones you like, or if you don’t care for any of them. The point is that you take the time to think about the impact and design of the code.
In crafts such as visual design, writing, photography, and film, the most important skill is editing. The artist removes everything they possibly can while preserving the message and artistic vision. This ought to be true of the code we write.
We should be striving to inspect our systems from different angles, to diligently remove or repair whatever isn’t contributing to effective communication. We can trust that sharpened editing skills will continue to serve us, even as all the subjective and trendy ideas about best practices shift from this to that.
Let us pack our time now, so that we may utilize it in spades later. When the class, module, method, or system that we write is unpacked–that is, executed at run time, implemented in the codebase, or when someone requests changes–we want all of that time and quality to spring back open for us.
The code opens up clearly, with guides and sign posts, maps, and well-driven trails for us to make our way. We took the time to use team-standard formatting, we followed established conventions (and we updated obsolete ones), our classes and functions have descriptive and useful names. The implementation is clear and does not force us to carry mental burdens about internal details. The system doesn’t resist us when it’s time to make changes.
However, if we have rushed through a handful of tasks, then the code that we produced will not spring open with much of any time, and we’ll find ourselves with no time left. We’ll be racing tight deadlines and staying late way past our usual work shift, chasing bug after bug, lost in a labyrinth of poorly communicated code.
If you’re committed to agile project management, but you’re not vigilant of long-term code management, then I urge you to question yourself why. Perhaps your first instinct is to say “better is the enemy of done.” Hey, I know the code can always be better, but are you really sure about when you’re done? How often does that ‘done’ code keep coming back to you to fix?
If you find yourself saying, “I don’t have the time for that,” take a second to look at your habits. People who use this excuse tend not to have very good habits. Instead of “maximizing efficiency” by completing tasks, maximize your efficiency of using better habits. As you grow, it will become second nature. I can promise you, that if you take your time, then you will always have the time.