The process is driven by a long list of new features – this is how it always starts – but the overall design goal is “better and more simple”. This goal is of course extremely difficult to achieve. Combining a lot of new features with the extensive list of ones already in the software – while making the overall experience better and easier takes a lot of hard work.

One place where we have done an effort is on concept list. We have come a very long way with our demo of the new version – but the new features introduced some new concepts – like “formulas”, “policies” and “calculated columns”. These concepts – or what they represent – is needed in the software – but having a complete list of words and lingo to learn when starting to use our software made for a very steep learning curve. Especially considering the fact that two of the three new concepts was totally hidden in like 80 % of the program – which is bound to make users forget they even exist!

So – we’ve done the only thing we found really worked – we reduced the number of concepts the user has to juggle! From three to – one! “new column” – it is very easy to understand – the user can do exactly the same thing as before – and the code only needed a little tweaking to make everything with one concept. Not to mention the UI – which simply needed to be reduced to work the new way!

Hopefully our users will feel the simplicity when the program hits the streets!

Even the smallest amount of programming I do go in my repository, and I wouldn’t want it any other way – the luxury of being able to roll back and forth, branching, merging and suddenly sharing with other developers if the need arise is very nice!

One of the main issues though – especially when working in a team – is how often and how much to commit. During the past few years I’ve realized a few key points:

• You can never commit too often! (Given that:)
• You should never commit code that doesn’t compile!

Following these points is easy, important and gives you very high flexibility. I bend the  second rule a bit, and add the following:

• Branches are for experiments and long hard deviations, and
• Only trunk needs to be compileable at all times

This comes from the (well known) trunk/branches/tags-model which we established when we started using Subversion. We reserve trunk for the place from where we can always release a new version. Code in here should always be compile-ready – no exceptions to this rule at all!

Our branches are used for experimental development, new versions etc. and the compile-issues in here shouldn’t be to the annoyance of the other developers but generally no more than one day’s work should go in each commit (see the first rule)!

Needless to say I follow these rules very precisely all other projects, even the ones where I’m alone and working at night.

After reading this post my mind spent 5 seconds looping through all the data it has passively consumes over the last year – about formats and stuff. It was hard! For those of you who have seen the movie Butterfly Effect – I image it was like those loop backs…

Well… These days I do a large amount of programming and interaction with the Microsoft Office formats. This means that I do a LOT of COM interfacing from my C# code – and I generally hate it!

The only thing on my mind right now is the possibility of doing XML-only based input/output. And if I am lucky – I can add Open Office support in that process!