Posts tagged BDD

I recently listened to Jeremy Miller in the Alt.Net podcast, and I also watched the latest in the NHibernate series from TekPub. The common thread I see between both these things is the act of achievement in your own development life. Jeremy Miller talked about the state of Alt.Net and how he and others can further the cause of the movement. The main message I got was, get your house in order. Knowing who you are and what you do can go a long way in reducing the pain of development.

The TekPub series talks about NHibernate and integrating it into Rob Conery’s Kona project, but Oren Eine said something very interesting. NHibernate is a tool to keep you from doing the grunt work associated with a database. Which is exactly why I purchased the NHibernate series, I want to reduce the amount of time spent grunt working and optimize the time spent adding value.

This series of posts will be as much introspective as it is informative. I will look at things that cause me pain in my day to day development, and also explore methods to alleviate the pain (short of morphine shots).

Let’s start with the biggest area of pain, Bugs.

Bugs

No software developer likes to release code that has bugs in it, but bugs are an inevitable pain every developer will have to deal with. I personally have had my fair share of bugs, but I have always been able to resolve them quickly and effectively. The pain with dealing with bugs can come from two places: the act of trying to preemptively stop them, or the act of reacting.

Stopping Bugs

If you are anal about the code you write, then you probably employ some kind of testing methodology: Test Driven Development, Behavior Driven Development, Integration Testing. All These methods make sure your code works. The pain with using these methodologies is that they require a substantial amount of effort to implement. They require understanding and a time investment that some developers just don’t want to put in. I can’t say I blame anyone for not adopting a testing methodology, it takes discipline and dedication.

There are several test generating tools out there, but few really make the process any less painless. You usually are trading one set of pros and cons for another. The trick here is to build a system of developing tests regardless of tools you use. A system that is smaller in complexity is ideal. Test Driven Development has Red Green Development; a process where you get tests to fail then pass. A small but effective system of writing tests. A solid system can help bake practices in and make you more disciplined.

After understanding why I should write tests, I found that bugs in my code are melting away. It’s hard to make a test pass when all your assumptions are correct but the code isn’t. So am I saying that everyone should adopt a testing methodology? No I’m not, but I do recommend it to those developers who don’t like dealing with bugs later because it can substantially reduce those incidents.

So you’ve spent the time to write tests, but bugs still creep into your code. Time to panic! Aaaaah!

Fixing Bugs

I’ve seen this one too often. A bug is found and everyone goes into fire-drill mode. Managers hovering, programmers sweating, IT guys pushing continual updates. It is like watching a slow motion crash test. The problem usually get’s fixed, but not the best way. In addition, the fix usually introduces more bugs.

The solution here is to understand what is happening. Far too often, companies feel that panic mode is ok but it psychologically drains everyone involved. This can bring morale down and breed resentment amongst groups. Why didn’t the testers catch that major bug? How could the programmers have been so stupid? Why are the managers making me push a solution every 5 minutes? What happened to the order of things?

So how do you reduce this pain. Well I’ve experimented with a few options and found that sandboxing is the best course of action. A sandbox environment that is exactly like your production environment. This might seem obvious but the number one sin that most people commit is, they don’t respect the concept of those environment. A sandbox should be your first and only place you push code. Once you are happy, copy that exact environment over to production. There should never be any code directly pushed to production. Respect the structure you setup and it will help you, don’t respect it and it will come back to haunt you.

Beta environments are also a good way to reduce the pressure of critical bugs. Many application have employed this method with success. Create a clone of your web application/application that is strictly Beta. There is an implied agreement between you and your users that there are bugs and the experience might not be ideal. That way you won’t be surprised when a critical bug occurs, also your clients will hopefully understand why the application broke.

Conclusion

Bugs are a part of our development life. They are present and they will always be there. The best thing we can do is take an approach that makes it less painful in our development lives. Some developers are more comfortable writing tests to preemptively stomp bugs, while others thrive in the panicked environment of critical bugs. I personally feel that I don’t want to let bugs get out the door, so I test everything with a three pronged approach. Unit Testing, Integration Testing, and Quality Assurance.