3 years ago

Category: Software, Business, Database, Data, Ubuntu, Docker, github, automation

Most Software Engineers would agree on the ineffectiveness of measuring productivity based on lines code, however, I’ ve seen that because of this, the industry has fallen on a cynism thinking that Software Productivity cannot be measured accurately. For some of us is quite often the opposite, we thrive on challenges and look to push the boundaries of innovation.

It rather measures the amount of time your development pipeline takes to implement, as an added bonus it is almost always the easiest to interpret as in most cases the fastest your code lifecycle is the better your project should be.

The rest of the metrics are not as straightforward to implement nor interpret thus, I will only cover them briefly: Code coverage is fairly well developed, easy to understand and implement, a second step on this is to measure the degree of change in code coverage with new commits, the percentage of new code is well tested and how many “legacy” code is revisited with increased testing. Using standardized linting, we can get a good approximation on how many tests per lines of code there are, a great idea is to visualize directories and files as a graph with colored nodes based on relative wellness of test coverage.