Categories
Development

Automate it all

When doing Agile development identifying and eliminating waste is a important practice. There is many things to eliminate, but one of the usual remedies is to automate a manual and error prone task. In my experience it is worth spending a lot of time automating tasks, not just because it saves time but because it gives you predictability.

Taking automation and predictability all the way would probably lead you to something like Continious Production that Paul Duvall has a post on. Johannes Brodwall also has some good perspectives on something similar.

It is sort of the holy grail of agile development, and would be something like what Jeff Sutherland said the are doing at Patientkeeper. They have deploy at the push of a button that enables them to deploy new versions to all their customers on a regular basis.

Spend time automating people. 🙂

Categories
Development

Our responsibility as good developers

InfoQ summarizes a couple of blog entries discussing what responsibility we have as good developers when the customer asks you to take a shortut. They’ve put the word agile in there too, but regardless of agile or not this is important issues. In short there are two views:

  • Say no. You can’t allow anyone to do that, you know there will be bad consequences.
  • Say yes. It’s the customer that will have to maintain the ugly code, and he is paying, so let him have what he wants.

I know it’s not easy saying no. Not a lot of developers can afford to start a big argument with their customer, so we all often just do it. But this is always wrong.

The problem with saying yes and it’s argument is the perspective. The perspective outlined in the argument suggests that maintenance of the ugly code will come somewhere in the distant future. This is wrong, the crappy code you write today will hurt you tomorrow!

As you work on a task doing an implementation that is crappy, you will touch code that has been created for another feature, and the feature you will be implementing tomorrow will touch the crappy code you wrote today. And this isn’t a agile weakness, I don’t care how much detailed up front design you’ve done. This will always be true.

So if you let the customer have his way, you’d better make it real clear that this will start to hurt the project from the moment it is implemented. And it will continue to hurt the project until it is fixed.

For the full article click here.

Update: Ferris has a common story of bad code that has a happier ending than most.

Categories
Development

DWR on the move

It’s moving both organisationally and in features. It is one of the first AJAX experiences I had, and it really does solve the Javascript to Java and back problems in a clean and easy way.

Shortly summed up it generates Javascript from your Java classes (that you configure it to expose) and lets you call them on the clientside. So a call to your AddressService.lookUp(id) would return a Address object with data populated. Pretty neat.

It will be exciting to see the new features scheduled too.

Check this post on InfoQ for some of the news, or go to it’s homepage here.