an aggressive QA tool
I woke up this morning figuring out how to build a modern QA tool.
It is not like any other QA tool I have seen. It combines a handful of modern software development technologies that are not usually combined.
It does not fit any pattern I have seen before. It combines technologies that are common but not part of the same discipline. I am not sure if it is unique, but it certainly is original.
It was a very static technology when I was first waking up to the idea. Within 10 minutes I had worked out a way to maybe make it very dynamic, almost interactive. It is designed to thrash out serious bugs very quickly. Like I said, it is very aggressive.
I have a very specific use case in mind. I think it can be generalized, though. The primary target is existing code. However, at this moment, I am trying to think if it can be used for TDD (test-driven design). Preventing bugs from having any lifetime at all in new code would be very useful.
I am just letting it play out in my mind now. I am feeling unusually intuitive/creative this morning. I am not planning to code this bad boy today because I have a lot of other stuff I want to get done. When I do program it, I think it is going to be a lot of fun.
I think it will be almost fun to use too. It will certainly make it a lot easier to do something that is insanely tedious and clearly not efficient or decisively productive now.
Certain types of bugs have been creeping into software for ages. Right now, there are likely a lot of these creepy bugs lurking in vital infrastructure and on ordinary people's desks. Stuff almost everyone uses every day, and almost no one ever thinks could be a problem despite a well documented history to the contrary.
Such an inurement bothers me because it fosters fecund problems that fester and fan out, frequently infusing facilities with faults. The faults have potential energy (PE) that ultimately reaches a trigger point and latches up hard - breaking whatever it grasps, until equilibrium is reestablished.
As I was wrapping this post up, my subconscious dredged up a word have never used and barely ever heard before: "epistemology". It turns out, that is a good word; a very useful one.
After I have the toolset created and as I am getting ready to put it into use, I think I will consult with that word a bit more. It will probably allow me to imbue it with a lot abilities. It can certainly have some influence on the architecture.
A guy who seemed pretty wise to me once said on the radio, words to the effect: "We must stop being gatherers. We must become hunters." He was so right. Some problems need to be targeted right at their roots, boxed in, and eliminated
That is hunting. That is not sitting back and collecting. When one type of low-hanging fruit is exhausted, you have to change the game and convert something else to low-hanging fruit. To change the target and still be effective, you have to change the approach. That is the core principle he was getting at, I am sure.
The domains of this radio show guest's problem and mine are kind of orthogonal to each other. That is not to say that one does not know about the other, unfortunately.
That kind of bugs me. I would like to disarm one problem of the other because right now it is too damned well armed. And then the potential energy in the system can go back down to stable levels. It is not at its resting level now. It is at its triggering state. In fact, it is constantly triggering.
Look up the mechanism whereby a nerve impulse causes a muscle to contract and what kind of change has to occur to get that muscle to relax again, and you will see how it resonates with the current status of Windows security. In this case, intrinsic flaws have created an emergent environment that is in effect the clenched muscle.
The current praxis of trying to protect Windows and other programmed systems does not deal with this situation because it tries to model itself after ill-fitting military base-guarding techniques: perimeter defenses, passwords, encryption, etc.
All are useful techniques but none solve the core problem: the central flaws in the thing being protected - buggy software. Bugs gotta go!
The bugs are not just creating an opportunity for attacks: they are responsible for the rapid evolution and growth of the attackers. You can winnow the population size of the attackers, or strive to do that anyway. However, you cannot devolve them. Evolution is mostly a one way street. Population control has no effect on how inimical individual members of a species are. Nor does population control prevent future population growth. Bugs gotta go!
posted by John Collins | 10:04 AM
