In The API Train Wreck Part-1, I discussed API design factors such as KPI, performance measurements, monitoring, runtime stats, and usage counters. In this posting,
Developing a commercial grade API wrapper around your application is not a trivial undertaking. In fact, in terms of effort, the development of an outbound
In the words of Ecclesiastes, there is a time and purpose for everything under heaven. In the early stages of a startup’s life cycle, process is negotiable. Too much process may hinder the speed in which you can build a functional POC. In later stages, however, good process and procedures (e.g. requirements, QA, unit testing, documentation, build automation, etc., ) are critical. They are the very foundations of any commercial grade product.
What you lack are not more lines of code, rather it’s architecture and a road. To substitute quality with speed, Is the motto of the code monkey creed….
Its not enough to capture and display errors. Real quality of service goes beyond just acknowledging your application’s faults. My rule of thumb is that there is no such thing as an “informative error message”. A good error is one that has been eliminated through error-handling code and product design.
I seized the opportunity to respond in kind with a rival French maxim. I quoted Voltaire: “Le mieux est l’ennemi du bien” (the best is the enemy of the good). My companion was startled and said he didn’t understand what I meant.
To those unfamiliar with the term, a death march is not a walk through Ezekiel’s valley of dry bones. Rather, it is a reference to a development project where requirements exceed the realistic deliverables by at least 50 percent.