Software Craftsmanship puts focus on adopting good technical practices systematically in the development. Scrum has a higher success rate than other approaches, but still, a large quantity of Agile projects can have low quality on deliverables. Scrum does not pay particular attention to it; here is where software craftsmanship is born.
The Agile methodologies have been broadly adopted by the software industry and have proven to be one of the best approaches to develop software products today. There is no secret about that, and I –as an Agile evangelist– particularly love it.
But when the maturity in the Agile process arrives, it is time to go beyond it.
Discussions about the effectiveness of the classic Waterfall vs Agile methodology has been going on for years, but we have now arrived at a consensus that put Scrum above other known development methodologies.
Content related: How to implement Scrum in 7 steps and not die trying
Scrum does not acknowledge the beautiful concept that has a refined name: Software Craftsmanship, which puts focus on adopting good technical practices systematically in the development process. Scrum has a higher success rate than other approaches, but still, a large quantity of Agile projects can have low quality on deliverables. Scrum does not pay particular attention to it; here is where software craftsmanship is born.
We all hypothetically want to have software with high quality standards, but in practice, we know that this is something hard to achieve, even more in the context of projects where urgency and request for changes sometimes kills quality.
I decided to compile a list of practices that will help you to achieve this desired result, so let’s go deep into some particular concepts and actions that should be considered to get into the software craftsmanship movement.
1. Define and enforce coding standards
An initial step towards code craftsmanship is to define a set of guidelines, best practices, programming styles, and conventions that all developers should adhere to.
Enforcing and helping the verification of the coding standard with a tool (e.g., Stylecop, in the .NET world) is essential for this process.
2. Static code analysis
Using tools that analyze the code without executing the program provide an understanding of the code structure and also help to ensure that the code sticks to industry standards and best practices.
Static code analysis tools like FxCop in .NET or SonarQube (a more complex and elegant tool) are good choices for executing this analysis.
3. Automating testing
This is a key aspect that is often underrated and not applied in many projects. Everybody loves the concept of having automated testing, but in general, the drawbacks are a deal breaker for several projects:
- It will boost the quality of the deliverable.
- They have high upfront expenses related to the selection and initial setup of a testing automation suite.
- The resources are specialized and hard to find: The profile of an automated tester is more on the developer side than on the QA side. The testing automation profile is not the easiest tech profile to find in the market.
- The truth is that automating testing, when done in the right way, will be largely paid for in any project. It will increase the team’s productivity significantly.
Automating testing is a decision that takes more courage and implies a bigger effort. It also has some risk implied: If you do not do it the right way, it tends to fail.
A right implementation will require steps like deciding what to automate, choosing the right automation tool (such as Selenium or Appium), and setting the stage for the team, stakeholders, and users to let them know what this implementation will imply. Some tend to expect “magic results” from automated testing, and that is something we know does not exist.
You might like this: Testing in Scrum: 4 reasons why testers are needed from day 1
4. Domain Driven Design (DDD)
Domain Driven Design (DDD) is about developing in a way that gets as close as possible to real-world processes and entities. The idea is to work with a domain expert who can explain how the real-world system works. In many cases, the domain expert is the customer, but it can also be a user.
DDD uses ubiquitous language, commonly used by developers and domain experts for common specification for the domain that they are working on, so concepts can be explained and understood unequivocally, with no place for misinterpretations.
One of the best benefits of the DDD is that the development team is aligned with the users/domain expert language, which brings all the team members on the same page. In addition, DDD suggests dividing the entire domain into subdomains, also called contexts. These contexts should not be too large, because the larger the context, the greater the chance for multiple meanings for the same term.
Apart from capturing the domain model in crystal clear terms and embedding the model in the code, DDD also proposed a series of best practices and patterns (like the service, repository, and factory patterns) that are very useful for generating a neat and tidy code.
The Eric Evans’s “Domain Driven Design” book (PDF) is the main reference for starting to work with this recommended practice.
5. Pair programming
Pair programming is widely recommended by some and criticized by others. It became popular with XP (Extreme Programming), a development framework that enforces certain practices in order to improve software quality.
Even though the usual named disadvantage of this is the obvious one (two people working on one task seems to be an ineffective use of resources), we think, in opposition to that misconception, that pair programming is key for achieving software craftsmanship. Why? Here are some reasons:
- Programming together can increase the net amount of actual, complete features and reduce defects.
- It makes it harder to procrastinate and lose focus, so it tends to have higher productivity.
- It is a solid way of training developers thanks to the ability to share best practices and knowledge.
- It is the best way of implementing Agile learning; it implies going straight to the code over reading manuals and documentation.
I consider pair programming as the faster on-boarding method than the regular “please read the documentation and look at the code” learning approach. A good pair programming implementation implies defining how it works with each member: one programmer is the driver, having control on the keyboard and coding, while the other navigates and analyzes the code, watches, learns, asks, talks, and makes suggestions.
Now, it begs the question: When should we do pair programming? Pair programming is costly, so it is easy to do the math. It should be used when the problem, algorithm, or particular aspect of the code you are facing is difficult. Using it for easy to accomplish tasks is a waste of resources.
Do not miss this: How to become a code review master
6. Implement Agile development at ITS BEST
There are several other practices and platforms that will help in the software craftsmanship process. Some of them are refactoring old code, TDD (Test Driven Development), continuous integration, Application Lifecycle Management (ALM) configured in the best way possible (a product like Microsoft Visual Studio Team System), etc.
These should be the essential pillars of this maturity process. This is the very start for doing the right thing.
Obviously, everybody likes to have software craftsmanship, but it is something hard to achieve. There are several steps that should also be done and done the right way. This list will help you to do an assessment and execute it, as well as make you get close to the quality that we all want to achieve.
So, let’s go beyond Agile: Why should software craftsmanship be the target you’re aiming at? Because when you reach maturity, it is time to add quality to your software, and all the set of practices defined under the software craftsmanship movement’s umbrella are the ones that will help you best reach what most people are looking for: first-rate software.
Let’s start today!
Comments? Contact us for more information. We’ll quickly get back to you with the information you need.Go Back