This week's book giveaway is in the General Computing forum.
We're giving away four copies of Emmy in the Key of Code and have Aimee Lucido on-line!
See this thread for details.
Win a copy of Emmy in the Key of Code this week in the General Computing forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Paweł Baczyński
  • Piet Souris
  • Vijitha Kumara

x-ray software design question

 
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Adam Tornhill,
Wow, reading the description of the book, suddenly very interested on this topic of behavioral review as an approach to tackle technical debt.

q1: Is there a bit more you could share, is this about the developers being good at certain 'design patterns' versus others and creating technical debt by keep doing it 'the same way', or is there a different perspective/point of view?

q2: Being able to measure is what makes it easier to see progress.  Are there automated ways to help measure where this approach may be useful (such as using a common software analysis tools such as sonarqube)?

Thanks, very interesting point of view!

-Darren
 
Author
Posts: 21
6
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Darren,

Thanks for your questions! Let me try to clarify what the book is about:

darren hartford wrote:
q1: Is there a bit more you could share, is this about the developers being good at certain 'design patterns' versus others and creating technical debt by keep doing it 'the same way', or is there a different perspective/point of view?


The underlaying theme in the book is that there's more to code than code. Just because a certain module is complex, that doesn't mean its technical debt is high. It's only technical debt if we need to pay interest on it. Since interest is a function of time, we learn how to add a time dimension to our codebase by mining our version-control system, which knows exactly when and how often each piece of code was changed. By using version-control data, we can then identify hotspots that I define as "complex code that we need to work with often". Used that way, I view version-control as a behavioral data source that we can tap into for information that can guide our decisions.

But that's only the starting point. Once we embrace version-control data, we get access to lots of information that is invisible in the code itself. For example, most of the book focuses on how multiple developers and teams impact code quality and feature implementation efficiency. As an example, you might have heard about Conway's Law; Using behavioral code analysis, we can start to measure and visualize how well our current architecture supports the way our system evolves, as well as how well-aligned our architecture and organization are.

darren hartford wrote:
q2: Being able to measure is what makes it easier to see progress.  Are there automated ways to help measure where this approach may be useful (such as using a common software analysis tools such as sonarqube)?


When I started out with these techniques 7-8 years ago, there weren't any tools available that could do the analyses I wanted to do. So I started to write my own tools. I open sourced my first tool suite as Code Maat which might be a good starting point. These days I spend most of my time on CodeScene, which is a commercial product but free for open source projects.
 
Marshal
Posts: 14274
237
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes! And welcome Adam!

Yes to there being more to code than just code!
Yes to interest being a function of time.
Yes to the reference to Conway's Law
Yes to your use of the term "reckless debt" in the book.

I'm glad to see that you are one of the few people I've run into who understand that incurring technical debt is meant to be a strategic decision that will give you benefit sooner rather than later. Not many people have seen Ward's video explaining the original thought behind the Debt Metaphor. I'm looking forward to having some great discussions with you this week.

I'm at work at a client right now so I will check back in the evenings.

Again, welcome and thanks for writing this book. From what I've seen in the preview on Amazon, it would be a valuable addition to any developer's library.
 
darren hartford
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Adam, well thought out answers, and very much appreciate the external reference links for additional information!
 
If you are using a rototiller, you are doing it wrong. Even on this tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!