Insertion-sort applied to software quality

We have written unit tests for half a decade now. These functional guards are patiently watching for any irregularities in functional behaviour during a project's life. They keep the castle in pristine order so everyone lived happily ever after.

That is, until the day, the big bad wolverine shaped maintainers decided to change some walls. They kept doing this again and again. Over time, the castle did not at all look like the pristine castle it once was architected to be. Wolverine maintainers had more interest in just adding a new room than rebuilding the entire castle.

Dark clouds and shadows now assembled outside the gates and not all guards were at their posts. Some of the guards had grown old and had ended their service long ago. With low guard morale and an uproar approaching, the King and Queen decided to abandon the castle and move into another one build on a platform far far away.

So ends many an adventure, even today.

What if some building regulations were given to the maintainers? What if every room added had their own guards, with powers to stop the big bad wolverine maintainers from doing longterm evil deeds albeit with shortsighted good intentions? What if the maintainers would add their new room designs using forms already existing in the solution?

This adventure is not finished.  More thinking it needs to be completed.

I fear we are repeating history here.  Were not these powers already present in an early MUD where each user could program their own extensions to the universe?  I suspect this was LPMud with the LPC language, but I may be wrong.

Kommentarer

Populære innlegg fra denne bloggen

5 generations of computer languages

DOJO kamptyper [forbedre egen kompetanse]

Generations of text formats