Tag: Java

Categories
Development

Database migrations

I was originally looking for a way to organize our db-scripts so we could do a full drop and recreate before running tests, or deploying a new version. One of the main disadvantages to this is that test data will get lost. By separating the scripts you can still maintain upgrade scripts for when you are going live with a new version.

But since we have many interested parties, asking them to drop all their carefully crafted test data is not an option. That’s when I stumbled across DBDeploy. It is beeing developed by a bunch of Thoughtworks guys, and it supports upgrade/downgrade in small increments. It seems alright, though it’s doesn’t seem to be under active development. Last svn activity was in october last year, but I guess some simple things actually get done. 😉 I’ll report back when we get some experience with it.

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.