Tag: refactoring

Categories
Development

The cost and benefits of cleaning up code

I’m not a very scientific person. Actually I’m probably quite un-academic in my approach towards software development. There are a lot of stuff I consider essential that havn’t really been proven, but I won’t stop doing it just because of that. It might be a weakness, but this field is also way too complex for us to wait for stuff to be proven scientifically before we do it. Yeah. People are complex. 😉  It is however very nice when people smarter than me can prove stuff, especially when it matches my own world view. 😉

Even though it is not very scientifically conclusive Joakim Karlsson has some very interesting results on the locality of code changes.

EDIT: The original article is gone after all this time. Here is a link for the internet archive: https://web.archive.org/web/20101227161814/http://jkarlsson.com/blog/2009/06/24/the-locality-of-code-changes/

As Joakim discusses this relates closely to how you evaluate whether the code you are currently looking at is worth a cleanup. It’s very hard to do a good evaluation of this, especially since we always seem to underestimate the time to, and frequency, of when we will be re-visiting that code.

On my own gut feeling I have started to do a lot more fixes when I stumble upon them, exactly because I have done this error so incredibly many times: I have tried to be cautious, and avoid doing unnecessary work by cleaning up stuff that I’ll “touch just this once”. But by touching it you introduce new bugs, change old behaviour and learn something new. All of this feeds back into the code, and you will most likely be debugging or making more changes to that code within the near future. It’s nice to see a more structured approach to investigating this.

There are some good suggestions and even references in the comments of the article. It’ll be interesting to see any refined results on this.

Categories
Development

Redesign is not going to save you

This was really a ReTweet from Johannes, but my mind started working and it got sort of out of hand for a tweet. 😉 Both his comment and link was excellent:

Software tends towards more technical debt. Without the discipline to reverse this, we won’t succeed in a rewrite either. – Johannes Brodwall

The article that he linked to is the “The Big Redesign In The Sky” from Uncle Bob. If you understand Norwegian also check out Karianne Berg’s really good lightning talk on the subject.

I myself really have to fight the urge to start over on a green field application. I know it takes too much time, and the result will be much worse than what I hope for when I start out. But what it really comes down to is wether you have the mechanisms in place that lets you incrementally improve your application. Without confidence in the changes made developers will avoid doing them, and your application will continue to rot. So what can you do to encourage changes? Some of my personal favourites:

  • Unit tests
  • Functional tests
  • Web tests
  • Database tests and migrations

All of these can also resist change if done badly, but you need to start somewhere. It’s really hard, but finding a path for incremental improvement is the best way.

Categories
Development

Agile databases

Ferris sent me a message a little while back and asked if I had any input on handling databases, so it gave me a reason to sit down and try to write something about my experiences. I’m not too happy about the flow of these articles, but I figured it was better to get something out there. Just let me know if something should be changed. Here we go…

Changes?

I see a lot of different approaches when it comes to handling databases. Sadly most of them are on an ad-hoc basis, and something that should be something of the past. With the introduction of agile, focus has been shifted from preventing change to embracing change. And we’re pretty pretty happy to change the code and do refactorings, but when a change affects our database we tend to think it’s quite scary. We need to find ways to do this better, and it is possible.

By implementing the practices mentioned below the projects I have been in are able to perform upgrades to our different environments (testing, pre-production and production) in a consistent way quickly. And I am fairly confident that the scripts have been thoroughly tested and that the chances for human error is drastically reduced. We can create new environments for testing with a new customer in minutes and fill the environment with test data. Because of this we can focus our time and effort on developing new features instead of wasting time on upgrades and errors that can be avoided.

Most of this is based on the Evolutionary Database Design from Martin Fowler and Datbase Refactorings by Scott Ambler.

I will try to describe more details with separate articles, but for now check out the migrations in Java which is the essence of what I think is necessary.

Your database is code!

If you don’t have schema specifications, triggers,  test data etc. checked into version control. You need to start doing it right now. When you tag, release or branch your “normal” source code you do the same with your database scripts. For Java developers using Maven I would recommend keeping it as a sub project in your maven project structure. That will make handling of tags/releases automatic.

Make it easy

Even though SQL, PL/SQL or whatever your poison is looks quite strange and awkward to many developers, you can script the things you need to do. For Oracle, sqlplus actually works for some basic scripting. If you don’t know how to; learn it.

These are the tools/scripts I think every developer should have as a minimum:

Making these things easy isn’t just because your developers do it all the time. It is also because having these tools will enable them to do it when it’s needed. There are a lot of good things in every project that simply is not done because it is too difficult or takes too much time. At least let us give the developers the tools we can, and remove that kind of mental blocks.

One of the most important parts of this is the migrations. Next: Migrations for Java.