Robby on Rails: Tag tdd

BDD is still kinky

Robby Russell — Tue, 10 Apr 2007 16:51:00 -0500

I still believe that Behavior-Driven Development is kinkier than Test-Driven Development...

Embracing Failure, part 1

Robby Russell — Tue, 10 Apr 2007 16:38:00 -0500

I’m currently reading To Engineer is Human, by Henry Petroski and found the following applicable to software development and managing client and customer expectations.

“As much as it is human to make mistakes, it is also human to want to avoid them. Murphy’s Law, holding that anything that can go wrong will, is not a law of nature but a joke. All the light bulbs that last until we tire of the lamp, all the shoelaces that outlast their shoes, all the automobiles that give trouble-free service until they are traded in have the last laugh on Murphy. Just as he will not outlive his law, so nothing manufactured can be or is expected to last forever. Once we recognize this elementary fact, the possibility of a machine or a building being as near to perfect for its designed lifetime as its creators may strive to be for theirs is not only a realistic goal but also a reasonable expectation for consumers. It is only when we set ourselves such an unrealistic goal as buying a shoelace that will never break, inventing a perpetual motion machine, or building a vehicle that will never break down that we appear to be fools and not rational beings.”

I’m sure that most of us are guilty of having high expectations for products that we purchased. (why does my ipod screen scratch so easily when in my pocket?) We also set high expectations for the code that we develop, which is why we (hopefully) continue to refine our process. We’re bound to time and budget constraints, which often prevent us from testing every imaginable edge case. Given our constraints, problems are almost always going to arise. It’s no wonder that we see Test-Driven Development as an important part of a healthy development process. We want to catch our failures as early as possible.

Our clients often have high expectations and it’s almost always very reasonable. That’s not to say that some clients will not have highly irrational expectations. It’s our job to manage these expectations as best as possible.

Do we mislead our clients by convincing them that our TDD/BDD process is going to prevent any bugs from creeping from the woodwork after the development cycle is finished?

“I thought that we paid you to fully test the code?”

Really… is that even possible? Can we predict (and test) every possible interaction within an application? Highly unlikely.

What we can do is plan for and embrace failure. We can help our clients understand that almost every application needs to be maintained after it’s initial development cycle. Bugs are inevitable and there needs to be a clear process for handling them.

Perhaps I’m abusing the bug fixing process by calling it a failure… but I’ve also found that yes… many bugs are due to failure. Whether that be a failure to specify application behavior, a failure to understand the project goals, a failure in communication, ...or maybe a failure in our software architecture. We’re constantly failing.. and it’s okay!

IT’S OKAY TO FAIL! (some of the time…)

“No one wants to learn by mistakes, but we cannot learn enough from successes to go beyond the state of the art. Contrary to their popular characterization as intellectual conservatives, engineers are really among the avant-garde. They are constantly seeking to employ new concepts to reduce the weigh and thus the cost of their structures, and they are constantly striving to do more with less so the resulting structure represents an efficient use of materials. The engineer always believes he is trying something without error, but the truth of the matter is that each new structure can be a new trial. In the meantime the layman, whose spokesman is often a poet or writer, can be threatened by both the failures and the successes. Such is the nature not only of science and engineering, but of all human endeavors.”

As we’re creating these virtual structures… are we really taking the time to reflect on our failures? This is why some teams adopt practices like iteration retrospectives and post-mortems.

I’ll end this with a few questions, which I hope that you’ll share your experiences about…

In what ways is your team embracing the failures of your development projects?
How do you help manage your clients expectations… so that they too can plan for and embrace failure? Isn’t their new business venture on the web… likely to experience some failure?

We have so much to learn…

Is BDD kinkier than TDD?

Robby Russell — Thu, 08 Feb 2007 13:20:00 -0600

If you’re in need of a compelling reason to switch from Test-Driven Development to Behavior-Driven Development... consider this.

“BDD sounds kinkier.” -Michael K. Loukides, Book Editor for O’Reilly

...on that bombshell... I am going to suggest that this be used as the official BDD logo.

There you have it. Deep down… the biggest reason that I switched from Test::Unit to RSpec... was the sex appeal. ;-)

What was your reason?

Keeping the Code Organic

Robby Russell — Sat, 29 Oct 2005 20:30:00 -0500

The landscape around us is quickly changing-~~really, it has been changing for some time now~~-we’ve come a point where we admit that it’s okay to want more for less. We want more features, in less time. We want more control, for less money. Why? When did we collectively decide that huge monolithic systems could be completed in a fraction of the time it should take?

After years of working in .NET, PHP, Perl, and even a little Python, I have gone down the road of simplicity. I want simple looking code (thank you Ruby). Code that I can hand off to another developer and for them to simply get it—which helps to keep things moving. It’s about getting the project done.

Scenario: The client wants delivery in X days, so you aim for Y days early. Shortcuts get made, tests are forgotten, code is blemished, and deadlines still manage to sneak by unmet. Why do we do this to ourselves?

I say, no more!

Sacrifices Are Okay

What? You mean I can choose to leave something out? I can-~~dare, I say~~-tell my client no? Yes! Well, maybe. It’s time to re-think how you view your projects. Have you asked your client, “What is the single-most-important feature of this project?” Every project has one. Your customer will likely be relieved to hear that you care about the purpose of the project. And it gives you an idea as to where not to make sacrifices, which in turn helps to identify the areas where you can.

So, if you haven’t asked them yet… ask them now.

The Big Picture

If things change, how will it impact your timeframe? When your schedule is threatened, it becomes easier to see what isn’t necessary, or perhaps, not necessary right now.

All features in a project are part of the big pictures. If you ask your client what is required they will almost always respond with the all to easy, “everything.” Simply accepting this as fact often leads to shoddy workmanship in favor of giving your client “everything.” To the client it may seem like you aced the test, but that’s because they don’t know you’ve cheated. I’m sure a lot of you know what it’s like to inherit the code of someone who has done this, and you know you’ve probably been on the other end as well.

A Neverending Story

Projects aren’t just instantly created, they evolve. They need to be fine-tuned, maintained and should most certainly be refactored when necessary. Most projects require ongoing work… because requirements do change.

It’s time to stop and really consider how you approach both your clients and their projects. Can the next project be built in an evolutionary fashion? Can you focus on one new feature at a time, maintaining your tests, and avoiding bloat?

“Big fleas have little fleas Upon their backs to bite ‘em: Little fleas have lesser fleas And so ad infinitum.”

I found this in a book that I picked up at the local Library booksale for something like 20 cents. The book, The New Utopians by, Robert Boguslaw was written in 1965 and has some insightful thoughts on systems as organisms.

Keep it Organic

Pesticides are not necesary to produce quality produce. They are a cheap shortcut that can cause other problems in the longrun, and are generally not a healthy addition to the lifecycle of the fruit or vegetable (or to those who harvest it and consume it).

Test-Driven Development allows you to constantly monitor the behavior of your application. Feature-Driven Development keeps your team focused on what is currently the most important piece of your project. Don’t rely on pesticide, let the project flow the way it wants to.

Keep it Flexible

Business Rules should not be flexible… but they should. That sounds confusing, but it’s not. Know where to make that distinction. Add your rules first… build your tests… then code. Maintain flexibility through your rules.

Test First. Code Second. Lather. Rinse. Repeat.

Be Proud of Your Code, But Not Blinded By It

You’re biased. Your code is biased. The opinion that you have about your code is biased. You are proud of your code… but you can do it better and some people are better at somethings than you are. Don’t dwell on it, embrace it.

How many of you are making the mistake of being the only programmer on a project? I’m not a big fan of big teams, but I know that small and focused teams are extremly productive and better positioned for the big projects of tomorrow. Find someone that you trust and trade peer-review time. Not sure where to start? Pick up a copy of Refactoring. It’s time that you RE-think how you are doing things.

Embrace Heuristics

It’s time to challenge yourself. A new year is almost upon us and we’re all behind on our goals… because things change. This is the time to explore your possibilities. Learn something new. Don’t be afraid to break things. Just learn why the thing broke. Learn to be a good tester. Learn to write cleaner code. Learn to refactor your code. Learn to make it readable.

Learn to learn… and remember to buy organic. ;-)