Version numbering: solutions to questions remaining

A while ago I posted an entry about version numbering and ended it with two questions:

1. When is backward compatibility broken? This probably looks like a stupid question, but imagine: A DLL named “SomeFunctionality.dll” uses some other DLL’s, named “Other.dll” and “MoreOther.dll”. But then this ”SomeFunctionality.dll” is changed and doesn’t use “Other.dll” anymore, but uses “Another.dll”. However, the interface of “SomeFunctionality.dll” didn’t change. Is backward compatibility broken or not?
2. What about customer related changes to old software which breaks backward compatibility? Say for example you have version 1.1.0.1 at a customer site. Meanwhile version 2.x.y.z has already been released. Now the customer with version 1.1.0.1 wants some new feature which breaks backward compatibility. However, major version 2 is already taken. What major version do you use?

After some thought I will present you today with possible solutions.

Building a Development Environment Part 1: Managing your sourcecode with Subversion

This first installment in a series of posts about building a development environment is about repository lay-out and getting the code out of your source control system.

I originaly was planning on writing a series of articles about how we implemented continuous integration (CI). However, while experimenting and searching the internet for information, I quickly came to the conclusion that this whole CI thing was just to narrow in scope. There is a lot of information and a lot of blogs discussing CI, but most of them are people starting to write a simple application and them being the only one working on it. So, no projects made of multiple subprojects, no projects shared by other projects, no developer interaction, etc…

But in a real company you do have several developers, you do enable reuse and thus use a project in multiple other projects, you do have organisational standards (how projects must be setup, where code must be commited in the source code repository, etc…) that must be applied, etc… Some of this interacts with CI and this is way I made the scope of the series bigger:

How Do I Build An Environment To Develop Software?

Disclaimer

This post is by no means “The Way” of building a development environment. In fact, you will notice that at times I deviate from some of the practices advocated by the referred articles at the end of my articles. It’s our interpretation of the process and how we implement it. If you have any remarks or suggestions for improvement, please post a comment.

Software Design Specification and Software Module Specification

Introduction:

It’s probably completely out of fashion to write software design specifications in an agile world, but we are still doing it. And I believe it is a good thing. Of course, there will be exceptions and the culture of the software shop should also be taken into account, but as you don’t go on holiday without planning your route, I don’t think you should start coding without thinking on how you are going to implement your application.

Peer Code Reviewing

The Artima Developer Community has an interesting article on code reviews. Go check it out…

Software Factories: the industrial revolution all over again?

TheServerside.net has an interesting post about software factories.

Apparently someone is afraid that automation will lead to “dumb-ification”:

While that’s a great theory, what ends up happening is developers get plugged into an assembly line and are treated like battery chickens expected to squeeze our code. In our increasingly diversified platform and architecture world the software factory is as outdated as Henry Ford’s Model T assembly line, where you could have any color as long as it was black.

And then there is this other guy who believes it is an opportunity:

It explains how, by providing a simple but effective architectural framework for organizing a project, called a schema, Software Factories help their developers define better metrics, and how, by providing a framework for harvesting and reusing experience, Software Factories help their developers use metrics more effectively to improve future projects.

I’m with the last one. Software factories are an opportunity.

I can’t believe anyone still thinks we want to treat people as mindless tools. This is 2006, not 1906. And even if anyone would like to, people will not let him.

The Practical Traveller

The holidays are back again, and everyone is preparing for their holiday trip. Our European roads are stuffed with cars filled with people and their luggage. They all share a common goal:

“Get there co-travellers as fast and comfortable possible to their destination”

There are of course different ways for drivers to prepare for the trip.

Implementing a Source Code Standard: a necesity

You will have noticed that we are really getting into managing and controling our software process at my daytime job. In this description of our progress I will talk to you about implementing code standards.

Implementing Peer Code Reviewing

At my daytime job we are in the process of implementing a peer code reviewing process. These are the sites I used as guidelines and the process we ended up using. Of course, as always the process will need evaluation and tweaking.