I was asked recently, kind of off the cuff, whether I thought that static analysis made sense for small business. I must admit that the first response that popped into my head was a snarky one: “no, you can only reason about your code once you hit 1,000 employees.” But I understood that the meat of the question wasn’t whether analysis should be performed but whether it was worth an investment, in terms of process and effort, but particularly in terms of tooling cost.
And, since that is a perfectly reasonable question, I bit my tongue against the snark. I gave a short answer – more or less of “yes,” but it got me thinking in longer form. And today’s post is the result of that thinking.
I’d like to take you through some differences between small and large organizations. And in looking at those differences, I will make the perhaps counter-intuitive case that small companies/groups actually stand to benefit more from an investment in static analysis tools and incorporation of the same into their software development processes.
Size: Too Big to Fail?
If you’re a massive enterprise, you’ve earned the ability to swing for the fences and miss. Badly. So badly that you trip and somehow your pants fall down, as if in a child’s cartoon. As an example of this in action, consider such mega-whiffs as the Apple Newton, Google’s Glass, or Microsoft’s Zune. It’s not just tech companies either. Perhaps synonymous with the corporate flop was Ford’s Edsel. And yet, Apple, Google, Microsoft and Ford are still scraping by.
They have this luxury whereas those of us in small groups and firms really don’t. We aren’t able to spend years and tens of millions of dollars working on a piece of software only discover that “oops, no one likes that as constituted, so we’d better do something completely different.” We can’t gamble that way.
Static analysis is built in flexibility. If you charge out of the gate doing the right kind of static analysis from the get-go, you’ll have valuable feedback from day one. You’ll know if you’re creating problematic dependencies, baking in anti-patterns or incurring technical debt. These are the sorts of things that prevent you from pivoting your software as you go and learn more about your domain and customers. If you keep them out of your software, you’re creating a badly needed hedge against spectacular, small-business-killing flops.
Going to market with a dud isn’t the only way to fail, of course. But if you keep your software free of cruft, you’ll have a much better chance of avoiding that particular fate.
Skills Development Capacity
Another luxury afforded to massive companies by virtue of their size and scale is the ability to offer training and career development to their people. It’s not that small business can’t or don’t ever do this, but those dollars are going to be a lot more precious to them and harder to give up. Enterprises often fly people to training courses, bring in firms to run bootcamps, or hire quasi-permanent consultants to coach their teams. As a smaller organization, your company is more likely to purchase Pluralsight subscriptions or find videos on Youtube. Maybe, if you’re lucky, it’ll pop for a conference.
Static analysis tools offer an undercover benefit here. They provide a whole lot of valuable feedback about rules, best practices, and goals to go after, and they do it by incenting developers to experiment and find ways to make their code compliant. This is valuable, on the job learning that will stay with them and help up their skill set. It’s not quite the same as hiring an experienced consultant to come in and work with them in real time, but it’s not a bad substitute, either.
Architectural Specialization
Another thing that I’ve observed about large organizations is that they tend to have architects. A lot of architects. Teams of architects. Hierarchies of architects. I wouldn’t be surprised if you could dig up someone, somewhere, with the title “Architecture Architect.” Point is, these large firms tend to create intense specialization among their workforce, including having people who really, truly specialize in architecture (which is largely about dependency and complexity management).
Your small business probably can’t afford to have people wandering the halls, focused on nothing but the dependency structure of your code. But arming your developers with a static analysis tool like NDepend can, once they’re practiced using it, simulate architectural specialty with a remarkable degree of effectiveness. You don’t need to make a bunch of specialized hires to have a team that speaks intelligently about afferent coupling, cyclomatic complexity, and method cohesion.
A Parting Metaphor for Small Business
Small businesses invest a lot in solutions that democratize the expensive. They employ managed services solutions and they put things into the cloud because doing so allows them to scale from almost nothing to as much as they need. Managed services companies, web hosting outfits, and cloud providers essentially offer a single payer model to the little guys out there, and the little guys can now have access to server farms and web scale, where they couldn’t have previously.
That offers an interesting parallel to a static analysis tool like NDepend. In the past, to have specialization within your walls, you would have needed to hire expensive, renowned employees or high priced consultants. You might have needed to requisition custom analyses of your code base, done by teams of architect-level people. Now, you can spend a few hundred dollars and have a pretty decent facsimile of all that.
You can cultivate in a small company or group an impressive degree of architectural expertise and understanding with a strategic investment in the right kind of tooling. And this kind of tooling is available to all in a way that it wouldn’t have been, historically.
