This content originally appeared on Bits and Pieces - Medium and was authored by Philipp Rembold
The following is a summary of and some additional comments on the chapter ‘Technical Practices’ from the Book ‘Clean Agile’ by Robert C. Martin. Reading the entire book is highly recommended. While all or most of them are already well-known in the ASE community, these four practices, their interplay and the role they play in agile software engineering should also be considered together in one article and not only be presented as discrete practices which can or cannot be adopted.
Test Driven Development (TDD)
The three rules of TDD
- Do not write any production code unless a failing test proves that the code is needed
- Do not write more of a test than is necessary to fail that test. Failure to compile fails the test
- Do not write more production code than is necessary to pass the failing test
These rules enforce a very short cycle of programming that feels very awkward at first, but it prevents you from making stupid mistakes — and we all need this at times. And at any point in time, everything worked just a minute before and you can always go back to that state if you made a mess — and we all do this at times.
TDD is hard and requires discipline and practice
- We do not do test driven development because it is easy.
- We do it because it helps us writing good quality software with high velocity and very few bugs.
- We do it to reduce the time we spend debugging and then banging our heads against the wall because some jerk (we) forgot to set the return value or switched an if/else condition inadvertently.
- We do it to be able to prove, with the push of a button, that each class in our system works as designed.
- We do it to document, in a language each software developer understands, the desired behavior of the system.
- We do it so we can implement new features without fear of breaking existing functionality.
- We do it so we can improve the structure of our code (refactoring) without fear of breaking the functionality.
- We do it so writing the tests is fun and does not feel like a chore.
- We do it, in short, to improve our quality of life as a software engineer.
Practicing TDD needs some time, and in the beginning, it will feel highly unnatural. Doing it on so called “Katas” is a good way to start: when you have some slack time, implement a roman numeral parser, create a function returning the prime factors of a natural number or solve the change-making problem. Do it together with another person, maybe someone who already practices TDD for some time, and have fun with it.
Documentation, Fun, Fear and Prove
These points deserve a little more elaboration.
- Documentation habitually lies.
It is not written together with the code, but after the fact or even beforehand. It is not regularly updated, and sometimes, it is written badly and easy to misunderstand. However, working tests written beforehand where every new test needed a new bit of productive code to succeed, document the behavior of a class or system or API completely. If good patterns are applied, e.g. the test data class pattern, these tests read better than any classical documentation. - It’s not fun to write tests for existing code.
At some point, some edge case will be difficult to test, some call to a legacy function not easy to mock and also, we have done manual tests and it works and it’s already 17:00 and we want to spend some time with our family or friends — and then there are tests, but the tests are not complete. They might not test “trivial” things or the really bad edge cases, and that’s a giant pitfall.
However, if we write the tests beforehand, it is fun. We break our own code, but then we make it run again. Then we write a test to break it again and that works, which is satisfying. And then we make it work again, which is even more satisfying. At the end of a long TDD session, it feels like a really good and fun workout for the brain. - You see bad code — and you think “I need to clean it up”.
And then you think: “If I touch it, I will break it. If I break it, it will be mine. If it is mine, my life will be hell”. And so, we do not improve the code but try to build a skyscraper on a rubbish heap. Spoiler: it will collapse. Now, if there are really good tests and we can run them in a few seconds or even faster and prove to ourselves that we did not break anything by refactoring the code, the fear of breaking things is gone. Also, adding new features is way more fun if we know we did not break anything which already existed. - The prove of the pudding lies in the eating?
Well, in the kitchen, there are no automated, repeatable tests. In software development, there are, and unit tests written by following the three laws of TDD, while not being formal prove of correctness, offer a highly reliable heuristic. It provides a code coverage of 100% (sic!) and in most cases, a branch coverage of 100% (sic!). We can, with high certainty, say that when all tests pass, all the classes work as designed. So we do not actually have to eat our pudding or use our software to prove it works — we can test it.
Warning: Having automated integration and component tests in addition to the unit tests still is necessary, we need to prove that all the puzzle pieces combine correctly. After all, having all working parts does not make the car run, combining them correctly is still a major part of the work. However, an additional benefit of TDD is that our code is easy to test, and writing those component- or system tests is not complicated.
Refactoring
Refactoring is what we do with code which has grown ugly — in whatever way. We can even do refactoring to prevent code from becoming ugly in the first place. It is a structural change of the code without changing its behaviour. It starts with the renaming of methods and variables and reaches up to the complete redesign of a far-too-big class into many small classes. Abstractions will be introduced to reduce coupling; duplications will be removed… there is a multitude of refactoring techniques and describing them here is neither useful nor possible. There are excellent books on the topic, Martin Fowler’s “Refactoring: Improving the Design of Existing Code is recommended.
However, a few points bear mentioning here nonetheless:
- After each refactoring step, all the tests must still pass.
- Only refactor when all tests pass.
- Refactor product code and test code — bad test code makes life unnecessarily hard.
- Do not try to be clever or save time by doing big steps. Sometimes it works, but when it does not, much time is lost and much frustration occurs.
- Concentrate on making the tests run first. Once they do, clean up the code. Coding is not lab work: working clean at every point in time is not only unnecessary, it is unnecessarily hard and it is okay to have intermediate code versions that are not “clean” in every aspect. Just clean up in one of the next steps.
Example: 1. Introduce new code with code duplication 2. Make all tests pass 3. Remove the code duplication by introducing a new method
Simple Design
Robert C. Martin writes:
The practice of Simple design is one of the goals of Refactoring. Simple Design is the practice of writing only the code that is required with a structure that keeps it simplest, smallest, and most expressive.
Kent Beck’s of Simple Design are as follows:
- Pass all the tests
- Reveal the intent
- Remove Duplication
- Decrease Elements
The numbers are both the order in which these are executed and the priority they are given
The end goal is to have a working system (fulfilling 1.) which is easily read and understood (fulfilling 2) where no code is written more often then necessary (fulfilling 3) where the number of classes, methods, variables etc. is as small as possible without violating any of the former three.
The complexity of a design is one of the aspects determining how easily an application is understood and changed. It has an influence on how fast new team members can be on-boarded and how much time is needed to implement a new feature. In short, an overly complex design has an adverse impact on productivity.
The other main aspect of how easily an application is understood and changed is the complexity of the requirements. Is it a highly configurable book-keeping system able to comply with obscure laws or is it “Minesweeper”?
These two aspects are, however, not additive. An application fulfilling very complex requirements can employ a highly sophisticated design to make the application easier to understand than it would be if the design was naive, not simple. We strive to make our design as plain as possible while serving to reduce the complexity of the requirements which, in this article’s author’s opinion, is the more relevant aspect when determining how easily an application is understood.
Pair Programming
Pair programming is the technique where two (or more) programmers work on a programming problem together. Pairing is entirely voluntary and there are many different ways pairing can be done. However, it is recommended to spend at least a few hours each day working with someone else on their programming problems or getting someone to assist in one’s own. More experienced programmers should pair with less experienced to share their experience and get unforeseen insights. Less experienced programmers should ask for help from more experienced programmers more often than from other inexperienced programmers. Pairing is a great way to learn and share knowledge and all those little tricks needed to write code efficiently.
Pairing, preferably with different partners, is a great way to ensure that no knowledge-islands are created in a team, so that common ownership for the code can develop organically. Pairing also covers code review — if the code has been written by a pair and passes all the tests, then it is probably good enough at least until the next pair works on the same code.
The development velocity of a pair will be slower than that of two developers working on their own — if observed over a short period of time. Robert C. Martin quotes studies observing an overall loss of about 15%. However, this investment pays off in higher quality, better design and higher team resilience. It is unclear whether these studies factor in the time gained by omitting formal code review after the pairing. It might be that actually, pairing has no adverse impact on development velocity at all; but even if there is such an impact, the benefits outweigh this by far.
Interplay of the practices
TDD enables Refactoring
The most obvious point is probably that test driven development enables refactoring. Being able to say, with a high degree of certainty, that a change to the structure of some code does not change the behavior of that same code allows us to do a refactoring, however “small” or “big” it is perceived and be sure we did not break anything. This is the key to never again be in the situation where we cannot add a simple feature to our program because it needs a redesign and that is just too risky. However, that redesign will still have a cost, and that cost can be managed by following the practice of
Simple Design enabled by Refactoring
Recall that the intent of simple design is to create a system where the design is just complex enough to manage the complexity of the requirements the system shall meet. If we have reached that happy state after each requirement is implemented, implementing the next new small feature shall not require a massive redesign. And we reach that happy state by continuous refactoring.
Simple Design created by Pairs
The more complex the problem, the more we need someone with whom to discuss the issue. And since programming still is a complex problem, even if we follow all the rules, pairing is, for that reason alone, a very beneficial practice. However, from these four practices, pairing stands out in that it is not as technical as the others. It is hard to point out where the immediate connection between paring and the other practices is. However, each of these other practices is easier to follow when working tightly together with someone else, and to me, the practice of simple design is the one pairing has the greatest positive impact on.
Technical Practices in a SCRUM Team
We have now discussed the four technical practices as presented by Robert C. Martin and how they are interconnected. But what is their meaning in an agile software project?
Martin Fowler writes:
There’s a mess I’ve heard about with quite a few projects recently. It works out like this:
- They want to use an agile process, and pick Scrum
- They adopt the Scrum practices, and maybe even the principles
- After a while progress is slow because the code base is a mess
What’s happened is that they haven’t paid enough attention to the internal quality of their software. If you make that mistake you’ll soon find your productivity dragged down because it’s much harder to add new features than you’d like. You’ve taken on a crippling TechnicalDebt and your scrum has gone weak at the knees. (And if you’ve been in a real scrum, you’ll know that’s a Bad Thing.)
Following the scrum framework without following the technical practices that enable you to create good software leads to something Fowler aptly dubbed ‘Flaccid Scrum’.
Let me underline that:
The technical practices are what enables us to create good software; there are — possibly — other ways, but these technical practices have proven their worth, they make a software project result in good software.
The non-technical practices make a software project manageable; following them, we minimize waste, are able to tell the stakeholders early that (not if…) we’ll not meet the timelines they hoped for and overall do not make a mess out of the project.
Following both will hopefully result in a successful software project.
Let’s briefly address the interplay between certain scrum artefacts and the technical practices:
- the Daily Standup is an excellent occasion to arrange for a pairing session.
- the Retrospective can be used to evaluate certain design decisions and how they impacted development. It can be used to share experience gained when refactoring parts of the system.
- the Planning and Refinement can both be used to identify those parts of the system requiring a (hopefully small) redesign to implement the user story
Conclusion
These four technical practices are indispensable for agile software development projects. Without following them, the codebase will inevitably become so messy that the development velocity will decrease until any further development causes massive cost and risks. This is largely due to the high value we place on agility, i.e. our ability to react to changing requirements quickly. They are, in short, the software equivalence of the old adage a stitch in time saves nine.
Build composable web applications
Don’t build web monoliths. Use Bit to create and compose decoupled software components — in your favorite frameworks like React or Node. Build scalable and modular applications with a powerful and enjoyable dev experience.
Bring your team to Bit Cloud to host and collaborate on components together, and speed up, scale, and standardize development as a team. Try composable frontends with a Design System or Micro Frontends, or explore the composable backend with serverside components.
Learn More
- How We Build Micro Frontends
- How we Build a Component Design System
- The Composable Enterprise: A Guide
- 7 Tools for Faster Frontend Development in 2022
Four Technical Practices Facilitating Agile Software Engineering was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Philipp Rembold
Philipp Rembold | Sciencx (2022-04-11T19:44:07+00:00) Four Technical Practices Facilitating Agile Software Engineering. Retrieved from https://www.scien.cx/2022/04/11/four-technical-practices-facilitating-agile-software-engineering/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.