---
title: "Why payroll systems are a pain to design - Temporal Data (and some great resources on it)"
url: "https://osherove.com/blog/2005/6/18/why-payroll-systems-are-a-pain-to-design-temporal-data-and-s.md"
canonical: "https://osherove.com/blog/2005/6/18/why-payroll-systems-are-a-pain-to-design-temporal-data-and-s.html"
published: "2005-06-18T23:21:00"
updated: "2005-06-18T23:21:00"
tags: ["Architecture"]
author: "Roy Osherove"
description: "When I first started working on a payroll system at a previous engagement, I was very frustrated with the biggest problem in building payroll systems: Handling time. That is - the change of things and values over time.…"
usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)."
license: "https://creativecommons.org/licenses/by/4.0/"
---

# Why payroll systems are a pain to design - Temporal Data (and some great resources on it)

By Roy Osherove June 18, 2005 In [Architecture](https://osherove.com/blog/category/architecture)

**Historical article** · Originally published June 18, 2005; technical details may be outdated.

When I first started working on a payroll system at a previous engagement, I was very frustrated with the biggest problem in building payroll systems: Handling time. That is - the change of things and values over time.

You see, in a payroll system, you need to know not only what "Dan"'s salary is Today, or what it was on January, you also need to know what you "knew" about Dan's Salary regarding January when you created the payroll for February (assuming today is March, for example).  You actually need to keep tabs on time in two dimensions: The actual time, and the history of the actual time. (I always think of it like a comet and it's tail - the comet being the place in time you want to know about and the tail  - the value in that time's history you want to know about).

   Were you just able to wrap your head around that last paragraph? because you can just imagine how much problem solving you need to do with such a system - data wise, architecture wise and design wise.

I won't go into the excruciating details (for now), but if you're in the same bind as I was then, you'd appreciate knowing that Marting Fowler [has a nice writeup on various patterns for "Temporal Data"](http://www.martinfowler.com/eaaDev/timeNarrative.html) - data which changes in time, which try to solve exactly these problems. I wasn't aware of many of these back then and, as usual for cases where you invent the wheel - came up with my own half-assed solution. Reading these I found that I was on the right track in some places and off track in others (in a way).

[Go read this](http://www.martinfowler.com/eaaDev/timeNarrative.html). And also probably [get this book](https://www.amazon.com/exec/obidos/ASIN/1558604367/iserializable-20) (which Fowler recommends).

On a related note, "[Patterns of Enterprise Application Architecture](https://www.amazon.com/exec/obidos/ASIN/0321127420/iserializable-20)" is by far one of the most eye opening pattern books I've read (along with the [classic Gof book](https://www.amazon.com/exec/obidos/ASIN/0201633612/iserializable-20)). The great news is Fowler is on his way to making more of the same good thing - continuing on with a different book. Meanwhile [we can all enjoy his thoughts on the patterns he comes up with online on his bliki](http://www.martinfowler.com/eaaDev/index.html). I consider it a treasure trove of things to think about - like a totally free book of open thoughts.

Most of it is pure gold - stuff you really wanted someone to put in words for you.

What can I say? This guy is going somewhere ;-)

## More in Architecture

[All posts in Architecture](https://osherove.com/blog/category/architecture)

- Jun 19, 2005

    ### [\[Audio Interview\] Brian Noyes: Deep .NET Q&A](https://osherove.com/blog/2005/6/19/audio-interview-brian-noyes-deep-net-qampa.html)

- Jun 19, 2005

    ### [A very nice .NET architecture blog discovered](https://osherove.com/blog/2005/6/19/a-very-nice-net-architecture-blog-discovered.html)

- Jun 5, 2005

    ### [What's legacy code?](https://osherove.com/blog/2005/6/5/whats-legacy-code.html)

- Jun 5, 2005

    ### [VS 2005 Team System Modeling Strategy and FAQ](https://osherove.com/blog/2005/6/5/vs-2005-team-system-modeling-strategy-and-faq.html)


---

## About the author

**Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery.

### Sites

- [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership.
- [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts.
- [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin.
- [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model.
- [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps.
- [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes).

### Social

- X: https://x.com/royosherove
- LinkedIn: https://www.linkedin.com/in/osherove/

### Contact

- Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7

### License

Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/
