“Can I change this code?” sounds like a normal question, but in my opinion it expresses a problem in agile development that needs addressing.

Foremost: This is a very good question, because it shows a noble intent: Make code you found better. Following the boyscout rule “always leave the campground cleaner than you found it” is among the best practices for coding. But the question indicates that there is something in the way of doing it. In Scrum you call this an impediment which calls for resolution, but also non-Scrum projects should take care of it. Also it should be said that solving this on a case by case basis doesn’t work. Effective development is only possible when this question is never asked again.

Here some reasons I found most common for asking the question and possible solutions:

• The code in question is not accessible, or politically tabu ⇒ Convince your teams that common code ownership brings benefit for everybody and is not about undermining special assignments of teams. Most developers will be very careful when touching others code, so the risk is neglectable.
• The code refactoring will break existing API ⇒ For many projects this problem is not as big as usually perceived. Usually the code is used internally only, and perhaps the new API will be much more pleasant to use. Even when this API is used externally, there is nothing wrong with changing API in a controlled manner.
• The developer is uncertain of her skills ⇒ Our industry demands for continuous learning and actually many developers like working on stuff that’s new for them. Its okay to feel unsure, but new ideas could make old code better. Let the developer pair program with the original author or one of the more experienced folks on the team. If everything fails there should be tests…
• Nonexistent tests make the change risky ⇒ Invest time in writing tests that check the current code behavior. If the change is intentionally changeing behavior, find out if thats okay, by talking to an architect, or by checking who uses the code you want to change.
• The actual usage of the code is unknown ⇒ try to get a big (architecture) picture and as much as code from this or dependent projects as possible. Create a big refactoring setup for developers to use in case of this kind of code changes. IDEs can find many possible usages of code and CI servers can also run on refactoring branches.
• There is no backup ⇒ Still running without version control? Do your homework and get one.

Changing code is good, because we all want to make it better or nicer. It helps keeping solutions clean and simple. If you are not going to change the cause (a bug, design flaw or whatever), people start to introduce workarounds, with is not nice, not clean, not simple and just a waste of bytes.

My call to developers is:
“Don’t be afraid of changing other peoples code with good intend.”

My call to project managers and SCRUM master is:
“Make changing others code a pleasant experience”

To answer the question in this postings title with a prevalent quote:
“Yes, you can!“

On Tuesday I attended Neal Fords session on DSLs and what they do for us. He showed that Java language capabilities for making or using DSLs are limited. But as we at codecentric have a lot Java, let’s have a deeper look to what extend it is possible. While some people already adopted the Builder pattern from Josh Bloch using a fluid interface, this has a problem, called the finishing problem. Because the Builder pattern works as chained method calls, some stuff might not be initialized when required. Neal showed an example, which he took from jMock, how to solve this problem in Java. This impressed me, so I came up with my own idea, which in fact is already done by some GWT or Swing developers.

My Java DSL Example

Session ormPitfalls = new Session() {{
	speaker("Mirko");
	attending("Fabian");
	attending("a lot of other people");
	at("Rheingoldhalle");
	at(new JaxDate() {{
		day2();
		session2();
	}});
}};

At the first glance this doesn’t look strange.. but… Whoa.. double curly braces?? The trick that is applied here, is that an anonymous class extending Session (and later JaxDate as well) is created. After the default constructor has run the initializer block runs. This initializer, written between that extra pair of curly braces, now contains method calls using the domain language of Session.

Is this useful?

Well, lets start that way: It has a problem. Each instance has its own class definition because they are anonymous classes. Which means slightly higher construction times, slightly higher memory usage and a different getClass().getName().

And I also think that we are not there yet: We don’t want business people to write production code in a Java DSL. Do we?

But…

… there is a great place for this: Testing! We all want to include business related people in testing, however they find it difficult to setup testcases due the amount of object bootstrapping required. But the above shown creation of that Session object is very easy to understand. Testers can use the domain methods, rather than, for example, fiddling around with creating multiple different Date Instances using the Java Calendar API. In fact this approach creates much better code than the old one. Currently the method being tested will calculate a date and the testcase will calculate it as well. But there is no proof that the testcase calculation is correct.
Using the above code will solve this, because date calculation is implemented only once, so it is less error prone and also easier to understand.

Side note on Calendar

While rating at the Calendar; How do you currently set a date to, lets say, noon tomorrow? Like this?

Calendar today = Calendar.getInstance();
today.setTime(calendar.getTime());
today.add(Calendar.DAY_OF_YEAR, 1);
today.set(Calendar.HOUR_OF_DAY, 12);
today.set(Calendar.MINUTE, 0);
today.set(Calendar.SECOND, 0);
today.set(Calendar.MILLISECOND, 0);

This does not only look ugly, but also has incorrect semantics. Better semantics would be:

Calendar calendar = GregorianCalendar.getInstance();
Calendar today = calendar.clone();
today.setTime(calendar.getTime());
Calendar tomorrow = today.clone();
tomorrow.add(Calendar.DAY_OF_YEAR, 1);
Calendar tomorrowNoon = tomorrow.clone();
tomorrowNoon.set(Calendar.HOUR_OF_DAY, 12);
tomorrowNoon.set(Calendar.MINUTE, 0);
tomorrowNoon.set(Calendar.SECOND, 0);
tomorrowNoon.set(Calendar.MILLISECOND, 0);

uhh.. well at least it tries to give all states in between a correct name. If this would be all in a method called tomorrowNoon() on our CustomCalendar/Date object this would be much better (it works only on “this.“) and this kind of ugly code is hidden from the user.

Conclusion

DSLs are worth looking at, but for many projects this is not the time already. However a pseudo DSL notation can be a powerful tool for testing and creating less error prone code, but short and speaking one. As the side note shows, creating methods with a domain meaning does help always, so just do it.

There is no English translation of this blog entry.

InnoDB has been the most popular MySQL Storage Engine as the MyISAM Engine was not usable for most use cases due to its limitations. MySQL AB was working on Falcon, the successor of InnoDB and MyISAM, for quite some time already.
After MySQL has been aquired by Sun and the Falcon chief architect left the team it didn’t look too good for MySQL already. But after the announcement of Oracle going to buy Sun everything is open again.
Personally I think its looking quite bad for MySQL, especially after InnoDB has been published as standalone database. Looking at the whole product portfolio of Oracle in the database segment now is very confusing. While it has been discussed the last days that “MySQL” could survive as “small Oracle” I think that the situation is much clearer now: There is nothing that is on the upside for MySQL. Many “MySQL” installations already run exclusively with InnoDB. It just fits better into the strategic portfolio of Oracle, making it the ideal small business solution. There is no need for MySQL to be the small brother of the big “real Oracle”.

But still doubts remain and we will have to sit and wait the future brings. But while sitting and waiting we can have a look at our existing installations and evaluate what requirements they fulfill and what features of MySQL we really use. Then we are prepared for whatever Oracle will decide.

Yesterday I attended the Agile Day on the JAX 2009 in Mainz. I do not want to rate the talks in any way. Since was one of the speakers, it just wouldn’t make much sense … … but I want to share a few personal impressions I had.

First I was surprised how many people attended the agile day. There were at least 300 persons, throughout the whole day. This showed me in a very impressive way that people are really interested in agility these days. In a short poll about half the people said they are using a few agile practices but they are not really agile. Most people of the other half said they are not doing any agility at all at the moment but they are interested in the topic. And just a few people stated they are doing real agile software development and most of them were speakers. For me that showed that there is still a long road to travel in the area of agility but many people started moving which is good.

The second interesting impression was a Pecha Kucha session. Stefan Roock organized that session. There were 6 speakers doing a presentation, each with exactly 20 slides, which are shown exactly 20 seconds each, 6 minutes and 40 seconds altogether. These are the rules of a Pecha Kucha presentation. For me it was really interesting to attend such a session. I have read about it before but I haven’t attended a Pecha Kucha session up to yesterday. I liked the short duration of the presentations. It urges the presenters to focus on one or maximum two ideas and keeps them from lengthily talking about dozens of things. On the other hand the strict format was quite distracting for me. Most of the time the slides were shown a bit too long or too short for the things the speakers had to say about the slide. So quite often they had either to wait or to hurry up. And I always was distracted somehow waiting for the next slide to show up. In summary it was an interesting experience for me but I don’t think that this very strict format is very helpful in most cases. I think short sessions – i.e. 10 minutes or less – are a good format but they shouldn’t be that strict.

The last interesting impression for me was the speaker panel at the end. It wasn’t the panel discussion in itself. Those I have seen many times. It was the fact that even the agile experts that stood there still had quite different viewpoints on the topic agility. I mean on the one hand that is quite normal for many topics but on the other hand it is always quite surprising to experience that live within a panel discussion. I think it shows that agility is still not a too well explored area that yet has a lot of evolution to go through.