Design Philosophy: Believe in the Math and Physics, not in Mystique.

One question I always ask is this: Do you see a house as a large number of bricks or a small number of rooms? If the latter you can just bolt prefabricated modules together and job done! Well maybe. What if the doorways in the modules don't quite line up? You are either going to have an odd looking house or a lot of work to do - quite possibly a lot more than you would, had you chosen to build it with bricks. This is the classic system integration conundrum.

There is usually a choice between developing the functionality yourself or incorporating a package, and a complexity threshold beyond which the package wins. For me, that threshold tends to be on the high side. For example, if complex queries were potentially involved, like everyone else I'd feel safer with a standard RDBMS. But if I knew the possible set of queries would be limited and simple as they very often are, I would at least consider a regime of collection classes and files. Most don't even ask the question. Their motto is if you are storing data, use a database. And if there is a package out there that performs the function, don't re-invent the wheel. It is easy to see why. Packages usually have a good reputation and there are lots of people out there who can work on them. But not asking the question is blind faith and blind faith in anything including tried and tested packages, is never a good idea. Integration costs are very easy to underestimate and can spiral out of control. I have witnessed this many times! Sometimes it is even worse. The package is a poor choice to begin with. Either it is hopelessly inefficient or does not actually do what is required.

I am firmly in the brick camp. My instincts are to write systems end to end in C++ and if I am honest, I take this way too far! Be that as it may, I don't believe there is any real alternative to understanding and in some depth, what all the project components need to do and how they will do it. The package might well do what it says on the tin, but what else is it doing? I am a great believer in the principle of OCCAM's razor: Non sunt multiplicanda entia praeter necessitatem; Entities are not to be multiplied beyond necessity. If this principle is not applied there will be a price to pay somewhere. Unless the inner workings of packages are described in detail, the only way you can be sure the software is doing the necessary, the whole necessary and nothing but the necessary, is the brick approach.

That I take writing systems end to end in C++ too far, does at least mean you don't have to. And it means the HadronZoo download is pretty extensive and comes with no dependencies except Linux itself and the gcc compiler.

The Rules of the House

Ventures can do worse things than fall over due to a lack of money. They can all too easiliy turn into a Frankenstein's monster. So how will I keep the monster at bay? As far as I reasonably can, Iam going to stick to the rules. The math and physics and the application of OCCAM's razor. It is said that the customer is always right but with respect, they are not always right. Many want or think they want, bells and whistles they don't actually need. Most software suppliers see this as extra money and so smile sweetly and go along with every little whim and fancy. HadronZoo will push back on this because while the extra money might be nice, the extra hassle isn't. We can't shave with OCCAM if you don't. We will sell you the bells and whistles if you insist, but you are going to have to insist!

Thanks for listening. Enjoy HadronZoo!