

How do you handle configuration control? - mironathetin

I know, this is one of the unpleasant topics of software development. Probably this is also a non-topic for small startups.<p>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?<p>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.<p>Time to leave the company.<p>Or? Anyone with a great solution? 
How do you handle this problem?
======
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.

------
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.

