This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Learning Your Agile Scales – Part 2
In Part 1 of “Learning Your Agile Scales” I why it’s important to learn and practice your scales in agile development. Here we will cover three forms of scales you should make part of your basic language: Test Driven-Development, Object Oriented principles (SOLID) and Patterns.
Test Driven Development
Writing a test prior to writing your code is not very controversial anymore. Everyone recognizes the value in doing this. And yet, most programmers will maybe write a few tests to get started, but then quickly move to an attitude of “I don’t have time right now; I’ll get to them later.” This is totally understandable since the idea of writing tests first still feels counter-intuitive. So do minor scales. It takes repetition and practice to get this activity into our “muscle memory.” Sometimes what we are doing is uncomfortable, or feels like it’s wasting time. We do it slowly at first. But over time, it becomes an instinct.
This instinctive activity is not going to happen just by doing it at work either. Just as Uncle Bob Martin asserts in his latest book, Clean Coders, we need to practice at home, also. Find a project or site where you can practice writing tests and making them pass. Get used to the idea of writing a test and then working to the “green bar.” We’ll talk more about practicing in a later post, though. Suffice to say, you need to practice, and a true professional will practice at home.
Another form of scales is Object Oriented principles. The best description of the principles that lead us to true success is the acronym SOLID. This has been identified and explored in many forums, so I will only touch on them briefly. For a deeper dive, check out Robert C. Martin’s book, Agile Software Development, Principles Patterns and Practices. Here is a link to an early article he posted on the subject. Meanwhile, for your dancing and dining pleasure, here are the SOLID principles, in brief:
- Single Responsibility – An object should have one and only one reason to change.
- Open-Closed – A class should be open to extension, but closed to modification.
- Liskov Substitution – Derived classes must be substitutable for their base classes.
- Interface Segregation – Clients should not depend on methods they don’t use.
- Dependency Inversion – Modules should depend on absractions, not details.
One interesting parallel to our musical paradigm here is that, as you start to get very comfortable with staying within these principles, you start to notice things that are not quite right. You are so used to looking at code that fits within the SOLID principles that it just seems natural. Code constructs that violate these principles come across as out of tune — something we refer to in music quite often as “klunkers.”
The final scale I want to talk about is Design Patterns. Patterns are another part of our basic language. We need to work with them and be comfortable with them. I am not a huge fan of saying, “Here is a problem; which pattern shall I apply to it?” That feels artificial to me. However, I also remember a time when I was just learning music that I did consciously say, “Now I am going to play notes from the B-flat blues progression.” As we are using patterns, we become more comfortable with looking at a problem and just knowing what we are going to do to implement it. Later, when discussing it with someone, we note that what we did was apply a Visitor pattern.
So, in conclusion, even though it isn’t anywhere near as much fun as just going out there and soloing, we need to learn and practice our scales. It isn’t enough to read about them once, or to pull them out of our bag of tricks when we have enough time or remember to use them. They need to be a part of what we do every day, and they need to be so ingrained in our brains that we don’t even notice when we use them. Hey, if it’s good enough for the greatest performers and innovators who ever lived, surely it’s good enough for us.
What about Refactoring, you ask? Refactoring is hugely valuable and extraordinarily important. It is so important that I want to save it for next time, when we talk about Practicing. Now I gotta run. I gotta go practice.