Melding Software Quality and Software Craftsmanship


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.

Filed in: Technical Debt
Kyle Christiansen
Kyle Christiansen Technical Solutions Architect
Kyle Christiansen is a Technical Solutions Architect at CAST and has more than a decade of experience as a software engineer and team manager. He has designed systems and product architectures to deliver personalized, secure and highly available apps.
Load more reviews
Thank you for the review! Your review must be approved first
You've already submitted a review for this item