Why Software Craftsmanship Matters: 5 Best Practices to Improve Software Quality

Søren Pedersen
7 min readOct 18, 2021

--

Agile methodologies are undoubtedly effective at achieving faster delivery of software. However, the higher the demand, the more an organization may try to push the boundaries of what’s practically Agile. The result can be a reduced quality of software released.

This may be partly due to some aspects of software development, like coding, being disregarded. Under this kind of pressure, some team members may focus on what quick solution others can offer, rather than how to empower others to improve their abilities. This is where software craftsmanship comes in.

What is Software Craftsmanship?

Software craftsmanship is an ethos that emphasizes the adoption of solid technical practices in an organized manner during software development. In essence, while the creation of software is largely guided by the problem you’re aiming to solve, there’s also a focus on the habits and procedures followed when coding.

Teams must also extend this thinking to other subsequent exercises that affect the final software product’s quality. Within Agile, software craftsmanship aims to anticipate the points at which an Agile methodology may compromise quality in the pursuit of greater speed.

Software craftsmanship should spawn routines that preempt errors and other issues slipping through the cracks. Additionally, this pushes teams to make shifts in the way they operate so members are able to contribute more easily and make a greater impact on the overall result.

Software Craftsmanship Best Practices

To keep up with both the foreseen and unforeseen during software development, there are practices that can achieve quality amidst dynamic, high-pressure situations.

Set and Enforce Coding Guidelines

When embarking on a new software development project, it’s important to define styles in which coding will be done. This not only helps you keep track of what each piece of code does and the entire flow, making you work smoother, but it also simplifies contributions from other developers.

Having clear coding standards will come in handy when you have a much larger code base and need to test or reuse components. Simple things such as devoting a single function to one particular action and naming pieces according to what they do can go a long way.

Luckily, there are tools that can help you ensure that whatever guidelines you set are being followed, such as Stylecop for .NET.

Conduct Static Code Analysis

It’s always a good idea to analyze code without executing it. This is because you have a chance to spot structural issues without being distracted by how it’s running. Software craftsmanship is about more than attacking the problem — it’s about how you build the solution to the problem.

Static code analysis can be useful in discovering vulnerable code. It can also be helpful in assessing the quality of the code in a statistical manner, like seeing how many lines are dedicated to simple or complex actions. You’ll be able to realize how easy or difficult it would be to repair some parts based on how convoluted the lines of code are.

Static code analysis could also unearth flawed logic that might be missed if that part of the program isn’t run because the scenario that triggers it hasn’t occurred. There are a number of tools that can do this analysis, like SonarQube, Codacy, Coverity, Checkmarx, ReSharper, Source Insight, and Roslyn.

Automate Testing

As stated, software craftsmanship can be exercised beyond writing code. Testing is an integral part of quality assurance and if rushed or not given enough attention, you’re likely to end up with poor quality software, however fast you deliver.

One of the main hindrances to testing is the challenge faced when trying to scale manual testing. Not only does it become way more expensive, any efforts to control the costs can leave human resources stretched thin, consequently increasing the chances of human error.

Regarding software craftsmanship, test automation is beneficial beyond limiting costs. To automate testing, you’ll need to write sets of rules, which inadvertently push teams to think more about all the tiny things that take place during testing. They’ll also have to think about what can be combined and what has to be split into separate tests.

Furthermore, test automation creates a rhythm. You start getting an idea of what it takes to test a piece of software of a certain size and complexity, and have it fully up to standard. You’ll know what steps have to be included, and the things that automation spots that are more likely to be overlooked in manual testing.

Test automation also improves accessibility of logs and other crucial data, fostering more robust data sharing. With automation tools brought into the testing phase, they can expose the gaps in communication and collaboration amongst team members and how they affect the quality of software released.

It becomes easier to see how issues arise due to a lack of consensus on the goals of a particular exercise, untimely notifications about issues discovered, poor planning on how to solve these issues, failure to use proper channels, failure to coherently present information, and other miscommunications. Of course, we can’t neglect the fact that readjusting development communication skills is key here, and will always help increase resolution.

Test automation also comes with a certain level of reusability, which can help create templates. These are especially helpful when working on projects with a lot of similarities. Basically, because test automation requires proper planning for it to work, it nudges teams into a culture of setting goals, rules, and clear strategies.

You can also choose from a variety of tools, which creates a wider spectrum for what you can achieve during testing. You can read a bit more about how combining developer skills with automation can achieve success here.

Follow Domain-Driven Design (DDD)

Software craftsmanship also encourages the creation of software in a manner that mirrors its real-world uses. For instance, if the software is to be used by cashiers and waiters in a restaurant, it makes sense for it to have elements that clearly demarcate processes like logging into a user account, opening and closing a tab, canceling an order, etc.

This is where domain-driven design comes in. By following DDD, you’re more likely to structure code in a way that makes it easier for another person to understand what you were trying to achieve. There’s also a higher chance that you’ll identify gaps in the logic when you try to compare the flow of the code to the real-world activity in which this code would be applied.

The DDD approach also brings technical and domain experts together to repeatedly improve a conceptual model, ensuring that it tackles a specific set of problems within a domain. This model can then be used later as a foundation for more complex designs.

In cases where different domains have similar requirements like account creation, verification of identity, and attaching a payment method, some sets of rules may be transferable. Ultimately, an organization can end up with a standard for how users can interact with their software.

This is how you find some software having certain steps like choosing skins and color schemes, installing plug-ins and other options made available in the earlier stages, while others let you work your way to them later.

In essence, with every piece of the software laid out and explained in similar terms to what is said or done in the domain the software is being made for, contributors have an easier time gauging whether the code is prioritizing the top pain points, and how it’s doing so.

Practice Pair Programming

In many cases, pair programming may come off as wasteful. Some might not see it as an efficient use of resources when two programmers are working on the same task concurrently. However, this technique can yield a lot of positive results when applied properly.

With one programmer focused on specific aspects of the software, the other may be able to spot some issues their colleague had missed. They can also share their varying styles of writing code and tackling problems, and also motivate each other when morale is down for either.

How to Encourage Software Craftsmanship in Your Organization

As a leader, it’s important to show the way. Here are a few ways you can encourage software craftsmanship in your organization.

  • Seek opinions from team members on the latest technology that can revolutionize how they work, and always be on the lookout for new trends that foster standardization.
  • Encourage communication between various team members, create scheduled time for them to interact, and learn more about each other’s role. By doing so, teams can brainstorm on the best procedures to follow when trying to achieve specific goals.
  • Bring in experts from the industries for which you are designing a software product. For instance, it helps to consult store and warehouse managers on their day-to-day activities before you build a tool that helps them keep track of inventory among other purposes.

Conclusion

All-in-all, there are plenty of tools and practices that can help you realize software craftsmanship, such as test-driven development and continuous integration. Even the refactoring of earlier code can work towards this goal.

At the end of the day, it helps to have adequate soft skills and build a rapport with the people you want to be following all the new rules. Software craftsmanship is also a continuous effort, meaning that you can put standards in place, and not revisit them to assess their feasibility and effectiveness amidst changing circumstances.

--

--

Søren Pedersen
Søren Pedersen

Written by Søren Pedersen

Søren Pedersen is co-founder of BuildingBetterSoftware, international speaker, contributor for The DevOps Institute, and Agile software development expert.

No responses yet