Our biggest defect

In Mary Poppendieck: test driven development redefined Gojko Adzic shares Mary's insights about what Test Driven Delopment is. Please read it, its a short post. He also shares a quote from Mary:

“the biggest defect we have now [in software development] is tolerating defects”

Currently in my workplace, we have some unit testing in place but there are many defects found during our process. I fully agree with Mary's appreciation, defects are a waste in our process and each defect should be a learning opportunity for killig the root cause, so it will never happen again.

Hey, really, if you find the same defect over and over again in your systems, obviously you need to do things differently! IMO, TDD offers a great base for us to use tests for automating such learning (documenting defects is not enough).

Recommended Reading: The 7 Software Development Wastes - Defects

Oh no, a long method... again...

A few days ago, a fellow coworker asked me to help her in fixing some "legacy unit tests". I'll explain why I call them "legacy", eventhough the code they test is relatively new.

The first test method "TestMethodX" tested MethodX that is located on a Presenter class (we use the Model-view-presenter pattern). We ran it and failed. Ok, lets try to fix it:

1. Following good design principles on the ModelViewPresenter pattern, your method should have just one responsibility so it has only one reason to change. TestMethodX was long, had a lot of data initialization and used Mock classes in a very confusing way. There were lots of repeated statements and wasn't self documented (or had any code comments whatsoever).

2. On an Object Programming style, you should assign responsabilities to different objects instead of having a large procedural method. The way, your design is loosely coupled and highly cohesive. That's a good thing. But MethodX was very long. It used the View class on strange ways and had lots of ifs, whiles and calls to other private methods. When you try to test such a method, I assure you you'll have a hard time understanding it. It's not fun.

Quoting Venkat Subramaniam from Agile Developer:

Long methods are evil on several grounds:

• They're hard to understand
• They're hard to change
• They're hard to reuse
• They're hard to test
• They have low cohesion
• They may have high coupling
• They ten to be overly complex

Often programmers ask, how "long" is a long method? A method is too long if

• you have to scroll down to look at the complete method
• it takes several minutes to understand
• you can't easily write an automated test for it
• you can't state the one prominent purpose for the method

3. The method wasn't developed on a TDD style for sure. TDD leads to simple design and promotes clear cohesive code. So, the programmer that did the tests, obviuously did them afterwards and just as a formalism. The final result was some test code that didn't add any value to the development process and to the product itself. Honestly, the original developer wasted his time doing that tests.

After reading the unit test and the tested code, we had two options:

1. To make the unit test pass and have it constantly verifying a confusing designed class.

2. To delete the unit test and just face the truth that the tested method should be redesigned.

At the end, we decided to delete the unit test cause its existence added no value at all. I'd really like to undeline the concept that Unit tests are a strong resource for helping in your design. The enfasis shouldn't be on Test, but on Design. They are not just a formalism, they are useful and the final result is great code. That's what we are talking about.

So, if you are a developer, please give it a try to TDD, write code in responde to a unit test. Test first, test early. Make small methods and write human readable code. We, the rest of the world, would really apreciate it! :-)

Recommended reading: How to convince your fellow developer to write short methods?

Stop writing bugs...

I read somewhere that the best way to solve bugs in our software is to avoid introducing them in the first place.

Too obvious?

Well, if you think about it, the one responsible for writing a bug is the programmer itself. Software doesn't breed bugs by itself. Humans put them there, and humans suffer the consequences: ugly code, broken builds, unhappy users, stressed programmers.

So, IMHO, the best way for avoiding bugs is to do TDD... In Test Driven Development, you write software according to a specific automated requeriment (unit test) and nothing more. Your design becomes more cohesive, simple and mantainable. I love automation, so I've always liked the idea of having code verifying code. I remember the first time I used JUnit (2000? maybe). Wow, the simple example of automating the tests of a calculator java class made me realize that there was more to writing software than just compiling and nice screens.

TDD is about automated requirements, good design, cool automation and fewer bugs. If you like the idea, maybe you can benefit from How to write good tests. Top 5 considerations to build software without defects. Oh! And if you can, please read James Shore The Art of Agile Development. Its really good in showing the big picture of what software development is about and how eXtreme Programming can help.

2 brief comments about TDD

I just found 2 cool introductory articles about test-driven. Maybe you'll be interested:

Test Driven Development part I : an Intro>

Test Driven Development part II : Code coverage

TDD Doesn't Make Development Take Longer!

Hi people, tonight I'm thinking about the conception that Test Driven Development makes your project take longer. I googled this post from Jeremy Miller and found it to be based on experience and really match what i've found on my own programming experience.

Some people say that a project can take longer cause you must write and maintain more code, and each time you suggest to include more quality in your software through tests you hear the same objections... but why is that?

Well, I think that is really a natural reaction and seems logical if you haven't developed the test-driven way (red-green-refactor). Some people think they have done TDD but they have just coded automated tests, but TDD is about design and continuous design. If you design the test-first way you are going to finish your code in a faster and better way... that's just a non issue for me. Your code will do what you supposed it should do, no more, no less. Why don't you try yourself? This is a pragmatic issue, if it works why don't we apply it and enjoy the benefits?

Jeremy Miller lists where he thinks TDD cuts development time, and I concur:

- Design
- Debugging
- Fixing bugs
- Testing

Let me add a few, IMHO:

Maintainability: When you develop the TDD way, you can refactor and change your code anytime and just enjoy the simplicity of good code and your unit tests are a safety net. That resumes in few development time and make programming more fun. Also, you can focus more in adding value to the code by reducing technical debt and improving your design cause good tests are you allies.
Trust in your own code: Since the days I started thinking and with TDD I trust much more in my code and feel more proud of it. I can even invite you to take a look any time and even make changes with confidence that my tests validate yours!
Trust in others code: if you honestly did TDD and you trust me your code for working on it, I'll feel very secure that your code will be simple, understandable and open to refactorings. We work in team environments, people come and go, and our code should be always hight quality. We'll save ourselves so much pain...

BUT, (and this is a big BUT), you'll enjoy all that benefits if you're honest and mindful about TDD. Please, don't do it as just a requisite. And PLEASE! Don't say that TDD is an overhead to software development if you haven't given yourself to learning how to do it and practicing for a little while. I can assure you, you won't regret.

If you want, take a look at this Introduction to Test Driven Design (TDD). Enjoy!

The Ferrary 599 and software

I was watching in the Discovery Channel a show about the Ferrari 599 and how they deliver the highest quality in that awesome machine. They seem so proud of their product! Every interviewed person was sure that his participation in the production process was important for the end product's quality.

I just wanna blog about two more things I realized:

- Each step in the Ferrari production process assessed it's quality. They knew which acceptance tests would allow the part in production (motor, leather parts, etc...) to go on in the process and be a part of a $240.000 car. Everything was done so they'd meet the expected quality... "Buyers are paying for perfection" they say. So, they minimized surprises, since they knew the expectations from the beginning.

- Any defect in the manufacturing process meant that piece would be rejected. If the chasis didn't meet the expectations, it was returned to the melting machine and they started clean with a new chasis. So, each process was sure that it was receiving quality parts.

The result?



Maybe we can learn something for our software development process!

1. Everything in the 599 manufacturing was done with the final product in mind. There was no waste. The process was well designed and executed with excellence. Do we do something during the process that doesn't add value to the final product? I'm not talking about not making any documentation. I'm sure everything in the 599 is well documented. I'm talking about being sure that every artifact, model and code adds value to "our Ferrari".

2. Validation: How do we define quality in our product? Is the user involved in that definition? Which are the acceptance tests that certify that your code does what the user expected? This practice is the one that is catching my attention lately. If we use some testing framework in collaboration with our customer to define the user's expectations, we'll be closer to define what quiality is for her. And, we are done when we find out that all of our acceptance tests are green.

Well, these are my thoughts; I think many people is doing great things with TDD and other agile practices... why don't we try them out and get the best of them?

New things! Check DbFit...

I was commenting with a partner today about how you can keep track of new technologies and practices. Software development is so pragmatic that an idea can be cataloged as "crazy" one day and the "silver bullet" the next... And the question is ¿what do you do as a professional software developer to be updated and share your new ideas with the community?

That's one reason why blogs are so great. They are free, easy to share, to update and you can keep up with their new contents with great readers (like Google Reader). Wow, when you are keeping track of 18 blogs and 9 podcasts there is something new every day, how cool is that?

If you want to start chewing a new idea right now, I recommend you the article Test-first development with FitNesse. I think maybe this could be the next big thing in automated testing.

Also, keep track of Test-driven database development with DbFit. I was chatting with the creator (Gojko Advic) and he has some great ideas he's applying on his projects. DbFit uses Fitnesse for creating your database tests in a wiki-style, with a very easy syntax and it manages the transactions so you don't leave corrupt data on your database. And Great news - SQLServer 2000 is now supported in DbFit for all of us who aren't still in 2005.

And of course, you can integrate Fitnesse and DbFit results into CruiseControl.Net, explained here.

So, there you have some new ideas, IMO with great potential to improve our software. Why don't you take some minutes to read that links and keep tracks of some related blogs? Check my blogs and podcasts on the sidebar. Stay fit!

We're on a cascade testing phase!

Honestly, there's not much excitement in delivering 359,000 lines of code of your project X into the hands of a fierce team of testers... but that's exactly where my team is right now.

SD Times reports that "A survey found that developers spent more time troubleshooting application problems than programming".

Scary! Most of us plan our schedules with lots of programming tasks and underestimate time for functional testing. That survey shows that a problem found after programming has a high cost. And if that survey predicts what the testing phase for project X is gonna be so expensive, the least we can do is to something from the experience...

What can we do? I find really interesting the philosophy that inspires Lean thinking and Agile practices. Although the project X I mentioned before is not driven by an agile methodology, we started applying Test driven development and Continuous Integration practices. I have learned a lot this year applying this practices, and I hope my team too.

The winning formula is:

Design Patterns + TDD + CI = better-tested-more maintainable code.

TDD, in my opinion, leads to a simple design which does exactly what's intended and can be continuously verified.
Design Patterns help us embrace change by making code thats more cohesive and less coupled.
CI is our feedback machine.

I don't think our software is bug-free, we are just starting to mature on this practices, but I hope to report some good things a few weeks from now. Until then, I encourage you to read more about TDD, CI and design patterns. I'm sharing some great podcasts and blogs on this page, and wish to hear your suggestions and comments. Make great code!