Adam Tornhill: I promise to bring you a new look at code and software systems

It is time for our second blog interview and this time we want you to meet one of our amazing keynotes! Ladies and gentlemen, please salute Adam Tornhill, the man who will bring you a very useful talk about Technical Debt. He is in love with modern history, music and martial arts, subjects that he will be more than glad to discuss with you in April, along with interesting facts about programming and IT.

Adam is a programmer who combines degrees in engineering and psychology. He's the founder of Empear where he designs tools for software analysis. He's also the author of Software Design X-Rays, the best selling Your Code as a Crime Scene, Lisp for the Web, and Patterns in C.

Until his coming, you can read this interview that Adam gave for DevExperience and get to know him a little better. This way, you will be able to prepare your questions for a very nice talk with Adam when you will meet him in person at the conference, in April. Of course, if you register here!

DevExperience: How does a normal day looks like for you? What about a not so normal day?

Adam: I'm running a startup so I'm not sure if I had any normal days in the past three years. My days are typically very different. Sure, sometimes I get to spend a day researching or coding. Other days I'm visiting customers to analyse their code, and to provide training and coaching. I also spend a lot of time planning the product development of CodeScene. But more often than not, I find myself doing all those things -- and some more -- within a single day. I also travel a lot since our clients are located around the globe, so a significant part of my code is written on airplanes or in hotel rooms.

DevExperience: Based on your research how do you see our test code? Is it usually too much, too brittle or not enough?

Adam: I do see a clear difference for test code when compared to application code. In fact, some of the worst technical debt I tend to find is in the test code. I think there are multiple reasons for this. First, we developers tend to make a mental difference between test code and application code; For application code, we know it's important that we keep it clean, easy to evolve and maintain. But for test code, more often than not, we don't apply the same standards. Second, test automation is still a relatively young field and we -- as an industry -- are still exploring and learning. Well-written tests look different from application code, the context and trade-offs are different, and we haven't really captured all the patterns we would need. I'm exaggerating a bit now, but I don't think the software industry really knows how to write good tests. We'll get there some day, but a lot of work remains to be done.

DevExperience: In your work with developers from different companies, what is the number one issue that they tell you or that you discover?

Adam: There are many different issues so it's hard to answer in general. However, a common situation is that I present a ranked list on an organization's technical debt and the organization tends to get surprised; not necessarily about the identified debt -- the most experienced devs have a decent gut feeling for where it is -- but surprised when the organization sees how much that debt costs them and how it just keeps growing. That temporal dimension tends to be surprising since it's not really visible in the code itself.

DevExperience: When analysing a new system/product source code, are they big gaps between what developers know and what the management knows in terms of quality, stability, scalability etc.?

Adam: Yes, definitely. Part of that gap is due to software being so abstract; there's no physics for code, so we have traditionally been left to subjective judgements and gut feelings around code quality attributes. Visualizing software systems and introducing a shared vocabulary for code quality helps closing that gap. We developers need to find a way to let non-technical people peek into our otherwise inaccessible world of code, and the techniques I'll present at DevExperience work well for that purpose.

DevExperience: Multi-repo or mono-repo? What do you find most frequently out there and what would you recommend?

Adam: I come across both approaches frequently, and there are valid cases for both. In general, I would try to get away with a mono-repo as long as possible. Introducing multi-repos might be necessary in order to align with organizational, legal, or product boundaries, but that extra level of in-direction always comes at a cost. Sometimes it's worth it, and sometime's it's not.
At Empear, we have combined several repos to mono-repos over the past year since we found that it worked better for us given our ways of working. Each additional repo carries the risk of a potential context switch, which is something that might discourage refactorings by making them harder.

DevExperience: When something went wrong with a project and we did a post-mortem it turns out to be a 'communication' issue. It was almost never a technical one. So how do you see the balance between XP practices and soft skills inside a team and organisation?

Adam: My view is that the software industry has become much better in addressing this, well, *softer* side of software over the past years. But we still keep underestimating social and organizational factors such as coordination and communication. I'm convinced that the main reason for this is because the organization that builds the system is invisible in the code itself. The consequence is that we often treat symptoms instead of the real problems. This frequently leads us to throwing technical solutions at people problems, which usually don't work well.

DevExperience: If you were now the CTO of a well established company, what steps would you take to tackle the technical debt?

Adam: Step one would be to understand how the codebase looks today: what kind of technical debt do we have, and how rapidly do we accumulate new debt? After that I would have a baseline where I can weight in my product roadmap. Is the technical debt acceptable, or do we need to pay it off in order to be able to implement our planned features in a predictable and affordable way? That would drive my decisions, and let me know if I need to switch the balance between adding new features versus improving existing code.
As a CTO, I would then constantly stay on top of my technical debt and make sure I know that the product evolves according to my goals and acceptable levels of debt. Used that way, we can live with some technical debt and might even take on new debt strategically since we would know if we can afford it or not. It changes the game.

DevExperience: Tell us more about the main ideas of your talk at DevExperience! Why should people register and attend the event?

Adam: Well, I promise to bring you a new look at code with the potential to change how you view software systems. There are two key points in my talk and they build on each other. The first is around technical debt where you will learn how to prioritize refactorings based on data mined from patterns in how the code evolves. The second part of my talk takes on the social side of code, and shows how to measure the people side so that you can detect potential coordination bottlenecks in your code and even measure things like Conway's Law. I'm looking forward to DevExperience and I hope to see you there!

We're looking forward to see you too, Adam! And we know for sure that all the participants at DevExperience feel the same and that they are all eager to meet you in person! So we will see you all on April 19 at the 4th Gathering of IT evangelists, to praise the word of Dev and to build together another great edition of the Absolutely Normal International IT Conference in Iași!