Agile Principles: Excellent Design Needs BDD & TDD

larry apke, agile doctor, bdd, tdd, excellent design, agile principles

larry apke, agile doctor, bdd, tdd, excellent design, agile principles

This principle is much like the one previous about sustainable development. Agile doesn’t ask us to shortcut quality and increase technical debt in an effort to deliver software faster. It is precisely because we do not shortcut quality and incur technical debt that we are able to move faster.

I have worked with many teams to introduce Behavior Driven Development (BDD) because, among a great number of other advantages, BDD allows developers an easier way to access the practice of Test Driven Development (TDD). And, in my experience, TDD is the only way I have seen out of the practice of “Big Up Front Design”.

Big Up Front Design is generally a waterfall practice in that architects and designers spend a great amount of time before coding begins to attempt to foresee all possible design considerations in advance so that the final design could be implemented without issues. The problems with this approach are outlined wonderfully in Martin Fowler’s “Is Design Dead?” blog.

The one I would concentrate most on is the issue of changing requirements. Since most of software development falls in the complex quadrant (see my Complexity Theory and Why Waterfall Development Works (Sometimes) presentation), it generally has a great deal of nonlinearity (sometimes referred to as the “butterfly effect”). This means that any small change in requirements can have a great ripple effect, usually nullifying the extensive work that designers and architects (our experts) have created.

If you want a rule of thumb measure of an organization’s (or team’s) relative agility, bring up the word refactor. A rigid organization will recoil in horror while an agile one will recognize refactoring as desirable. The answer to nonlinearity is the concept of evolutionary design and this is simply not possible without refactoring and refactoring is simply not possible without a safety net. That safety net is created by a suite of tests that were created as a result of TDD (using something like BDD) and are leveraged via continuous integration and continuous delivery.

With respect to this principle, continuous attention to technical excellence is expressed through the XP practices of BDD/TDD and CI/CD, learning how to create testable requirements (via BDD) which are expressed through tests created prior to coding (TDD) and through near instantaneous feedback (CI/CD). I can be assured that my refactoring of design addresses not only the new requirements but also the legion of existing requirements (through automated regression) so that nonlinearity is not expressed through regression defects in the final product.

Because of the technical excellence above I can then use evolutionary design to create not just “good” but excellent design.

“This might all sound fine,” you say, “but I live in the real world and it doesn’t work for us because of (fill in your favorite excuse).”

To you I say, yes, it does work.

No matter what your situation, you can leverage the above practices. That is not to say that it won’t be challenging because you may be struggling with existing technical debt, but it is possible if your organization had the understanding of the costs of not adhering to this principle.

For the skeptics out there I leave you with a little story:

There was one team that I worked with to teach BDD/TDD and pushed them to adopt these practices. Though they were initially skeptical, they did it anyway. After only a few short days they began to see the “method to my madness” and roundly declared that this was the way that all software should be developed.

After a few months of success, they were asked to present what they learned to other teams. Like a proud father I stood in the background and listened to what they said. Not only did they say that they couldn’t imagine doing software development without these practices, but that there were times that they felt pressured (as we all do at times) to produce software faster and they shortcut the processes and every time they did, it was this code that was identified later to have defects; defects that they had to spend time fixing.

Because the time spent finding and fixing code that wasn’t created using TDD was greater than if they had slowed down and done the initial coding properly, trying to write code faster by neglecting technical excellence was actually slower in the long run.

To this day these folks that I had the pleasure of teaching a bit of technical excellence to email me from time to time to tell me that they have convinced yet another team (or vendor) to pursue technical excellence.

Why? Because continuous attention to technical excellence and good design enhances agility.

Larry Apke

We Must Inject (not just inspect) Quality

quality inspection for blog

Not sure where I first heard the phrase “you can’t inspect quality into a product” but I have certainly used the phrase myself all too often in my consulting gigs. After a quick Google search, I found the originator of the quote was Harold Dodge and it was first used in a manufacturing context. While I generally eschew appropriating manufacturing analogies for comparison to software development, in this case, it is certainly apt.

In many of the companies I consult with, the prevalent view of “quality” is nothing more than inspection after the fact, a misplaced notion that quality can be insured by finding all of the defects built into the software. The great majority of these inspections are conducted by a separate team, a half a world away by manually banging on keyboards and mice. If one were to write an article on how NOT to ensure software quality it would look frighteningly similar to this (which is what I experience all too frequently when I work with companies).

I find that often this goes hand in hand with the mistaken notion that we are performing projects as opposed to creating long term stable quality products. In some cases our quality leaders are merely naive or simply unquestioningly following the misguided policies and practices of those who came before. For those who truly wish to understand true software quality, who desire to build quality into a product instead of merely trying to inspect it out, what practices should we use?

The first thing is to recognize that building quality into our software code must begin with those who are building the software, the developers. We might have some nice motivational posters that state quality is everyone’s business, but until we tear down the arbitrary and dangerous walls we have erected (incorrectly taking waterfall to its bizarre conclusion) between development and “testers” we will certainly fail to put quality into the code. Development can ensure the quality comes first by writing tests first and performing true TDD (test driven development).

Sometimes, as Dan North found, developers may be convinced that TDD is a great idea yet find it difficult to implement. This is a great opportunity to inject BDD (behavior driven development) as a means of helping developers with TDD. In fact, I often recommend that BDD style scenarios can be used to express acceptance criteria even if developers are not yet ready for TDD. The tremendous increase in understanding and early inclusion of test cases as expressed through scenarios is the biggest benefit of BDD and goes a long way to injecting quality into our code.

Another technique for injecting quality is the concept of code review. There is nothing like another set of eyes to make sure that our code is high quality before we push it out of the development environment. You may want to go one better and get a more immediate feedback through pair programming. Like many things in software development pair programming is counter intuitive but the quality of code produced by judicious use of pairing far outweighs the perceived “double” expense.

Akin to code reviews conducted by humans is the ability of code to be “reviewed” by software through static code analysis tools. This software can “read” code and determine “quality” through a set of programmed rules. It will, for example, let you know which classes are too long or complex. These rules become instant feedback for code in progress and help us to easily avoid technical debt. For existing code these tools can help us to understand existing code quality and provide us with candidates for refactoring.

Whatever the technique you choose, the key is to understand that quality is something that is built into the code not something that we can inspect out.

Recent Agile Speaking Engagements

Boy it’s been some time since I have blogged! I have been busy with all things business, personal and have had a great number of recent speaking engagements with any free time I have been able to find. I am passionate about Agile and love the opportunity that speaking brings.

My most recent gigs included a bunch of talks when my body was suffering a annoying fall head cold.

Continue reading “Recent Agile Speaking Engagements”

10 Reasons Why BDD Changes Everything

Goal, larry apke, bdd

Goal written on whiteboard

Recently I have been working with my two scrum teams to implement a BDD approach to our development. I’d have to say that the early results are astounding! While I have always known and believed in BDD in theory, I continue to be amazed by its simple power in practice. For anyone reading who is considering BDD adoption, below are 10 good reasons to move off of the sidelines and embrace BDD:

 

1. Communication between business and development is extremely focused as a result of common language.

A recent scrum team I lead was struggling during groomiing sessions to come up with valid acceptance criteria. After much excruciating pain we introduced ubiquitous language of BDD. What was taking days was accomplished in just a few hours with better quality forged from increased understanding of expected behavior.

2. Business needs tie directly to the code that is written.

The scenarios can be written by the business, testers and/or developers. Since the scenarios can be written by business and the scenarios create the tests, the code that satisfies the tests satisfies the business requirements. Simple.

3. Developers know what test cases they should write to accommodate TDD.

Most developers will see the wisdom in Test Driven Development, but they find it very hard to decide what tests to create. BDD eliminates this by having tests created directly from scenarios, making the process of deciding which tests to write a moot point.

4. All the underlying benefits of TDD become more easily realized.

These include: safer refactoring, fewer regression defects, greater ability of QA to concentrate on important tests, defects are found and fixed sooner.

5. Code is easier to maintain.

Studies have shown that about 90% of investment in software involves the maintenance of code after the initial “project” is complete. BDD means that all features have tests and these tests show how the code is used and make the code easier to understand and maintain.

6. Code is self documenting.

Similar to the point above. Your test cases and scenarios become your documentation. Using BDD will allow you to have updated documentation that is not separate from code, but integral to code. Documentation can be easily extracted and that documentation is understandable by anyone.

7. Stories are easier to “groom” – breakdown, task and plan.

I can better estimate a story that I have acceptance criteria for and the BDD scenarios become that acceptance criteria. Armed with the scenarios ahead of planning allows a team to better understand the work needed and estimate how long it will take to complete.

8. Teams can be more agile.

Like the point above – when your requirements are better understood, your acceptance criteria better known and estimates more accurate you can be more agile.

9. Developers can be trained / on-boarded easier.

Since the code is self-documenting and test cases show how the code should work, new developers have access to a wealth of information that is usually not available when they are brought on-board a project. This point alone should be a driving reason to adopt BDD as new developer training is usually steep.

10. There is more visibility into team progress and status.

One of the main benefits to Agile is to have visibility into team progress. The tasks for completing a story are broken into well-known pieces that burn down cleanly. For example, each scenario can be added to story as a task and tracked to completion to see how well the story is progressing.

I hope that you find my reasons compelling and that you too try BDD and see if it provides the benefits I outline.

Larry Apke