Software Architecture Metrics Interview With Neal Ford

Neal Ford is Director, Software Architect, and Meme Wrangler at Thoughtworks, a software company and community of passionate, purpose-led individuals who think disruptively to deliver technology to address the most demanding challenges, all while seeking to revolutionize the IT industry and create positive social change. Neal is an internationally recognized expert on software development and delivery, especially at the intersection of Agile engineering techniques and software architecture. He has authored magazine articles, nine books (and counting), dozens of video presentations, and spoken at hundreds of developers’ conferences worldwide. Neal’s topics include software architecture, continuous delivery, functional programming, and cutting-edge software innovations, and he includes a business-focused book and video on improving technical presentations. 

Apiumhub had the opportunity to do an interview with Neal Ford, a Global Software Architecture Summit speaker, to get to know what metrics he normally uses and learn more about his chapter in the Software Architecture Metrics book that was recently published by O’Reilly.

What Software Architecture Metrics Do You Normally Use? 

It depends! However, this is truer than most of the times this answer appears in software architecture trade-offs. Metrics that don’t add value to a project are empty exercises, and different projects define value in different ways. For example, some projects carefully monitor code quality because they are trying to build a foundation for future development. Another organization may value speed to market and build small, throw-away projects where execution is all that matters. The key for architects is finding the metric(s) that give real insight and wiring those into your build. 

What Are the Key Software Architecture Insights You Could Share With Gsas Attendees?

Most teams misunderstand the concept of “reuse,” which has two important aspects–but most people miss the second one. The first is an abstraction — finding something abstract enough to be used in multiple contexts (everyone gets this one correct). The second is volatility — the rate of change of the reusable asset. If the rate of change is high, it is a bad candidate for reuse: every time this thing changes, everything that reuses it must stop and coordinate around that change. Thus, the secret to successful reuse is both good abstraction and low volatility.  

Can You Briefly Comment on Your Software Architecture Metrics Book Chapter?

I wanted to look at how architects can use metrics to add value to their projects, not just as an abstract exercise. Too many architects wire tools like SonarQube into their builds and think they have governed their software, yet they never look at the dashboard. Converting metrics to fitness functions means that an objective measure for that metric executes each time the build runs, making sure that metrics are not only defined but also applied at the earliest possible feedback opportunity.