Oh boy, I feel sorry for developers in the norwegian banking industry these days

Yesterday, one of the big banks in Norway basically had to shut down most of its services due to a worm (viking.gt) infecting more than 10000 Windows PC’s running in nearly 200 branch offices (see article in norwegian). OK, I know I am wierd but my first thought was “oh boy, I am glad I am not a developer working for one of the traditional norwegian banks right now”. Why? Because I think I know exactly what is going to happen, seen from a developers point of view.

The banks will immediately impose strict restrictions on how people use their machines; developers will loose sysdmin rights on their computer, internet filters will be tightened to make sure that only “serious” sites can be reached, downloading stuff from internet will be banned, and email with binary content will be silently thrown away by the mail system, and much more. It is a bit like, after a nasty accident, you take away all the sharp tools from your carpenters and still expect them to be productive and enjoying their work. Then after weeks and months of struggling, the restrictions are lifted or relaxed one by one, the developers have to beg and fight for each improvement, like explaining to perhaps six levels of management, both verbally and in written text, why, say, having read access to slashdot.org is important, and why they need to have svn access to external repositories. They might have to explain to another group of nutheads why they need sysadmin rights for installing Ethereal or basically all other useful developer tools. It might take several months (or never) to restore an environment where efficient software development can happen. Until next time a virus or another security story hits the headlines in the news…

I did work in the banking industry for a couple of years, and the scenario described above happened over and over again. Why? Because our production servers, the administrative machines and the developer machines were all on the same LAN! Believe it or not. I suspect that this is quite common in other banks as well. This means that if you control the machine of a developer, then you have more or less free network access to the productions servers and to the workstations used by the people to manage this servers. With such a network configuration we had to find a compromise between the security, reliability and usability requirements for all these different environments (production, administration, development) at the same time. The result was of course suboptimal for everyone.

The solution, I belive, is to make sure that you separate the corporate network into several completely separated networks, where secure double locked VPN/SSH tunnels and/or remote desktop solutions is the only way to access machines on one network from another network. But first of all, make sure that the developer network has no possible network path into the administrative or the production network. You could even consider a setup where different development groups are on separate LANs, perhaps with ssh access between the LANs and a common shared software repository. First of all this will be a much more secure setup, but perhaps even more important (seen from a developers view) this will also be a productive environment to work in. With such a setup a developer will not be locked down by all the security and reliability issues that the production and administrative network needs to care about. As developers, we do actually care about security and reliability, but at the same time we really, really need all the sharp tools that we can find to be productive and enjoy what we are doing…

Oslo XP Meetup: Lighting Talks

Yesterday I attended the Oslo XP Meetup. More than 20 people gathered at Scuba bar to watch a series of lightning talks – that is, maximum 10 minutes. There were seven sessions of very high quality – I really enjoyed all the presentations. Here is a quick summary of each presentation as I remember them:

Marius opened the evening with a talk about JavaScript. He claimed that it is probably the most important language around. It is used everywhere, and is currently driving the direction of how the web evolves. Maybe he has a point? Although it is hard do love a language which usually looks so ugly, he did point out several tricks to improve the quality of your javascript code.

Thomas talked about use cases and how they tend to grow into a massive pile of hard to maintain information. As an alternative he reported success from a project using Selenium to record scenarios and thereby reducing the need for some of the details in use cases. Thomas has also written a blog article about this subject.

Dagfinn, one of the authors of the PHP in Action book, presented some interesting ideas around Fake services. How to test an application without having to also run all the services that the application depends on. Is it high level mock objects we are talking about?

After the break, I did a 10 minutes presentation of TDD in CPP which is basically just Uncle Bob’s Bowling Game Kata converted to C++ and QUnit.

Trond had some amusing observations about the absurd mathematics behind the so-called risk matrix. Trying to categorize risks a matrix by estimating probability vs consequence gives some strange results if you try to actually do the maths. The basic idea is that you will see that the degree of probability does not really matter much in the end. A high consequence risk will always be red, while a low consequence risk will always be green.

Aslak presented some best practices about building software in agile projects. He called them “Build Patterns”, and it was about the need for having both a fast and slow build process, how to use a flag to focus the project team on a broken build, the need for a common check-in procedure for the developers.

Finally, Kjetil talked about three trends in the agile world. Even the Norwegian government is now asking for agile developers and projects, techniques from different methodologies are mixed together as they now can stand for themselves, and the word Agile is about to loose its meaning. The presentation triggered a few interesting discussions afterwards.

My first sourceforge.net project

I just created my first project on sourceforge.net, namely QUnit. To create a new project you have to fill in a form with some info. After a couple of days your application might be accepted, and then you get ssh access and full control over your project site. Default setup is to use CVS, but using the admin interface it is easy to switch over to SVN and seconds later you can just check in your code. I am quite impressed by the system. It does really work, and the system makes me feel welcome.

Using sourceforge.net I wonder how it would be to work in a company where all software development was based on developing software by managing projects the sourceforge way instead of having a massive shared repository. There must be plenty of pros and cons, but I think it could work quite nicely.

QUnit – a simple unit test framework for C++

I am a big fan of unit testing, mainly because I see that it has a very positive effect on the analysis and design process. You program by intention, telling the computer what it should do rather than how to do it. I really enjoy working with JUnit when doing Java, but I have not found any good frameworks for unit testing in C or C++. I tend to implement my own mini-framework over and over again. It is now a kind of idiom that I keep in my C/C++ toolbox, just like I used to have an Enum idiom for Java.

So what is the problem with the current JUnit wanna-be frameworks out there? All the C and C++ frameworks that I have seen so far are bloated. Someone recently pointed me in the direction of a paper called “The Simples Automated Unit Test Framework That Could Possibly Work” by Chuck Allison. I skimmed through the article (not really bothering to read the text) to look for the actual code and realized immediately that it was just another bloated unit test framework for C++. The title kind of provoked me, but also inspired me to publish my small unit test idiom.

I have chosen to call it QUnit. It is under 100 lines of code. It integrates nicely into your development environment, and there are no bells and whistles. The framework is at sourceforge.

To see more about how to use it you should take a look at some slides from a presentation that I gave for some of my colleagues two weeks ago. The talk was about how test-driven development drives the design process. It presents my simple unit test framework/idiom and show how Uncle Bob’s Bowling Game Kata can be implemented in C++ using QUnit.

Why not?

OK, it is probably time for me to start writing a public web log as well. I am sure it will not be a high volume blog, but it might be a good place to post some words about things that I am currently involved in. So let us see what happens…