How Healthy is Your Product? - Source Code Check

You are developing your product using agile and lean approaches. 

How can you check your approach and distill improvements? A health check of your product and your development approach is certainly a good solution.

This post is the first of a set of articles 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.

Rules

The patient solely decides if a health check shall be performed. The effort and depth of a health check is 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 improve durably the health of your application. The findings are often clear and the measures straightforward. The real work is to implement consistently the measures.

I have the same personal challenge when trying to loose 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 about source code checks is that a whole set of tools are 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 a current version and use the new Java features,
2. Multi-threaded, 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 provides insights why source code quality is of tremendous importance for any company. And the blog SonarLint for the Impatient would be a pragmatic first measure to measure and improve your source code health. 

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

Posts in the  Health Check Series

1. Source Code Check
2. Delivery Pipeline Check
3. Product Strategy Check
4. Company Culture Check