Chronos Blog

Should Software Developers Estimate?

2021-12-27T00:00:00-06:00

The Problem With “No Estimates”
The Biggest Loser in the “No Estimates” Game
“Yes Estimates” and the Software Developer

The Problem With “No Estimates”

A significant portion of the software industry has developed techniques and processes to avoid estimation.

Agile methodologies, for example, commonly replace time-scale estimation units with alternate vocabulary like “T-shirt sizes” and “story points”; poker planning is another example which removes individuals providing estimates in favor of collective, team-based task and story sizing.

Of course, these methodologies have their motivations: they’re a response to repeated failed attempts at estimating and predicting software projects. Software businesses that want to remain competitive must have at least some strategy for deducing software costs and delivery times. To many, these “No Estimates” processes seem to be the best options at the table.

But there’s a root problem with these methods. They’re compensatory: they ultimately exist to cover for a lack of skill set among members of the team and the organization. Software developers are notoriously bad at estimating, and many are simply loath to give estimates at all.

This lack of the estimation skill set among developers is completely understandable:

A vast majority of software developers are not taught estimation skills, neither in industry nor academia.
Estimates are almost ubiquitously misunderstood by business managers, who misuse estimates to make unreasonable commitments—sometimes coercively, but often with well-meaning intentions. In turn, estimates (and estimators) are frequently scapegoated when such commitments are inevitably failed to be met.

These two conditions alone create a destructive feedback loop in which estimating becomes a taboo, almost dangerous, endeavor. No wonder the industry trend is to shy away from estimates.

But we have a paradox: businesses—from nascent startups to established enterprises—require predictability, and yet predictions (estimation) from individuals are politicized and ultimately shunned.

“No Estimates” methodologies are an attempt to reconcile this paradox by treating the predictability problem with kid gloves—absolve individuals from giving estimates while contorting ways to extrapolate estimates “at the top”.

The Biggest Loser in the “No Estimates” Game

The software industry has devised many variations of the “No Estimates”¹ process, some more sophisticated than others, but all effectively the same: all an attempt to “approximate” and “pad” over a team’s inability to produce and manage estimates explicitly.

One might say, so what? Isn’t this approach sufficient? Why not embrace the “No Estimates” processes, and carry on?

For businesses and management, these processes are notoriously inconsistent: they (sometimes) work when they work, but often fail from iteration to iteration. Furthermore, they are sensitive to project instability such as personnel changes, etc. And because these processes purposefully obfuscate or hide the terms of the problem (i.e., time), they cloud visibility, leaving teams and their managers wondering why this week’s or month’s sprint was such a disaster when the last one was delivered precisely on time².

The ultimate reason for a team’s failure or success on any point of skill, of course, should be obvious:

A team is as good as its constituent individuals—e.g., a team’s programming ability is as good as the programming skills of any one of its team members; the same is true for a team’s estimation ability.
Any methodology or process that explicitly removes the estimation responsibility from each team member is guaranteed to not develop that skill set in its team members.

So while “No Estimates” processes may assist a specific team in hobbling through occasional predictability, the software developer is the biggest loser in these methodologies—by design, these processes leave a crucial individual skill set entirely undeveloped in each individual team member.

Not only does this deficit in skill set place a limit on one’s overall expertise, it is increasingly a career limiter especially in the context of other developers that do cultivate the skill set.³

“Yes Estimates” and the Software Developer

Should software developers estimate? That is, is the estimation skill set worth learning, practicing and cultivating?

The truth is—at least for time being—it is a seller’s market for software developers. A modicum of technical skill set can make you reasonably competitive in today’s general hiring market.

Still, this isn’t enough to become complacent. As the software industry matures and as technology advances remain apace, predictability in software delivery—and the skill set that can produce it—is becoming increasingly significant for market participants across the board.

Ultimately, nothing beats an intrinsic motivation to master one’s craft beyond just optimizing your paycheck. More often than not, the estimation skill set is simply in the blind spot of software developers that otherwise want to master their craft.

In a healthy businesses, managerial stakeholders (product, project, and people managers, e.g.) quickly zero in on programmers that can technically deliver with predictability.

Pure technical ability is increasingly becoming table stakes. Highly capable and technical programmers are “managed off” mission critical projects precisely because they can’t predictably deliver. Conversely, developers who are willing and, crucially, able to give reliable estimates can expect to rise above others to have the attention of business leaders.⁴

One major “secret” to advancing in a technical career is learning how to give accurate estimates.⁵

Observations like this one have been made by experienced practitioners for a long while, but are increasingly entering the zeitgeist. The estimation skill set grows increasingly relevant as more software developers acquire and leverage it.

The good news is that—in spite of whatever upstream process one’s team uses to manage their “sprints” and deliveries—software developers can learn, practice, and master the estimation skill set on their own, in private, independent of and adjacent to their team’s process.

This is worth doing. Estimation is a transferable skill set. The skill set can be practiced and cultivated even by software developers that aren’t in business contexts yet able to leverage predictability. By not practicing the skill set, naturally it won’t be there in contexts where it can be leveraged.

Given that estimations are often exploited and politicized, practicing estimation in private, as a local activity is an ideal way to improve. Even for experienced estimators, a large part of the process will always be personal. It is very easy to practice, observe results, and iterate alone to perfect the skill.

Specifically how to estimate and how to grow the estimation skill set is crucial to the argument posited here. A future post will soon elaborate on how to estimate in detail.

Footnotes

¹ You will see even the “Yes Estimates” camp fall into the trap when giving estimates but effectively negating them with arbitrary padding factors and number fuzzing.

² And why they didn’t notice the approaching failure until the last minute.

³ The good news is that the skill set can be learned. More on how to learn estimation and grow the skill set will come in a future post.

⁴ Able is the key word here. Estimation is a skill set. You’ll know when you’ve developed the skill set enough to give confident estimates at the right time. A future blog post will break down the path to developing this skill set.

⁵ From https://jacobian.org/2021/may/20/estimation/.

You’re Already Estimating Your Software Projects

2021-12-22T00:00:00-06:00

You Are Always Estimating
Why Does This Matter?
How Many Candies Does Your Code Have?
Getting Back on Track

The industry debate over software estimation is one of false alternatives: either you are pro-estimation or you are anti-estimation and that is effectively the end of the story.¹

Unfortunately this dichotomy is a complete misdirection, confounds understanding, and ultimately leaves teams and organizations throwing their hands up in the air and missing out on practical ways to significantly reduce risk of failure in their software projects.

The truth is that everyone estimates their software projects—in actual time units!—whether they are fully aware of it, or not; the primary difference is only in whether one reifies (writes down) their estimates or not.

You Are Always Estimating

One of the most repeated, and understandable, points from anti-estimation proponents is that because estimates are inaccurate, we can conclude they’re worthless and simply ignore them. But any decision to initiate a software project (or project iteration) is ultimately rooted in some assumption about time—i.e., an estimate.

Rarely does one start a software project—or individual task for that matter—without some assumption about how long it could take. There is always an assumption about time, even if that assumption is tacit and unspoken.

When an experienced tech lead takes on a large project, she assumes some time-based scope to the work; it is rarely a good look for one’s career prospects to be working on a technical project for years with no deliverable or outcomes.
When a manager or tech lead assigns a task to a new engineer on a project, the general assumption is that the task has some time-oriented scope; it would be downright cruel to give a new junior their first task that was expected to take a year or even several months.
It goes without saying that serious entrepreneurs & startups expect to deliver something specific within the scope of their runway—even if it is a non-production artifact like a prototype to obtain a next round of funding.

Of course, we could keep going with this list. Even the most anti- of the anti-estimation set will find themselves—possibly sotto voce, behind a closed office door—asking, or answering: “How long do you think that’ll take?”

The point is this, though. There is no sensible business context in which time doesn’t matter for some software effort. We are always estimating, even if we are doing it intuitively or unconsciously.

Furthermore, we effectively estimate this way not just at the launch of a project but at each day and each week that we continue in our efforts: that is, we are always assuming that the work ahead of us fits into some reasonable scope of time. If we believed otherwise, we’d stop or switch priorities.

Why Does This Matter?

This is not just a rhetorical point. There is a fundamental misunderstanding in the popular discourse about the value of estimating, and it has dramatic cost to software delivery outcomes.

The question is not whether we should be estimating; we already are all the time. The question is whether we should be writing down our estimates as we make or revise them.

To the credit of the anti-estimation crowd, estimates are almost always inaccurate out of the gate. But here is one of the fallacies in the estimation debate: the idea that estimates must be correct before we consider them of value.

This fallacy that estimates must be initially correct is where the train first goes off the tracks for many people: it is how we, as the software industry, end up with either an outright disdain for estimates, or—worse—a purposeful distortion of estimates by replacing time-based estimates with things like “story points”, “dev units”, T-shirt sizing, and the like: i.e., fantasy units devised to purposefully hide our inaccuracies.

To understand why these reactions are so counterproductive and damaging, we should consider what would happen if we approached other areas of our work in the same manner.

How Many Candies Does Your Code Have?

Imagine if we took the same approach with our software code that we took with estimates.

Just as with estimates, our code is regularly wrong. Either because it has accidental defects or performance issues, because our understanding of our domain has changed, because the market or product requirements have evolved, etc. In all such cases, our code is wrong by any measure and requires modification.²

But unlike with estimation, we can’t avoid writing our code down; our compilers and runtime environments wouldn’t have it. We could, however, try to distort matters—as some do with estimates, when they replace time units with story points and the like—in order to limit exposing ourselves to our own inevitable code mistakes.

Instead of identifying defects, performance issues, and feature gaps in our code and working to prioritize and fix them, we could instead bucket issues together under a new pleasant-sounding name—say, “candies”—and try to make decisions within this new vocabulary.

“We discovered approximately five pieces of candy—two small and three big—in our code today.”

This sounds a lot nicer than reality, but it leaves us with much less ability to make rational and risk-reducing decisions about where we should go next. Most people would agree that defects should be prioritized and fixed each according to estimable qualities: severity, customer impact, time-to-fix, etc. By obfuscating things with an artificial vocabulary, we blindfold ourselves from rational decision-making.

Of course most of us would deem this approach to code absurd, but we don’t balk when a similar approach is applied to writing down our estimates and plans.

“We discovered four more tasks to complete before we can go live with Feature X—all T-shirt sizes Adult Medium…”

Getting Back on Track

The pro-estimates and anti-estimates debate has forced many in the industry into this absurdity.

But the truth is there is no reason to distort reality with fantastical vocabulary (story points, dev units, candies, or what-have-you), nor is there reason to entirely mask reality by pretending that we’re not estimating when we effectively are.

How did we lose our way, and how do we get back?

We lost our way because we did this:

We wrote down our plans (tasks and corresponding estimates) and then immediately “published” our upstream commitments to the initial—certainly inaccurate—version of our plan.

The equivalent if we did this with code would be announcing to customers that we were feature- or product-complete, the minute any relevant code was committed anywhere, before any completeness, quality assurance, performance testing measures were taken. Once again, most of us would consider this absurd.

So, of course, we were doomed to failure. Along the way, our actual steps diverge from our original conception. We inevitably discover new tasks and we lengthen and shorten other tasks and then blow past our commitment:

When it comes to our code, we have specific measures and tooling to protect ourselves against defects and performance issues. These measures are understood by industry and tailored uniquely for the particular teams and business contexts that leverage them. Unit testing, continuous delivery processes and tools, peer code review, including checklist-based code reviews, and so on.

These measures have all evolved to allow us to ship product to customers with explicit or implicit quality and SLA guarantees.

Planning and estimation deserve the same industry attention and evolution of tooling and processing that we’ve given to code, without any purposeful obfuscation.

The way back to sanity is to write down our plans (tasks and estimates—in real time units) and embrace, as we do with code, that they’ll be inaccurate. That is, we must not treat plans as static artifacts; we must regularly evaluate our plans and continuously refactor them. (As with code, we can leverage the help of tooling for both evaluation and refactoring.)

If we can apply processes and tooling to ensure sufficient defect rates and performance latencies within our software systems, then we can certainly apply processes and tooling to ultimately determine reliable delivery times. Both are a matter of process, tools and skill set, and we don’t need to obfuscate either.

Code processes are familiar. What processes can we apply to our plans and estimates?

Peer review. Much like peer code review, peer expertise can be applied to improve plan accuracy and task coverage.
Checklist-based review of plans. Checklist-based code reviews are powerful ways to reduce defects in shipped code. Likewise, specific mistakes in plans and estimates are frequently repeated, and reviewing plans with checklists yields greater accuracy.
History. Consulting history and applying historic on-task time to future estimates is notoriously effective at producing accurate plans and estimates. It should be pointed out that if we refactor plans as we go, we will always have a perfect historical record of our actual historical delivery times³ for leverage when making future plans and refactoring future tasks and estimates.
Scope reduction. This is one of the most underappreciated and powerful tools when reconciling plans with upstream commitments. Software development efforts frequently have enormous room for scope reduction, but attempting scope reduction without a plan and estimates is like trying to find your keys in the dark.

This is a limited list. As an industry if we pursue this path, we can evolve both industry and context-specific, personalized expertise. Some are already there and capitalizing on it.

Footnotes

¹ This plays out on Twitter, among other places, as an evergoing #yesestimates and #noestimates hashtag battle.

² Incidentally estimates are often wrong for the exact-same reasons that our code can be wrong.

³ The estimate for a task becomes precise and accurate at least at the moment we complete the task. So if we are regularly refactoring, every task will finally achieve its accurate estimate: the time it actually took to complete the task. Of course, this is a degenerate case to make a point.

Coupling and Estimation

2021-12-16T00:00:00-06:00

When I was a junior software engineer, I had a mentor who gave me two of the most valuable tools I’ve carried and still carry throughout my career.

The first tool was this one—how to break coupling:

If the left-hand side of the diagram are two components with mutual dependencies, then the right-hand side is the solution. That is, two coupled components are decoupled by introducing a third component that becomes the new dependency.

This visual formula is simple but the fundamental skill set that can leverage it effectively is deep and takes years of practice to master and become part of one’s instinctual process.

The second tool I inherited from my mentor was the practice of personal work estimation and time tracking, which, along with component decoupling, is another practice that cannot be ignored by any software practitioner wanting to move beyond “expert beginner”.

These two skill sets are intimately related; estimating the cost of manipulating decoupled systems is far cheaper and more predictable than estimating and predicting delivery within a heavily coupled system. (A future post will have to elaborate on this.)

Interestingly, both of these skill sets—decoupling and time estimation—are highly controversial in the software industry. It is not uncommon for both of these skill sets to be looked at with near disdain by certain circles of software practitioners.

I’ve always found this surprising because I believe the ultimate goal of any creative professional or business is to master time management. With more time, we can create more—thus increasing our chances of creating valuable things.

I don’t think there’d be much disagreement on this if the point were pressed. Time has always been the most limited resource, by far, when I consider my own career experience, as well as being a frequent outside observer of other creative and business endeavours—when software projects fail, it’s ultimately because of a misuse or misunderstanding about time.

There is a natural correlation between the difficulty it takes to master a skill set and its value, but I suspect also to how much resistance there is to the skill set. If someone is telling us there are riches at the top of a steep mountain but we are at the bottom, that’s going to be some bitter news.

The trick with decoupling and time estimation is that if you start valuing and practicing these tools early in your career—as you cultivate your other technical skill sets—then you’ll find yourself incrementally moving up the steep mountain instead of having at some point to look at it from the bottom to decide whether there is value up there.

Did I deliver value on June 17th?

2021-12-13T00:00:00-06:00

I developed Chronos, a task management tool, to manage my personal task lists, compare execution strategies and project future delivery dates. Specifically, I wanted a local-first task app where I could quickly update estimates, add and reorder tasks, and see a calendar of projected completion dates.

One thing I quickly realized when building Chronos was that, almost for free—so long as I kept the task estimate for the current task updated as I worked on it—Chronos would accumulate a reliable record of my historical day-to-day on task time.

I’ve been eating my own dog food in 2021, so I now have an accurate history of all of my on-task days for the year. As the year is almost to a close, now is a good time to look back and ask—professional speaking, did I do anything of value?

For fun, I’ll generate a random date from 2021 and look at my Chronos history to see what I was up to:

$ date -j -f %Y-%m-%d -v +$((RANDOM%365))d 2021-01-01 +%Y-%m-%d
2021-06-17

What was I doing on June 17th?

Here’s a screenshot of my task list in Chronos, representing some tasks that I completed in June:

Note: I’m going to have to obfuscate my data a bit, as my weekly tasks come from my full-time salaried position and I don’t wish to leak any proprietary information.

Here, I’ve blurred out the other tasks and obfuscated the focused one’s description by translating it through multiple languages, which is why it reads a bit hilariously: “Strengthen the management and development of the governor of the central bank”.

I don’t know how “central bank” came out in the translation; I’m not in the banking sector¹; but the obfuscated text at least captures the essence of what I was working on: an implementation task that wasn’t testing or bug-fixing, for example. So on June 17th, I was working directly on the implementation of an actual feature—always good to know².

A few things in the Chronos UX. To the right of the task description are task links (); in this case, one is to a Github pull request related to this task and the other to a related issue in my team’s collaboration system (Jira). This was all useful data at execution time and remains relevant for our forensic historical data analysis.

The calendar on the right shows the actual on-task days for the task. In fact, I can walk the entire lineage of my tasks for the year and see the on-task days for each one:

Once again, apologies for the blurred view—just note the calendar highlighting. As focus moves from task to task (on the left), the calendar highlights the corresponding days on-task (on the right).

One thing to glean from this blurred view is what a real-world task list looks like from a distance.

Real-world software delivery is a messy affair but, by following a simple process of using estimates to check off tasks, Chronos makes it straightforward to produce a reliable record of personal day-to-day on-task data over time.

One thing of interest with my June 17th task is that I didn’t complete the task on that day; I was interrupted and switched over to a “discovered” task related to a dependent “caching” need.

(This “caching” task is blurred out in the screenshot above, but I can see from my task lineage that I eventually returned back to my original task after a four-day interruption.)

This gives me an idea about what might account for some inaccuracies in my 2021 planning and delivery³ that I can leverage for improvement going forward.

For a simple first analysis I’ve categorized my 2021 tasks into coarse-grained categories:

Implementation (86 on-task days) design and code tasks for core features delivery
Testing (40 days) tasks to design, implement and pass unit tests
Bugs (26 days) tasks related to bug fixing post feature-delivery
Discovered (50 days) tasks (both impl and testing) not in original plan for core features

Historic data is notoriously useful for producing accurate future estimates; not only will I consult my task history when estimating future tasks, but I can also make some macro observations from this end-of-year vantage point.

Interestingly, 25% of my year was spent on discovered tasks, tasks that didn’t make it into the original plans for my core feature deliveries.

After further analysis of my task history, most of these discovered tasks occurred due to faulty assumptions about system dependency capabilities: features I’d assumed existed in core infrastructure that would serve my top-level feature delivery. This is certainly something to feed into the 2022 checklist, to improve planning accuracy where needed.

Another note of interest here is that my time spent on Testing comprised less than half of my overall Implementation tasks. Whether or not this is meaningful is highly context-specific; for my project, I know this is on the short side and I’ll likely start the year off with an audit of test coverage over the relevant features before product ships.

What else can we do with personal task data?

While this personal data is extremely valuable for estimating and predicting future outcomes, it can also be used to objectively answer questions about personal performance and throughput, including:

Negotiating compensation and career advancement. Day-to-day personal task data can also be used as an objective basis for negotiating compensation or career advancement with our manager or employer. Trying to pitch our worth without accurate data can be lossy and difficult, as otherwise we’re left stitching together an imperfect recollection of our historic on-task time.
Reviewing on-task data for self-improvement. Just as different code implementations have better or worse runtime complexities and architectural qualities, the iterative steps and strategies we spend delivering value are at risk of being severely non-optimal in time if we don’t look at them reflectively, or even have our plans reviewed by competent peers.
Keeping ourselves focused and honest. For the entrepreneurial-minded, especially—continuously evaluating our time with respect to value delivery is essential to keeping ourselves honest to our outcome objectives, and in maximizing our limited time resources. Did we spend our past year, month, or week on the right things; can we do better in the next iteration?

It can be a difficult thing to do—looking at objective personal data—as it might dispel certain imaginations of ourselves or our work. Have we been delivering in accordance to the 10x, or even 1x⁴, engineer, that we imagine ourselves to be?

Or might we surprise ourselves: maybe our pull request throughput wasn’t up from last year, but, in terms of value delivery and overall strategy, we’re up⁵—in any case, we can only assess these things with objective data in hand.

Incidentally the kind of reflective analysis described in this post is not an exclusively end-of-year activity for me—not in the least: consulting my on-task past is a near-daily activity that results in a constant reconsideration—via task refactoring, in Chronos-speak—of my future plans.

Chronos was explicitly designed to make this kind of daily dynamic planning a fluid and integral part of the developer workflow.

Try Chronos

If you’d like to try Chronos, you can download it for a free twenty-day trial. The Chronos tutorial is a step-by-step introduction to using Chronos effectively.

Footnotes

⁰ Chronos will highlight on-task dates for both past and future tasks.

¹ Or am I? 🤔

² As dutiful software engineers, we know that there’s other important work beyond just writing implementation code—unit and system testing, refactoring & design investment, utility & domain abstraction are all worthwhile activities—but investing too much on tasks other than material delivery has destroyed many a software project and is equally an anti-pattern. Being able to track and analyse our data in this regard and tune our efforts accordingly can lead to significant risk reduction or competitive advantage.

³ Planning and estimates are typically inaccurate until the last moment, but the estimation skill set can be improved and leveraged over time to significant business and career advantage. That’s one motivation for tracking and analyzing objective personal task data.

Software developers that evolve their technical skill set without attention to the estimation and planning skill set do their professional self a massive injustice. For the initiated, Jacob Kaplan-Moss’s Estimating Software Projects series nails it.

⁴ 😜

⁵ Mastery optimizes Value / LOC over time. The hallmark of the “expert beginner” is lots of code and not much material value at the top. How do you know you’re not stuck in expert beginner-land? ⟶ Analyse personal data objectively, with respect to value delivered.

Chronos: The New Way to Manage Tasks

2021-12-10T00:00:00-06:00

Our tools shape us. Ideally, they shape us for the better, but that’s not always the case.

Traditional checklist and “to-do” apps have wide adoption, but they miss the mark for software developers and creative professionals, and ultimately these tools shape us for the worse.

To be clear, personal task management is necessary for successful professional outcomes — for both individuals and their teams¹ — but the traditional tools get it all wrong.

Why is this?

For one, traditional task apps are too general, attempting to serve both consumers knocking out grocery lists and professionals executing creative projects, as if grocery shopping were effectively the same use case as creative delivery.

“Get More Done!” is a familiar sticker tag on these products. At some level, we know this is the wrong goal. Completing 1,000 tasks in record time does not translate into project success, and yet software practitioners commonly operate as if this were the case — even as software projects regularly fail.

Our tools shape us.

In the traditional “to do” app view of the world, tasks are managed as an unordered bag of items to be completed and “checked off”, encouraging a kind of blind walk toward outcomes.

But successful creative execution involves strategy: a conscious, ordered sequence of steps to reach our goal — that is to say, we require a plan.

But plans are worthless, aren’t they?

Yes, Plans are Worthless…

Plans are worthless; but planning is indispensable².

Interestingly, Eisenhower’s popular wisdom here (about the optimality of planning) has a theoretical proof³, but, practically speaking, we can understand the need for planning by first considering the traditional task app’s process of managing tasks.

With traditional tools, we may loosely order tasks with priority tags and the like, but over time our core operations are effectively adding and checking off disordered items in a bag:

If plans are worthless, one can see the appeal of this process: we’ve altogether removed any semblance of plan or strategy from our process and tooling.

But, while this process is provably suboptimal, we don’t need a proof to see why it’s so deficient.

For one, this process leaves us with no meaningful history or data over time. At any point, the finished tasks in our bag may, at best, have the date at which we marked them as done — but understanding the historic cost and relative order of those tasks is not available or reliable for analysis. There is not much data for us to look back on to assess our performance.

Secondly, at any time in our process, we have no clear or reliable picture of our future. Traditional task apps offer “future-projecting” features such as setting a “due date” or priority level for a task, with which we might record our hope for when a task would be complete or what we might work on soon.

But “hope” is the key word here; these features reflect wishful thinking more than reality.

In the real world, as we all know, new tasks are regularly discovered, and existing tasks are frequently de-prioritized and re-prioritized. Yesterday’s due dates quickly grow stale, losing all meaning, while tasks marked as “Important” sit incomplete for months.

Planning is Indispensable

Plans, static plans, are indeed worthless, precisely because of this flux inherent in real world execution. But for the same reason, planning — the dynamic, continuous activity of it — is indispensable.

Instead of a bag of tasks, consider a strictly ordered, linear sequence of tasks that is continuously revised to reflect the latest reality:

Instead of due dates we specify estimates and leave it to our tooling to dynamically project completion dates, keeping them accurate as our estimates and the relative order of tasks inevitably and frequently change.

Instead of “checking off” tasks we speak the same language about our past as we do the future: the estimate of any completed task is precisely how long the task took to complete.

By keeping current tasks active via estimates, this new process can be as simple as checking a box; but, unlike checking a box, data isn’t lost: we accumulate, at every stage of our work, a fully accurate per-day diary of our historic on-task time.

This is especially invaluable historic data, which we can use to personally assess our own performance to date, demonstrate our own productivity objectively to career stakeholders, and most significantly this is data that we can use to improve future estimates and, consequently, outcomes.

Introducing Chronos: The Task Management “IDE”

Chronos is a new desktop tool — an “IDE” for task management — that seeks to make personal time tracking and planning as intuitive and flexible as using traditional apps, but powered for the software developer and creative practitioner.

As software developers, we leverage IDEs to continuously refactor our code whenever it doesn’t fit reality — either because we have defects, new feature requests, or because our knowledge of the world and our problem domain has inevitably changed.

This is the same relationship we ought to have with our plans.

Chronos puts continuous refactoring tools for plans, tasks, and estimates on our desktop and at our fingertips, delivering value on multiple levels: first, by offering support for managing and quickly refactoring lists of tasks; secondly, as a generator of accurate historical on-task time, and, third, by supporting estimation and completion forecasting for future tasks and plans.

Chronos makes each of these levels opt-in at any time in the lifecycle of a project plan.

Our Tools Shape Us

Unfortunately, it is common to see that estimating software project timelines is hard and just … give up. There’s an established “No Estimates” position that says we should entirely stop giving estimates on software projects ^{1, 4}

Estimation, especially in the software industry, is a hot button word, but this is unfortunate: the surest way to find ourselves stuck in an “expert beginner” skill set is to ignore time and estimates while otherwise cultivating our technical and professional delivery capabilities.

One major “secret” to advancing in a technical career is learning how to give accurate estimates.

This is true of individual contributors and engineering managers: you can pretty easily become a Senior Engineer or Engineering Manager without needing to be good at estimates, but to go much farther than that you’ll likely need to learn this skill.

And it is a skill: estimation can be learned.

Chronos is designed to meet software developers (and other creatives) where they are in their professional journey while fostering the advancement of one’s own personal estimation skill set with minimal required buy-in.

Estimates are the lingua franca of Chronos: the singular model used for predicting the completion of future tasks and for the recording of actual historic task on-task time. Estimates of future tasks are optional and Chronos embraces the real-world expectation that estimates will be frequently inaccurate and regularly revised.

Chronos anchors its users into an effortless practice of linking day-to-day creative professional pursuits to time and estimation.

Try Chronos

If you’d like to try Chronos, you can download it for a free twenty-day trial. The Chronos tutorial is a step-by-step introduction to using Chronos effectively.

Footnotes

¹ Team collaboration and project management tools sit a layer above the personal and serve a separate purpose, but look over the shoulder of any successful team member practitioner or individual contributor and you’ll find a list of tasks captured in an app, text editor, sticky notes system, or similar.

² This quote is attributed to Dwight D. Eisenhower 1890–1969 American Republican statesman, 34th President 1953–61.

³ See: Garcia Contreras, Angel F.; Ceberio, Martine; and Kreinovich, Vladik, “Plans Are Worthless but Planning Is Everything: A Theoretical Explanation of Eisenhower’s Observation” (2017). Departmental Technical Reports (CS). 1102 https://scholarworks.utep.edu/cs_techrep/1102/

⁴ Jacob Kaplan-Moss’s Estimating Software Projects is an excellent series on the topic of software project estimation. The series covers why the practice of estimation is invaluable with practical tips on how to do it well.