+972 52-548-6969
Trading safety for simplicity
I many situations, I see people trying to look for technical solutions in order to prevent bugs. Typical example are "how do I prevent users of my API to do XYZ" or "how do I force developers to always do things in a certain order" or "how do I validate [complex state] at every point".
The intent is good, but the problem is that the issues that is trying to be solved is usually big and complex. The solution, as well, going to be complex. Moreover, the solution is likely to be fragile. At any event, it is going to be costly.
Those are admirable goals, but I don't like this approach at all. The issue from my point of view is that I would much rather have a bug in my code than introduce this complexity into the code base. Bugs can be fixed, but it is hard to reduce complexity.
Comments
One of our goals with developing apis is to try to ensure that errors happen at compile time vs runtime.. I think this is the exact thing that can go way to far and make an api really ott.. we basically cut the code base of one of our 'incubation' projects in half when we went to release it.. whilst making it more flexible as well.
All 'bugs' are not equal. If a high level of [runtime] validation complexity is required to prevent a 'bug', then I would say a side-by-side evaluation and prioritization of any such known 'bugs' would be in order before addressing them. Such an evaluation should be based on the cost of likely downstream consequences. Those costs should dictate which 'bugs' are tackled and which are not.
I would also say Stephen is pretty much on target and if there were very many high-cost API 'bugs' were appearing I would want to review the architecture, design, and implementation of the API - something is probably fundamentally amiss. Either that or you've wandered into a complex and expensive problem space.
I can answer all of those questions at the same time: Train your team appropriately.
seriously - if you have to ask these questions, you have serious trust issues in your team. train them or move them somewhere else.
Comment preview