Exercises

In these final exercises you get an opportunity to look for early warnings of potential future quality problems. You also get to experiment with a proactive usage of the social analysis techniques as a way to facilitate communication, as well as to reason about offboarding risks.

Early Warnings in Legacy Code

• Repository: Tomcat^[139]

• Language: Java

• Domain: Apache Tomcat is a servlet container that implements several Java EE specifications.

• Analysis snapshot: https://codescene.io/projects/1713/jobs/4294/results

Apache Tomcat has a rich history and the code continues to evolve, which makes it a great case study for detecting early warnings due to new features. One of Tomcat’s classes, java/org/apache/tomcat/util/net/AbstractEndpoint.java, had been around for eight years before it suddenly started to accumulate complexity. The class is still small, around 700 lines, so if this turns out to be a real problem, now is a great time to counter it.

Start by investigating the complexity trend of java/org/apache/tomcat/util/net/ AbstractEndpoint.java. Continue with an X-Ray and see if you can find any areas that could benefit from focused refactorings. Bonus points are awarded if you, using the Git history,^[140] track down the new code and focus your investigative efforts there. (In reality, you’d deliver the possible feedback as part of the pull request.)

Find the Experts

• Repository: Kubernetes^[141]

• Language: Go

• Domain: Kubernetes is a tool to manage containerized applications—for example, Docker.

• Analysis snapshot: https://codescene.io/projects/1823/jobs/4598/results/social/knowledge/individuals

As we discussed distributed teams we saw that tasks often take longer to complete as we struggle to find the experts. It takes time to learn who does what, and that learning curve gets longer when we’re located at multiple sites.

Pretend for a moment your team works on Kubernetes and looks to complete a particular feature. After an initial investigation you realize you need to modify the staging/src/k8s.io/apiextensions-apiserver package and probably the staging/src/k8s.io/client-go code too. Who should you discuss your changes with? Have a look at the knowledge map and see if you can identify the main developers.

Offboarding: What If?

• Repositories: Clojure^[142], Git^[143]

• Language: Clojure, Java, C, and shell scripts

• Domain: Clojure is a Lisp dialect for the JVM, and Git is git.

• Analysis snapshot, Clojure: https://codescene.io/projects/1824/jobs/4597/results/social/knowledge/individuals?aspect=loss

• Analysis snapshot, Git: https://codescene.io/projects/1664/jobs/4156/results/social/knowledge/individuals?aspect=loss

We’ve seen how we can measure the impact when a developer leaves, and now we get a chance to simulate the same effect with proactive use of a knowledge-loss analysis.

In this exercise you get to investigate two popular open source projects and see what happens if their creators leave. Simulate what happens if Git’s inventor, Linus Torvalds, leaves and compare it to the effect on Clojure if Rich Hickey abandons the codebase.