Categories
Development

Learning to program

Tim O’Reilly has an interesting post on the O’Reilly Radar where he references some discussions they have had when it comes to learning, and in particular learning to program.

In essence it requires practice, and we need to work hard at it. There is however a bit of a paradox here. If you are going to practice that means doing the same thing over and over again with small variations to get good at it. I see in the discussions that it is often compared to learning maths, and I have no doubt that my utterly horrible math skills stems from the fact that I never took the time to sit down and practice. But the repetitions is difficult when it comes to software, as it is written to avoid doing repetitive tasks and we always learn that one of the basic principles of software development is DRY.

The way we usually work doesn’t really foster continuous repetition and learning either. When you are working in a project the solution is created and then you move on. The next time you get to try the same thing with a little twist from what you learned the last time around, is when the next project kicks off. With the worst projects around this means 2-3 years between each repetition. And according this definition of mastery you’re going to have a hard time reaching that:

According to Dizzy Gillespie, it takes ten years of practicing your butt off to achieve Mastery. His statement has been backed up by scientific research which shows that to reach a very high state of mastery, a task should be repeated about a million times, which takes about ten years. Better get busy! – (Sound the Trumpet, pp 67-68)

Related to practice is also another pet peeve of mine: We need to practice at it and use real OO. Usually we’re not good enough at using the power of our OO languages like encapsulation and separation of concerns. You can of course debate whether OO is the best way for developing software, but if you are using an OO language we need to get better at the basics. I believe that if we practice these basics more it will give us big returns in regards to quality and cost of systems. Way too many systems are built around POJOs acting as data carriers with all kinds of logic scattered all over the system.

So how and when to practice? Most companies should have structures for facilitating this during work hours, but ineveitably you will also need to spend some of your own time. One thing I like doing is participating in small projects. The smaller the project the sooner I get to move on and try a new angle on how to do systems development. Other ways may be to participate at a code dojo, or contribute to Open Source projects. I haven’t really tried a code dojo yet, but it sounds like a great idea. How would you practice?

The bottom line is that we can not read about something like programming and get good at it. Mastering software development requires practice and we need to focus on finding, using and creating spaces for practice.

Categories
Development

Norwegian government open sources travel expense project

The norwegian department of renewal and administration has released an open source solution for managing travel expenses (english translation). This is an interesting event and I hope and think that it is a practice that will be followed in the future.

No doubt, I think it is a terrifying experience for most developers to have to publicly publish their code in such a high profile project. And surely it didn’t take long before someone was picking it apart on Twitter, but that’s just part of learning. Quality review is now free, focus on that. 🙂

What is important now is that this is handled as a living product where feedback is included and others get to contribute. And you will need an active core of developers, so the people that did develop it needs to be kept on payroll for a good while to actively improve the product. Over time more developers will hopefully contribute, but in the beginning the core group is extremely important.

I can’t wait to see more projects like this. It will increase reuse and savings in the public sector, and it will put the code out there for everyone to see and contribute. In the case of consultants beeing hired to develop software for the public sector, they can no longer say that a project was successful because it delivered according to contract. They will also need to deliver quality. The code and system will be out there for everyone to scruitinize. Let’s hope more and more projects get open sourced like this.

Categories
Development

Quicker JUnit Spring context tests in Maven

This is probably fairly well known, but I couldn’t find any doc on it when I searched so I’ll put it up here.

First off: Don’t load your Spring Context in your tests unless you absolutely have to. Some integration tests should load it, but keep it to a minimum. Loading the context is expensive, especially if you load up Hibernate and maybe H2 in that context.

Avoid loading the context is important both for speed and design. I have seen way too many tests where the context is loaded just because someone don’t want to do mocking. Besides, if you have to do a lot of mocking your design is usually too coupled, and should be changed.

So how can you speed up your tests in Maven?

Spring will cache the context and make sure it is only loaded once. But due to details I have not studied; in Maven, this only works for the tests that are in the same suite. It should work with fork=once on the surefire-plugin, but for some reason we need the suites too. Test which one works for you.

Drawbacks? If there is state in your context (database, stateful services) you will have created a dependency between your tests. That’s why, when it comes to database-testing you should use the AbstractTransactionalSpringContextTests which will automatically roll back your changes at the end of your tests. If state is modified in a way that has nothing to do with your database use setDirty() to signal to Spring that the context should be recreated for the next test. Of course then you get the time penalty of recreation.