If you wander the halls of a large company with a large software development organization, you will find plenty of examples of practice and process at scale. When you see this sort of thing, it has generally come about in one of two ways. First, the company piloted a new practice with a team or two and then scaled it from there. Or, second, the development organization started the practice when it was small and grew it as the department grew.
But what about “rolled it out all at once?” Nah, (mercifully) not so much. “Let’s take this thing we’ve never tried before, deploy it in an expensive roll out, and assume all will go well.” Does that sound like the kind of plan executives with career concerns sign off on? Would you sign off on it? Even the pointiest haired of managers would feel gun shy.
When it comes to scaling a static analysis practice, you will find no exception. Invariably, organizations grow the practice as they grow, or they pilot it and then scale it up. And that begs the question of, “how?” when it comes to scaling static analysis.
Two main areas of concern come to mind: technical and human. You probably think I’ll spend most of the post talking technical don’t you? Nope. First of all, too many tools, setups, and variations exist for me to scratch the surface. But secondly, and more importantly, a key person that I’ll mention below will take the lead for you on this.
Instead, I’ll focus on the human element. Or, more specifically, I will focus on the process for scaling your static analysis — a process involving humans.