Software bureaucracy is overkill
This is a story of two applications being developed one by bureaucratic methods and one by continuously integrating user feedback. Not long time ago (about two years ago) me and some friends started working on a project using agile methods of test driven development. We had a test for almost everything and at the launch we had a application with 0 bugs still running today. The sole problem with this app was that it didn't get the user's touch. We designed the screens, we impersonated the users for user cases and so on; but it missed one thing: REAL USERS.
About a year after the launch of the first app started the work on the second one. This one was tested with the users from day 0. In fact, it was created because users told us that they want it. It was so focused on the main feature, that it even had no signup form. It was quickly packed and delivered to the users with only it's core functionality.
Of both apps today, the first one is on hold, the second is growing everyday; exponentially!
I'm not advocating against test driven development, incremental development (it's what we are doing for both apps) but I'm advocating to the use of this methods when they are really needed.
When developing applications I try to guide by these rules:
- if a feature it's not controlling life support of a person (or it's money) do only a basic set of tests (smoke testing and click testing give you the best results)
- don't write behavioral tests. The behavior of your application is very likely to change in the initial iteration, so don't write a bunch of useless tests and is the behavior. You will end up refactoring tests instead of code
- DON'T write logins (use openid, facebook connect, oka) you name it and skip the fuss of managing login information
- when the concept is ready throw the app into the web
- make the developers use the application. Since I use the application I'm working on, i feel my karma glowing; and that's a good thing; also I have a clue about what the f*(#$ this application do beside AJAX requests and SQL queries
And a good illustration of all these things by Geek and Poke
March 3rd, 2010 - 11:22
look like you’ve got a blog, finally
congrats
March 3rd, 2010 - 11:32
looks like.
March 3rd, 2010 - 13:42
I completely agree with you. Nothing beats the stupid randomness of a user visiting your app. That’s why I say that the testing process will never be completed during the lifetime of an app.
March 3rd, 2010 - 18:33
TDD is meant for things users can’t test. For the rest, just make sure your app doesn’t break and the rest will take care of itself.
And yes, release early, release often works so much better than coding in a black box.
Nice tagline
March 3rd, 2010 - 22:28
I disagree with the rule. As the complexity of the project increases, the lack of automated tests makes every new feature or bug fix a potential bug creator.
The dread of having a customer call to inform that something else is broken after each new feature has, in time, overcome my laziness.
March 4th, 2010 - 10:11
@COS: I wasn’t advocating not to automate test, but do it when it’s really necessary eg. recurring bug and not take TDD just as it writes in the books and write the test before every feature.
You will end up having a bunch of test, you will find yourself adjusting them rather then having an application.
March 5th, 2010 - 17:16
Calin, you got one thing wrong. You should not have to change the tests. Unless they’re for thridparty API`s that might change.
Otherwise, the test should be well though-out and you should never have to change it.
March 7th, 2010 - 13:28
Theoretically.