Programming is based on certainty. You can only write code if the layers that connect together do so without any holes in the logic. When you discover a method by which an infrastructure should produce a bunch of objects you do not need to be concerned that the infrastructure gets it wrong, that is why it is infrastructure.
When the infrastructure does not respond in the most wholesome way, crashes the server memory or simply seems to fails inexplicably and you have checked things, your confidence in the infrastructure may be shaken, but if, for example, the infrastructure delivers a set of objects cleanly, and also provides a method that sets a filter for that selection in the infrastructure but that filter method crashes badly, there are two approaches:
a) develop a work around that applies the filter at the higher (application) level
or
b) rewrite the infrastructure to do what is required without crashing
Always, always aim to do b), unless you do not have enough time, in which case always do a). Or of you are developing against a "code freeze" version, then never do b). The infrastructure could be incomplete and you can not reach your deadline.
Good software, infallible software is written in layers each of which can be separately monitored. If the infrastructure is broken, then a software team with a good architect will know what is going wrong and may rewrite the infrastructure.
The worst thing to do is to rewrite infrastructure incorrectly and allow untested bugs into the system. And if you are using a "version frozen" open source module, you may be in for a quagmire.
Suddenly you have 10 days work being added to the schedule already agreed, and there is no way
to do that. So, you do option a). The software gets delivered and it is slightly less efficient but it only affects the instance of the decision tree that it affects.
Now, you can upgrade the infrastructure, it will still work, but you can replace your workaround and test it on a staging site before you release it.
No comments:
Post a Comment