The software development community has been talking about practices in an informal way for a very long time - more than 50 years. In the way the community talks, a “practice” is just something that people do, a habit they have that may be good, or perhaps not good. Talking about practices in this way makes for good conversation, but it is hard to figure out how to combine good practices into something meaningful.
I like to talk about practices in a more precise way, so I will refer to these as Practices (with a capital ‘P’). With a more precise definition we can do some interesting things: we can combine them (or compose them) in interesting ways, and we can separate them to allow us to replace a practice with a better one.
In earlier blogs I have discussed Practices. Practices are, in effect, the use cases of software development: they describe an independent set of actions that a team takes that delivers meaningful value in the software development process.
Practices rely upon a process kernel that describes the fundamental invariants that all methods always have, such as activities for specifying, architecting, designing, coding and testing software and artifacts (documented or undocumented) for requirements, architecture, code and test. The kernel helps us to normalize the descriptions of Practices by giving them a common foundation. It provides the basic vocabulary and concepts underlying all Practices. Practices that are described as extensions to this kernel can be combined and composed in simple and understandable ways.
Practices remove the need to have one single monolithic, all-encompassing method or process. In the Practice world a method is just a set of separate but complementary Practices. This reduces the complexity of improving processes - it can be improved a Practice at a time.
You also don’t need to force every team in your company to use the same method or process. Practices can be chosen and composed based on the needs of the project and the skills of the team. Your company can set up an internal community of practices to allow people to share experiences, to learn about practices and to build a practice library.
Precise Practices are practical, because they are much easier to learn and adopt than learning and adopting a method or process. They ”are as simple as possible but not simpler” to quote Einstein.
Very few people read process books, and the ones who do usually seem to misunderstand the point. This is why we have described our Practices on index cards. A single practice is described on ten to twenty such cards, forcing the Practice to focus on the essentials – the most important information you need to know about it. If you learn the essentials you can figure out the rest by yourself with a little help from someone more experienced.
The idea of Practices has started to catch on, and it is being adopted by many people and in many organizations. Even companies like IBM and Microsoft are coming around. That is a good start, but we need to make sure that the Practice is really good - something useful to a team - something that simplifies software development and makes it clearer how to work. That is smart!