Should I track time for an hourly project during time taking operations?

Question

I am a freelance programmer and use time-tracker software to bill my hours. Sometimes when I am running some time-taking operation such as building a Docker image, running a CI pipeline and waiting for it to finish. Should I keep the time tracker running while I am waiting and using apps like YouTube, Discord in the meantime?

Answer 1

It depends on whether you need to watch the paint dry. Some tasks or requirements disallow you to leave for other productive, fee-generating work. If that's the case, charge. If not, then don't charge.

Answer 2

---

Suitability for PMSE

Part of what you're asking isn't really a project management question. It probably belongs on The Workplace, or your contract with the client belongs on the desk of a legal professional who knows the employment and contracting laws in your jurisdiction. That said, there is a project management answer to the broader question of whether process wait-time is (or should be) billable, and I'll provide that.

---

TL;DR

There's a big difference between process-related wait time and goofing off. While I outline some of the differences below, ultimately you and your client need to agree on which one represents what you're doing, and that will likely be based on:

1. Both sides understanding the development process, your level of control over it, and whether you're empowered to improve it.
2. Both sides agreeing on whether the outcome of the current process is working as expected for all involved.

If you and the client can't agree on those things, then you will eventually part ways one way or another regardless of the underlying reasons. That's just the bottom line; the rest is largely sophistry.

Resource Constraints Like Slow CI/CD Pipelines are Generally Billable Overhead

Notwithstanding the sidebar at the top and the other provisos above, the general answer is that work-related delays are billable and should be accounted for in any sensible project plan, including the labor budget. Here's the obligatory XKCD cartoon explaining it succinctly:

If you can't do something else billable in the meantime, such as working on a different part of the project or doing billable work for another client, then the client should generally expect to be billed for all hours allocated to the client's process. Small mom-and-pop businesses won't be happy with this, of course, but larger businesses understand that a certain amount of overhead and process-driven delays are just "the cost of doing business."

This is not the same as double-dipping unless there's more to this than you posted in your original question. So, as long as you are legitimately blocked because you are waiting on something work-related that is time-consuming, you as a contractor should be getting paid for your time. This is especially true if the client's processes, policies, or infrastructure are preventing you from making money doing something else with the time you've set aside for them. In other words, if that time is allocated to the project, then you should be billing for the time spent on the project even if it's wait-time.

If your contract says something else, or you can't justify your time in some meaningful way, then you should expect some push-back. However, if you've done your professional due diligence and pointed out inefficiencies in the process (and especially if you've offered to help fix them) then the company's project and organizational leadership is ultimately responsible for the overhead.

Some Practical Examples

Let's look at a couple of real-world problems that should be considered expected-and-billable overhead absent contractual issues or a failure on your part to task-switch to other billable work.

A Priori Assumptions

For the sake of argument, let's assume:

1. This is your only client.
2. You are expected to devote "full time" to this project.
3. You yourself are not responsible for the slow tests, builds, or pipeline processes.
4. Excess wait-times and excess processing are two types of "waste" in Lean-based systems, and are systemic problems that cannot be solved at your level.
5. You've communicated the delays inherent in the process to line management.
6. The organization has chosen not to prioritize or authorize improvements to the process, or empower you to do so in a billable way.

Common Billable Constraints

Given the assumptions above, here are some legitimate reasons that billable wait-times should be considered "known-knowns." Because they are predictable, they should be expected by project and technical leadership, and treated as unavoidable overhead within the project.

• There are slow integration tests that aren't necessary for routine check-ins, but are required by policies that can't be changed within the project.

• You can't check in one component without having to rebuild dozens of other slow-building dependencies too.

• The CI/CD pipelines or other build tools are under-powered or unsuited for the tasks.

• The CI/CD pipeline is not fully automated.

  This is surprisingly common in my professional experience. While anecdotal, I can count the number of fully-automated CI/CD pipelines I've seen in even large-cap companies without having to take off my shoes.

• The build process is very sequential, with numerous manual steps that you need to frequently check on or wait for before kicking off the next part of the process.

  This type of problem is again surprisingly common in many real-world organizations, and often prevents developers from treating the process as a fire-and-forget activity. This in turn prevents them from fully switching away from the task to do something else.

• Other work related to the slow process can't be started until the current process is complete. For example, you can't work on "embiggen the widget" until the widget is fully built and deployed.

If the work is highly sequential and can't be done out of order, then the wait-time is baked into the process. Unless the process changes the wait times are inevitable, but some slack is actually good for most processes (see queuing theory). The question is really what to do if the slack is excessive, and what to do with the excess if reducing the wait-time itself isn't an acceptable option for whatever reason.

Things You Can Do with Excess Wait-Times

If you're concerned about your personal productivity then there's almost always something project-related to address. The real problem is political: determining if the client considers it value-added and billable work or not. Assuming you've already raised the real issues to line management, there are generally some useful project-related activities that are rarely blocked by slow pipelines or build processes.

Unless you already know that such work would not be valued (or paid for), then you can—and probably should—use some of that extra time to:

• Review code.
  • Identify new TODO, FIXME, or other issues in the code base.
  • Add useful comments in the code.
  • Use your language's documentation markup to document the code better; this is especially useful in dynamic languages like Ruby or Python.
• Propose modest refactorings on a separate branch.
  • Create self-documenting refactorings (like explanatory variable names) on a separate branch.
  • Flag or fix style issues.
  • Update your (hopefully automated) style guide rules to reflect the reality of your project and its contributors.
• Work on your project-specific tool chain.
  • Automate your local auto-testing environment.
  • Update your linting rules.
  • Update your tag files, project environment files, local test fixtures, pre-commit hooks, and so on.
  • Add useful shortcuts or plugins to your editor or IDE.
  • Replicate the CI/CD tool chain locally (if possible) so you can do sensible preflight checks.
  • Try a new tool to see if it does whatever-it-is faster than the existing tool used for that purpose.
  • Update out-of-date tools, libraries, or OS components on your development workstation.
• Do some project analysis.
  • Check your code coverage.
  • Graph your dependencies.
  • Tag areas that are too complex, too interdependent, or violate some useful programming principle like SOLID.
• Decompose future work.
  • Identify hidden dependencies.
  • Consider alternative approaches that are faster, easier to read, or more automatable.

Most of these things are intrinsically valuable, and not just busy-work. They're things many experienced programmers do routinely as part of the job.

The Client (and Your Contract) Determine Value

I've certainly seen plenty of companies value the activities above because programming isn't just about writing code; it's about producing a sustainable product. Then again, I've seen companies that don't value any of these things at all; they just want to see n lines of code produced per day, butts in seats, or visible effort expended even if the end result is not actually fit for purpose.

If your company is one of the latter, then they clearly value time expended more than actual outcomes, so you need to track time expended even if it's wait-time. If you're lucky enough to work for the former type of company, then you should be taking every opportunity to help the project level up, and that will in turn make your job easier and your original question a non-issue.

In either case, you should absolutely be paid for every hour you spend on project-related work, even if the activity is "waiting" because you are legitimately blocked. Please note being "in the right" may or may not help you keep your job if you have a lopsided contract, an unreasonable client, or are being paid for piece-work rather than time-and-materials. However, if you're asking "Would my client like to be charged less for more of my time?" the answer will always be yes. On the other hand, goofing off or billing for time when you could be adding value to either the project or your own workflow within it is definitely on the "Why would you think anyone would pay for that?!" list. You doubtlessly already know whether or not that's the case for you.

Draw or Imagine a Venn Diagram

There's a Venn diagram to be drawn that includes your contract terms, your moral code, your personal work ethics, your client's expectations, and the level of results you're delivering. If you aren't smack in the middle of that Venn diagram and you're not delivering results then the problem is you. Otherwise, focus on what it takes to deliver the expected outcome and keep your client happy. As long as you're doing those two things, and there's truly nothing else to do during those wait-times, then it's just overhead that the project should absorb as a cost of doing business.