Sajith asked me to talk about a programming topic with the good folks at Shopper.com recently, and I picked something near and dear to my heart: how to engineer with pragmatism at heart, how to navigate the challenges between business folks who want really fast turnaround time, and your engineering soul that wants good, maintainable craftsman-worthy code.

This wasn’t my finest presentation, but I liked the discussion that came up in between Sajith & me, and there were several things I’d improve if I were to give this talk again (this requires that you have either watched the video or at least skimmed through the slides above):

1. I wish I had called this Pragmatic Engineering instead because a) there is very little programming in these slides, and b) people will think this is from the book, when it’s clearly not.
2. Sajith brought up a good point in between that pragmatism is only possible because you lean on the shoulders of giants who wrote code before you (i.e. open source code). And that work priority is independent of these decisions: you plan & prioritise based on what makes sense to your organisation. I somehow should make this clearer in the slides and the talk that “big rocks” doesn’t necessarily imply a work priority.
3. I think the ending is very weak. I didn’t directly address what measures are possible for a pragmatic organisation. Here’s an attempt:
   1. Since the primary thumb-rule emphasises change, let’s measure speed of change or velocity. This is a leading measure, and a corresponding lagging one could be customer features delivered / quarter.
   2. A corresponding negative measure related to velocity could be defect counts, and defect escape rates, these can be measured from leading to lagging, as in DERs caught by PR reviews, your staging or QA environment, your beta and the worst of em all: in production.
   3. If there’s one thing that impacts the velocity of the team it’s good test coverage. So both code and feature coverage^[1] measures, and test resiliency metrics like false negatives should be measured and constantly improved. These are all leading measures.
   4. Measuring the warts in your code (e.g. FIXME/TODO lines, or “known issues”) is also a good leading measure. This should trend down.
   5. And finally, measure Cycle Time, but segmented by business use cases. The intent here is that all non-“Big Rock” items should have low Cycle Time. If not: maybe you don’t have the right processes or pragmatic software selection there yet. As an example: if a marketing page typo fix takes your company a week to execute (perhaps because it has to be prioritised in a sprint backlog), then might have a problem.

I’m willing and excited to do more such talks! If you’d like me to speak to a small group, do send me a message!

---

^[1]: Feature coverage was a term we invented at Lucideus to measure how many important features were covered by integration tests. Unit test coverage is easy to measure, integration tests aren’t, and only if you measure something can you consistently improve. The eventual definition ended up being something along the lines of “The % of test cases with priority Critical or High that were automated.” We reported these metrics segmented by feature.