Cool and all, but having a way to measure the gnarliest parts of the code is not, in my experience, the problem. Having a management objective that is willing to devote any non-zero amount of time to paying down technical debt is more often the problem. Technical debt costs over time, and new features pay off much quicker. The management may not even intend to be around in the long term (if they're developing for a client or intend to sell to a larger company, for example).<p>Of course, having a measurement might help shine a spotlight on how things are getting worse, but I've never actually seen this happen. Perhaps others have a different experience?
I don't think the author understands what "emergence" is. The concept of emergence is that a complex system might have properties that CANNOT be explained by studying the parts.
The talk about boids made me think this would go in a different direction.<p>Programmers and our employers exhibit flocking behavior. See how Ruby on Rails brought so many people to the Ruby language. How Python had a similar surge earlier in the 00s, and later with the explosion of use (numpy and similar) in data science applications. Additionally, things like Ruby on Rails helped make the web application commonplace. See JavaScript and AJAX for that as well.<p>Perl established an effective code repository (CPAN) that enabled their userbase to grow via a similar flocking mechanism. Go has no central repository but has an easy to use mechanism for adding dependencies based on git repositories. That ease of access to published modules allows people to adopt the technology once a peer (someone working in a similar domain) publishes something. And it encourages people to contribute back in some fashion (publish new modules or update the existing ones). In Perl's case you saw a lot of people from outside IT making use of it (the same is now true for Python with data science) because the heavy lifting was done and they could focus on gluing things together.<p>Exploiting this flocking behavior, then, becomes important to anyone wanting to push a new technology out. Even if it's the best thing and would produce the best software ever, it won't always succeed on its own merits.<p>(random thoughts, no real thesis here)
I write down every issue - everything from user interface issues to bugs, and then delete them as they get fixed. I can then use that file to measure code debt. The file is saved in version control, so no fancy stuff, but I can run statistics and compare code growth and growth of issues.
In my experience you want to keep this file small. On a current project I've estimated that it will take five years to clear this file <<i>grin</i>>. This file seem to grow exponentially with new features. And I think at some point there's a point of no return - where you can't possible fix all issues ...