Craftsmanship introduction

What is Craftsmanship?

Craftsmanship, is the state of art software development and is part of Continuous Delivery.

It is more than writing code meeting business and technical requirements (security, performance…). It requires more than knowing:

• A business context
• A development language
• A technical development environment (software factory)

As an overview before zooming in detail, Craftsmanship involved the following practices:

• Firstly, apply coding standards supporting sustainability of the code
• Secondly, embed early quality with early detection of bugs (functional and technical)
• Thirdly, properly take into account production requirements since beginning
• Fourthly, automate as far as possible
• At last, proceed by small steps to address complexity

To begin with, let us review the practices with their related objective and value. Nevertheless, keep in mind that these practices work as a system and support each other. In addition, this includes practices related to DevOps.

---

Comprehensive Testing Strategy

Objective

Better leverage the means dedicated to testing to have an optimized coverage of the risk. In addition, it supports a better integration of the tests in the development cycle for continuous testing.

Value

• Early onboard the quality in the development cycle
• Improve the quality
• Decrease the risk

---

Behaviour-Driven Development

Objective

Improve collaboration between Business&BA, Developer, Tester/QA and Production thanks to early stage collaboration. Indeed, this is stressed by the notion of the 3 amigos: Business, Development and Tester. They all work together since the very beginning to make sure specifications, tests and developments cover all aspects: business, technical and production.

In addition, a side notion is the Living Documentation that is a documentation relevant and up-to-date as automatically generated from the code. Indeed, it is refreshed each time the code is changed.

Value

• Seamless handover from development to production
• Better balance between build and production management of applications
• Integration test automation as an automation of the BDD scenarios

---

Test-Driven Development

Objective

Build the test first then the code. Once the test is built, the developer runs it to check output is KO. Then he/she develops the code. At last, he/she runs the test again to confirm that the result is OK.

Value

• Split build in achievable steps:
  • Enforce that requirements are properly implemented
  • Manage better
    • Complexity of the request (simpler and more pragmatic code)
    • Consistency of the code
    • Quality with testing for each small step
• Secure the automation of unit tests that are no longer arbitrated
• Increase long term stability of the application
• Increase the management of the complexity allowing by the flow merges of the changes thanks to automatic tests

---

Clean-Code

Objective

Aims at building high quality code thanks to coding rules. Without a doubt, some are common sens like, keep it simple, don’t repeat yourself, comment your code or use a naming convention… On the contrary, others are more technical like SOLID.

SOLID

• Single responsibility principle
  • A class should only have a single responsibility. That is, only changes to one part of the software’s specification should be able to affect the specification of the class.
• Open–closed principle
  • “Software entities … should be open for extension, but closed for modification.”
• Liskov substitution principle
  • “Objects in a program should be replaceable with instances of their sub-types without altering the correctness of that program.” Also referred as by contract.
• Interface segregation principle
  • “Many client-specific interfaces are better than one general-purpose interface.”
• Dependency inversion principle
  • One should “depend upon abstractions, [not] concretions.” In other words, high-level modules, which provide complex logic, should be easily reusable and unaffected by changes in low-level modules, which provide utility features. So, to achieve that, you need to introduce an abstraction that decouples the high-level and low-level modules from each other. Extract from this post.

Refactoring

Is also part of clean-code practice.

Code refactoring is the practice of reorganizing an existing software code without impacting its external behavior.

Indeed, refactoring aims at to enhancing nonfunctional attributes of the software. Surely, advantages include improved code readability and reduced complexity. As a result, these can increase source-code maintainability. And create an internal architecture easier to understand or object model more simple to adapt.

Value

Allows sustainability and easiest, fastest, less risky changes.

---

Trunk based development

Objective

Trunk-Based Development is the practice where all developers commit their code to one shared branch under source-control. In other words, all changes are directly merged in the source of the code and not on a duplicated branch.

The demanding prerequisite is to have all tests automated so they can run after each commit (merge of changed code). Consequently, this enable by the flow control that nothing is broken after a given commit.

Value

• Address the complexity with direct effect of changes on the whole system (early feedback)
• Improve quality with early detection of issues
• Improve Time to Market removing painful and time consuming merge phase (conflict management)

To put it with different word, this practice makes it possible to get away from the merging phase when the team consolidates in the source code hundreds or even thousands of changes. Indeed, this is when nobody understands what happen due to the unmanageable complexity of the combination of all that changes.

---

Pair-programming

Objective

2 people coding on the same piece of code for quality and knowledge sharing. One developer then the other will use the keyboard. Both of them look and interact on what is coded. This is an expensive practice but a good investment as stressed in the value section.

Value

• Address the risk and the quality for parts of code especially complex
• Onboard and share knowledge
  • Coding best-practices
  • Mastery of code complex areas

Mitigation of the cost of this practice can be achieved choosing pieces of code (especially complex) or topics (needing knowledge transfer) where it will be applied during the iteration, the sprint.

---

What’s next? Learn more on the other technical area in Continuous Delivery: DevOps

Craftsmanship is closely connected with DevOps. So, check my other post on this topic. There are also plenty of other materials around Agile and Agile at Scale. In addition, here is my post to have an introduction to Agile at Scale.

Do you want to learn more about Craftsmanship? Here are some valuable references

Books about Craftsmanship

• Extreme Programming Explained: Embrace Change
• Clean Code: A Handbook of Agile Software Craftsmanship
• The Clean Coder: A Code of Conduct for Professional Programmers
• Refactoring: Improving the Design of Existing Code
• Working Effectively with Legacy Code

Websites and additional resources about Craftsmanship

• Coding Dojo
• Extreme Programming
• Post from Agile Alliance on Extreme Programming
• Website of Robert Martin, the author of Clean Code and The Clean Coder
• Martin Folwer’s Website, the author of the book on Refactoring
• Website of Michael Feathers, the author of the book on Legacy Code
• SOLID Principles
• Code Refactoring