Neal Ford is Director, Software Architect, and Meme Wrangler atThoughtworks, a software company and a community of passionate, purpose-led individuals, who thinks disruptively to deliver technology to address the most demanding challenges, all while seeking to revolutionize the IT industry and create positive social change. He is an internationally recognized expert on software development and delivery, especially at the intersection of agile engineering techniques and software architecture. Neal 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.
We had the opportunity to interview Neal before the Global Software Architecture Summit where he was a 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 wire 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 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 build 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.
Top comments (0)