Oftentimes I say that building software is like building a house of cards. You always build up but it depends how you do it on every level and layer very much determines the success of failure. I also say that if you don’t measure it then you don’t manage it. So how do you measure your back end solution? One way is to pick up one person as a reviewer and review your code. This not only doesn’t scale but also skews “resullts” a lot since good developers are very often opinionated and tend to measure code using a yardstick that only applies to their past experience and specific projects they have been involved. As shown below there are alternative approaches to this topic.
What about back end?
Turns out there are proven methods for measuring the complexity and maintainability of your back end. Take a look at the examples produced by the Visual Studio which measures the code using arbitrary metrics called Maintainability Index. The attached example consists of multiple projects, circa 10K lines in total, spread across different projects. Interestingly the analysis takes into account any possible interdependence between even separate interconnected applications, which is particularly useful in a scenario of service oriented architecture.
What about front end?
It turns out that there are ways to measure front-end applications too. Take a look at the overall performance score as measured by popular Yahoo YSlow which also uses arbitraty method to measure implementation of websites, stylesheets, javascript as well as configuration of the server itself.
Here grade C doesn’t look awesome but in fact it’s a score that is not trivial to achieve in case of a web application, mainly due to complexities of DOM and JavaScript.
What about database?
This is not covered in this article.
Summary
This is not a one fit all approach, but shows few very concrete examples how using arbitrary indexes anyone can compare the back end and front end performance and maintainability of complex projects and indicate the how well your house of cards is being built. In fact it doesn’t matter that much how you measure as long as you measure comprehensively throughout whole solutions (not fragments of them) and as long as you keep using the same set of tools to compare progress and change.
Comments are closed.