Sema Blog

Last week I made the case for codebase transparency: why 21^st-century dev leaders need real-time insight into the strengths and weaknesses of their codebase, and why new quality metrics are going to be the principal solution.  This week, I want to look at how this actually works in the day-to-day progress of a company. 

Case study 1: the regular meeting

It’s the first Wednesday of the month, and your dev team leads step away from the gentle hum of CPUs and caffeinated frontal lobes to gather in the meeting room, lattes and laptops in hand. 

On leading software development in the 21^st century

But first, a preliminary note about rain

Predicting the weather has always been valuable, but for most of history people have been pretty bad at it.  This was not for lack of heuristics.  Societies have always had weather lore – some parts of it (red sky at night) more accurate than others (groundhogs) – and an experienced sailor could develop a gut feeling for when a storm was approaching.  But today’s detailed forecasts would seem like outright magic to them.  A modern meteorologist would either be worshipped as a weather deity or burned at the stake.

What changed? 

I used to have a trick when I was job hunting. The interviewers would drill me on all the hot problems in coding, and clever new techniques in data science and machine learning. Then when my turn came, I’d ask targeted questions about how they’re employing these a specific system.  As soon as I saw smirks, sidewise glances, and the word “well…” forming on someone’s lips, I knew I was in. It was my specialty:  bug squashing, refactoring, modernizing, and just wiping out tech debt with feel-good newness.

Tech debt was shrouding their dreams.