HN Explorer

How do you handle configuration control?

3 points by mironathetin ↗ HN
I know, this is one of the unpleasant topics of software development. Probably this is also a non-topic for small startups.

But sooner or later it catches all of us: too many developers, probably external, everyone implements what he/she likes best and interfaces break far too often. A way back to a stable development is configuration control. Is this the only way?

Usually the configuration control board meetings are more or less boring. Once the project is large enough, the representatives do not know enough details to make educated decisions. Nevertheless, some people like to hear themselves talk and thus meetings become endless. If topics have to be re-discussed next time, a decision wether to change the software or not may take very long. So development slows down. Finally some developers don't care and go on with cowboy development etc.

Time to leave the company.

Or? Anyone with a great solution? How do you handle this problem?

8 comments

[ 4.6 ms ] story [ 42.4 ms ] thread
swombat
Are you referring to source code control? I've never really heard of Configuration Control outside of the realms of 3rd party software implementations (e.g. "Implement SAP at company X"), where it refers to, basically, source control for the app configuration.
mironathetin
I mean control of the development cycle.

We use a web based software to report errors and software change requests. The control board should decide priorities and whether new features should be implemented or not. This requires a lot of know how about existing features, about the direction the software should go and if there will be clashes.

A big problem is, that discussions take a long time. Another problem is, that some developers don't care and simply decide themselves. This sometimes creates instabilities in the software and not wanted features.

hapless
That sounds like a pretty fundamental business problem: developers are acting alone without direction from supervisors?
mironathetin
swombat, hapless,

you both hit the nail :o). Our management disappears and/or does not care about software. We got a young guy with little experience, who has to run the software configuration control business and he gets rather frustrated.

So we developer are somehow self-organizing. This is a problem in some cases, but it is also terrific in others.

That is the reason why I asked. How do you do it? Your managers don't shut the door and do it for you. They need developers expertise, right?

Oh, yes. You may wonder how this can survive? We develop for a scientific project. So our managers are scientists (like the developers). Although we have some very smart developers in the project, management is not among the talents of most scientists.

mironathetin
"developers are acting alone without direction from supervisors?"

Yes, indeed. We have a developer in China who maintains an important package. He tends to implement as he likes. His local supervisor was just like this, as long as he was developing himself.

swombat
Doesn't sound like you need any configuration control tools - or any other tools for that matter.

What you need is a project manager.

hapless
Internally developed applications can reach this level of complexity very easily.

Unit testing in development isn't enough.

At some point one also has to be able to do quality assurance and integration testing. In order to adequately unit test your source code, you'll need source control to verify how your source code differs from other copies.

In order to adequately do QA and integration, you need configuration control in order to adequately understand how your installed copy is configured differently from others.

nradov
Establish a customer / supplier relationship between teams that build libraries and those that consume those libraries to build applications. Treat the libraries as separate internal products with a defined release schedule and version numbers. Require any library API changes which could break backward compatibility be delivered in a release with a new major version number, along with documentation.

It also helps to organize your source code repository so that every developer can check out all the code across your entire organization. Then when a library developer refactors something she can immediately see if any dependent code will no longer build or fails unit tests. Google does this, at least for the majority of their Java code. I saw a presentation from the Google Collections developers and they explained that working that way made it fairly easy to revise their API.