In Software Development, there seems to be a negative correlation between delivering software quality at a slower pace, versus delivering a slightly lower quality product at speed. That’s not to say that doing both is impossible, but it is difficult, and few teams are able to achieve both speed and quality simultaneously and consistently.
Joan Gamel’s recent article in Hackermoon details the balance teams must maintain between delivering on time and delivering a good product. His analysis of the ongoing struggle is quite accurate. In particular, Joan addresses the issue of technical debt left behind by engineering’s taking development shortcuts to be able to deliver a product on time.
In my experience, it’s from this critical point in the SDLC that technical debt becomes entrenched in the overall application if it’s not refactored as soon as possible. If allowed to persist, this technical debt will continue its journey and spread its roots into broader parts of the system and become even more difficult to remediate.
One reason this happens is that Product Owners move onto the next feature after one is complete without necessarily thinking about the quality of that code, because, hey, “it works.” I doubt that this is a problem we will ever see fully go away, however, with good engineers that care about the software quality delivered by their team, they will have a better chance of coming out ahead.
“The best developers I know are crafts[wo]men,” wrote Joan. “Craftsmanship is the hallmark of good software. You don’t only build something that works, but you build it in the best way possible — It’s relatively easy to build something that works, but very hard to build something that works and stands the test of time.”
“Craftsmanship is also about caring. Caring to do a great job, caring about the ones who will maintain your code after you, caring about the consumers of your software having an easy time using it, caring about your team mates, and so on.”
With this mindset, Software Engineers are always looking for ways to refactor bad code that was written before their time, hopefully reducing technical debt, finding a good mix of quality coding practices for new enhancements, and working with their Product Owner(s) and Development Manager(s) to carve out the time to do so. In the end, taking the time to build a quality system may take a little longer, but will ultimately product a better product.
To ensure that development teams stay on the right path to produce quality software, Technical Leads and IT Management should consider tools to help validate and track progress. Using something like the CAST Application Intelligence Platform, everyone involved in producing software can get a view into the health and quality of a given system by tracking various measurements like technical debt and software risk in real time.
Having this kind of Software Intelligence helps software crafts[wo]men showcase what they have produced and enables them to be transparent with their software product and build trust between IT and the business, allowing them the flexibility to keep “crafting” to the best of their ability.
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.