Thomas Ferris Nicolaisen's blog

I started off this post with the title "Our Quest for Agility" but it kind of trailed off into being about our latest customer-dashboard tool. I'll do another post about our agile quest later. The Greenback project Before the summer, I was issued with the task of setting up a customer-management portfolio tool, which I named Greenback (as in, money , because that's what we want from our customers). The first goal was to provide our customer-managers with an overview of which customers exists, where they are installed, which applications they are running and other configuration details. Greenback is basically a web application with a big table with our customers and some filters to see the customers for a single manager, or with a particular configuration. Our customer-managers can also edit, add and comment all the entries, naturally. We have a rather large portfolio of customers (200+), and each of these are hosted with their own application of our software. Through

The last couple of weeks I've been spending a little effort on getting some code metrics up and running. I've blogged about measuring in software development before , and I think code is definitely one of the easiest and most important things to measure. The most important thing about metrics is that you monitor them . I am of the firm belief that if you run a static code-analysis report manually, it will give you very little. Your team will say "wow, we have 3000 FindBugs warnings", fix a couple of them, and then forget about it. Then the next time you run the report, you'll find new bugs that have crept in, with no idea of when or who did it. There are two ways to track these kind of metrics: IDE warnings Continuous integration reports IDE warnings Most of you have probably enabled the built-in warning system inside Eclipse (unused method, potential null-pointer, etc). Some of you strive to minimize these numbers of warnings, some of you have perhaps even turned

This post is a part of a tiny series I'm doing on why we use Maven, and you should too. Previous posts: Introduction: Why you should use Maven Reason 1: Get your libs-folder out of SVN Reason 2: Clean up your JAR-files Huge projects are hard to work with Many projects that have grown over time will become too large to easily work with. The workspace gets too many classes, the IDE slows down and the build takes too long. If the developers focus on separating the concerns of the classes into packages of functionality, these packages can be organized into modules. As the contract and concern of a module becomes more defined, its rate of change will fall to a lower frequency than the rest of the project. Once a module's activity has slowed down sufficiently, you can retire it into an external project, build a JAR-file from it and use this ready-built artifact as a classpath element for building and running the software instead. If changes occur later on, you can re-build the JAR-fi

Update: Added a summary section at the end of this post. This post is a part of a tiny series I'm doing on why we use Maven, and you should too. Previous posts: Introduction: Why you should use Maven Reason 1: Get your libs-folder out of SVN Some background Back a couple of months, I got the rewarding task of cleaning up our project's lib folder. You know the one: Crammed with JAR-files of various versions of the various dependencies your project has.. fizz-project \ fizz-core fizz-web fizz-libs \ junit.jar spring.jar common.jar lots and lots of others... ... Yup, good old fizz-libs . It needs to be regularly cleaned up to reduce software rot . Over time, the developers try out new open source libraries and remove the use of old ones, but they seldom take care to clean out the libs-folder, because they don't know if there could be any hidden effects from removing JAR files. Now, at our place we use Eclipse's . classpath file for specifying ea

This post is a part of a tiny series I'm doing on why we use Maven, and you should too. Previous posts: Introduction: Why you should use Maven The libs folder We have a libs-module in Subversion. When you check out the source code for our main product, this is one of the modules you get. It contains a hundred-and-some JAR-files. These are the dependencies for the sum of our modules: fizz-project \ fizz-core fizz-web fizz-libs \ junit.jar spring.jar common.jar Downloading all these MB's of JAR files is something you'll have to do no matter which build system you use, so bandwith cost isn't an argument. Subversion also uses binary diffs, so copying or changing a JAR file doesn't increase repository size significantly. The problem arises when you want more than one product. As soon as you want to split your product into two applications (or services), each project needs its own libs-folder : fizz-project \ fizz-core fizz-web fizz-libs \

Update: I'm doing some work to split this blog post into some more fine grained posts in a series. Please, bear with me if these changes are giving you lots of noise in your feed-reader. I used to work as a consultant. My job was to improve our clients' ways of software development. Among the most important things I tried to teach them were: o Good code style and object orientation o Practical use of good open source tools (don't re-invent the wheel) o Automating tests of their software, and continuous integration o Splitting code into modules, dependency-relationships and versions The last point is perhaps the trickiest. It's hard to understand why it's needed in an isolated project, it is hard to explain how it should be done, and most importantly, there is no de-facto way or standard for managing modules, their relationships, versions and scope . This is why me and my consultant buddies embraced Maven many years ago. After years of pushing and evangel

Update: Just fixed some outgoing links. After I began working at my new workplace, I've been gently pushing Agile here and there. We've been brainstorming how we can get agile working for our people, and so far we've adopted a few patterns and practices, but putting those plans into action has taken some time. Originally I hoped that things would go very quickly, but agile is about people, and people are hard to change. Getting better, always. We have a product that works really well, and pretty much all of the developers are happy. (Generally speaking, this state can be dangerous for a business. There is a danger of falling asleep, one day waking up to see that your competitors have gotten a good hold of your customers, with a better product and better marketing.) Having an environment that strives for improvement is a critical part of persisting success. And striving for improvement, well, that's what agile is. Luckily, our team of developers do a lot of activ

So! As I blogged about previously , I've begun working at a new company right after New Year's. I figured I'd get some thoughts out on how the first month has been. Usually, when someone begins in a new job they're excited, nervous and above all very humble towards the existing practices that exist in the new workplace. Of course, I had these feelings, but being an agile fanatic, I was pretty sure that I would be able to find some improvement points. Here are some of the specific steps I took during my first weeks. Step 0: Start writing a diary I don't think an honest worker was ever harmed by being transparent in his work. A practice I've been doing ever since I started working is The Diary . Basically, just a personal wiki-page where you note down a few lines each day on what you're working on. Apart from being a good way to keep focus throughout the day and being a nice place to paste notes and code, it sends out a message: that you're interested in

As I've hinted in some earlier blog-posts, I have now moved to Bonn, Germany, and as of last Monday, I'm working as a developer for IP Labs . This means I won't be a consultant anymore, as I have been for the last 2,5 years. I am now a "fast ansatt", or steady employee. It's a bit interesting to ask myself: Does this mean my rocketeer knowledge increasing career has come to an end? Will I go to work with a much more relaxed attitude, getting used to stable work environments and fewer changes? Will I spend less time overall doing stuff related to my profession? I hope the answer is to all three question a ringing 'no!'. I really enjoyed being a consultant because it allowed me to do stuff I'm really good at. I'm not a super-programmer, in fact I know lots of programmers who are better than me (well, even more that are worse than me), but I hope I still will be able to contribute lots to the company by doing what I always do: pushing for more agi