Its really a rant about configuration management but Word documents are a part of the problem…(this isn’t directly related to where I’m working right now, its something thats been running around in my head for a while – they suffer from it though)
I’ve seen so many things that are not the answer, what is the answer?
To know what the answer is you need to know what the problem is. The background is simple, there are groups of software engineers working a bunch of projects, some of these projects act as sources of code, some as sinks and some as both. Each of these groups may potentially be working on a number of parallel projects utilising the same code. Each of these projects will deliver a bunch of features, which may or may not be independent.
Now the observed problem – the capture and tracking of requirements. This is one of the big problems in computer engineering. There are a number of solutions I’ve seen to this, none of which have been successful.
The worst solution I’ve seen was to pretend that wasn’t something we needed to care about and just make some code anyway. This didn’t work at all, I hope this company is now bankrupt and not still peddling its ‘solutions’.
Some others that I’ve seen, in no particular order are:
– Use an over-elaborate Lotus Notes database that noone could understand
– Use Word & Excel documents in a big directory structure
– Use physical cards to write things down (the XP solution)
– Get everyone sat together around a whiteboard to talk about what they want (only works when everyone will fit around a whiteboard)
– Provide a prototype and ask whats wrong with it
Each of these worked to an extent, but they could all be improved.
Probably the closest to working for a large scale system was the Notes database controlling versions of a set of Word documents, but that was unsatisfactory in many ways. Searchability was one of the major problems. Another one I’d like to explore some more is the XP way of doing things – I don’t like the cards, they’re not searchable or backupable – but theres no need for it to be done with physical cards, it could be automated.
So all of this got me thinking. Would it be possible to extend the extreme programming paradigm to the point where you dissociate code from files? The vision I have works like this:
Requirements get split up into tasks (XP cards or CMSynergy tasks) by some process outside the scope of this discussion (though it should be easy to enter them in a group meeting, like XP requirements discussions), but the tasks are stored in ‘the system’.
Tasks have some code associated with them, either they generate some new code or they alter existing code (or more likely both).
There is some concept of dependency between tasks, but this shouldn’t be too strong.
Source projects then produce work based on their tasks.
Sink projects can choose the tasks included in (or required by) their project on a nearly adhoc basis (this is again something that Synergy can do).
Nothing interesting so far….
Each task has a set of tests associated with it.
The developers IDE has a mechanism which spots idle time (no input for, say, 15 seconds) and takes a snapshot to queue for building and testing locally. If he has another idle time before the build test results come in the snapshot in the queue is replaced with the later one.
There is an integration build and test system running for all platforms and configurations constantly, recording ‘good’ versions and notifying failures.
The IDE also has integration with the CM system to the point where the CM system records every keystroke. (This sounds a bit anal…)
Given that every change is recorded the system can identify hotspots in the code, where there is a lot of activity.
The editor would be able to highlight code in a number of ways, its ‘hotness’ (how much it has changed recently), the amount of thought that has gone into it, its relationship with test failures, and others.
4 comments