In software maintenance and evolution, it is important to assess both code health and application architecture in order to identify issues impeding software quality goals. One way to move the needle toward software quality is to use Technical Debt (TD) indexing as a method to evaluate development projects.
We recently presented a paper at MTD 2016, the International Workshop on Managing Technical Debt put on by the Software Engineering Institute at Carnegie Mellon, where we discussed the way five different and widely known tools used to compute Technical Debt Indexes (TDI), for example numbers synthesizing the overall quality and/or TD of an analyzed project.
These days, it doesn’t matter where I go or which media channel I watch, I hear about the same thing: cost reduction. From governments to households to companies, budgets are on a diet — saving is the new sacred word. Therefore, everyone must do more with much less. When it comes to companies, the first budget to shrink is usually the IT budget. But what can be cut, and how?
Sometimes, entire projects are stopped. With luck, maybe only features will be abandoned.
Sadly, lowering the cost to develop or maintain a project doesn’t lower customers’ expectations. In fact, those expectations increase as time passes and customers’ needs stay the same: They want better, faster, and more complete applications. And it goes without saying that the application has to be rock solid, because a deceived customer can quickly turn into an ex-customer.
But the “fat” has to be cut somewhere. Some would cut the budget on the lower elements of an application — the ones that the customers never see. But this is wrong. You see, an application is like a house. Skimping on the foundation creates an enormous risk of everything else collapsing.
So if you can’t save money on the foundation, you have to remove features. But, what is a house without rooms? Doesn’t removing features also remove the meaning of the project? As you can see, it is difficult to lower a project’s budget without putting it into jeopardy. So what is the miraculous solution? Unfortunately there’s no such thing.
A good start though would be minimizing the cost of heavy maintenance. This can be done by putting a lot of thought into what architecture would be the most efficient from the beginning.
That’s easier said than done! Firstly, defining what architecture is needed is difficult enough. Secondly, it is also difficult to respect the architecture when it comes time to code it. Sometimes, circumventing the architecture permits you to deliver a feature faster. But it defeats the purpose of the architecture and creates flaws in the software. To make sure that doesn’t happen, you need a tool where you can check that your delivered code respects the architecture model.
This tool is delivered by CAST and is called Architecture Checker.
Using CAST Architecture Checker gives a lot of benefits. With it, you will be able to validate the architecture of your application from the moment it’s thought up while choosing the level of detail you want.
And you will be able to validate how good your defined architecture is respected in the developed code whenever the code is modified using the generated set of quality rules. Every time a new feature is coded by the developers, you will make sure that your architecture is respected, permitting your applications to remain robust and easily maintainable. And you will keep your costs low.
In the end, an application is like any other thing. When you ensure that it stays intact during its creation, it doesn’t require costly down the road.