Tag Archives: architecture

Productivity Hack: Thinking in layers

I just finished reviewing a colleague’s latest project. It is absolutely beautiful. It’s a collection of very pretty looking documents and forms that you can use to keep track of your professional accomplishments and portfolio. The idea is that each person can use it to cultivate more agency in the professional development process — and it will definitely help people as individuals achieve that goal.

So why would it make my heart sink? Because it’s perfect for one person (or a handful of people) to more easily manage an individual (and isolated) process, but will make it difficult for us to gain visibility into the collection as a whole. It’s a personal management tool, not an organizational management tool. What it won’t help us do is:

  • Search across 10s or 100s of portfolios
  • Scale to 100s or 1000s of employees
  • Keep the content relevant and up to date

So when I see this gorgeous looking thing, I feel sad: so much work went into this, and although it’s going to help solve one problem, it is going to create a maintenance nightmare. In addition, now we’re locked into a single UI and any change will require a ton of effort (and manual changes in each employee’s worksheet). How could we have avoiding painting ourselves into this box?

Thinking in layers is a habit I’ve developed from decades of working in software. By thinking in layers, you can create more maintainable, systematic, and repeatable solutions for solving operations problems. If we had solved this problem in layers, here’s what the solution components would have looked like:

  • Data layer – store all the data in CSVs, with one observation per row and one variable per column
  • Processing layer – a way to create, read, update, and delete documents, records or fields & perform calculations
  • Presentation layer – a way to display the data and make what the user sees pretty

(One of the reasons I love R Markdown is that it gives you a way to easily combine the processing and the presentation in a way that still doesn’t break the layers. If you want to change what people see, you change that in one spot in your Rmd, then re-knit.)

The moral of the story is: you can’t build a scalable system without layers. Think in layers.