How Healthy is Your Product? - Source Code Check

2018 10 01 head

You are developing your product using agile and lean approaches.

How can you check your approach and distill improvements? Health check of your product and your development approach are certainly a good solution.

This post is the first of a series identifying health checks with different focus. We will identify strengths, potential weaknesses and hopefully find room for improvement.

The initial examination shall always be the source code. Your code base is a key asset of your company.


The patient solely decides if a health check shall be performed. The effort and depth of a health check are defined together with the patient. The findings are considered confidential.

A short check with a feedback workshop presenting the insights requires around two work days.

A deeper and more intensive check requests more effort, between one and four weeks. Upon completion, you can also hire a coach to implement selected findings and durably improve the health of your application. The findings are often clear and the measures are straightforward. The real work is to consistently implement the measures.

I have the same personal challenge when trying to lose weight or improve my running form. The long term implementation is the crux.

Source Code Checks

How clean, legible and maintainable is your source code? Often it is best to start your health evaluation with your product source code. At the end of the day, it is compiled source code you deliver to all your customers to work with.

One nice aspect of source code checks is that a whole set of tools is available on the market. You still need an expert to provide the diagnostic, but the gathering of data can be automated and quite inexpensive to gather.

Below a list of capabilities we have build-up over time for source code checks. Use common sense and strategic goals to identify the objectives you want to measure. Expertise is needed to define values to measure if the source code of your product reaches the selected objectives.

  1. Java 11/10/9/8/7/6 code and how to migrate to the current version and use the new Java features,

  2. Multithreaded, parallel programming and reactive systems,

  3. Functional and object-oriented detailed design approaches,

  4. Test driven development TDD and build-in quality - gradle or maven -,

  5. Acceptance test driven development ATDD and user acceptance,

  6. Clean code approach and detection of code smells,

  7. Static analysis tools to measure the quality attributes of source code,

  8. Compilation and test automation,

  9. Software craftsmanship approach, values and techniques,

  10. Domain driven development and micro services,

  11. Database models and open data,

  12. Software architecture and Enterprise architecture,

  13. CI and CD - continuous integration, continuous delivery, continuous deployment,

  14. Static quality assurance approaches for quick diagnostics,

  15. Development tools to improve quality and productivity,

  16. User Experience and UI design.

My blogs Pragmatic Craftsmanship and How to Reach the Software Quality Graal provide insights on why source code quality is of tremendous importance for any company.

The blog SonarLint for the Impatient would be a pragmatic first measure to measure and improve your source code health.

Any product should have a battery of measures deployed to continuously monitor the source code and detect trends over time.

Posts in the Health Check Series