Datalog and reasoning about what we intended to put where …
Sometimes you are not trying to reason about software in general but about our software – the stuff we build – Project-X-vers-1.01a and Project-X-vers-1.02b-alpha – and not whether they work as intended or how they work – just trying to build them so that they have the components intended.
Why software configuration management should always require a major software investment is beyond me. Usually we are just trying to track bits of knowledge that do not readily link. Everything is ad hoc when you make a custom software change to a standard product which itself is evolving through versions and fixes and optional patches.
When the software is written in-house in a language which is not only able to access relational tables but which also has an available Prolog module – well, a little work and a lot of pain can go away.
Recently a commercial Smalltalk guru informed me that back-tracking in Prolog is over-kill so better just to live with the pain we have always known in dependencies among evolving modules. Wrong. What may be needed is just a well-understood subset of Prolog known as Datalog and a little initiative.
Much of the hard-core information about your software can be kept in rows in your usual database. The knowledge that keeps getting lost would require constant as-hoc tinkering with table layout. So we let that information accumulate in memos, mail and missing meeting notes. And conversations in hallways and doorways. “Don’t forget that we … ” correlates highly with something that risks being forgotten. Because it is usually not just one thing, but some inobvious or unusual or easily over-looked relation. Because it was ad hoc.
In these linked pages I will try to adumbrate the inobvious contribution to practical SCM that a little logic can make when you only use a restricted subset of logic programming.
Or you could go buy an expensive product and learn to configure it correctly …
