When developing a rapid prototype it can make sense to put the emphasis on the 'happy path' and not consider things like exception handling, edge cases and failure. Perhaps, once the prototype phase of the project is over the code will be thrown out or it will be refactored to deal with the real world.
In a production system we simply don't have luxury to only consider the happy path. The more production system I have worked on the more types of failure I have being exposed to - some of it very painful. As my hair went greyer from these experiences, I couldn't help thinking more and more about how to make failure less painful. Who wants their pager going off for some silly reason? Nobody. If dealing with production code, we simply must think about how best to deal with various forms of failure.
In this presentation I consider two engineering techniques that I think should always be on the architectural radar:
* Fail fast
* Fail safe
In a production system we simply don't have luxury to only consider the happy path. The more production system I have worked on the more types of failure I have being exposed to - some of it very painful. As my hair went greyer from these experiences, I couldn't help thinking more and more about how to make failure less painful. Who wants their pager going off for some silly reason? Nobody. If dealing with production code, we simply must think about how best to deal with various forms of failure.
In this presentation I consider two engineering techniques that I think should always be on the architectural radar:
* Fail fast
* Fail safe
How about trying to minimize Fail while migrating Rapid Prototype into PROD environment?
ReplyDeleteThe simple pattern would be to provide as little code/features as possible, but still meet aggressive prototype agenda.
Basically, moving one step further in question space
from “How to connect A to B?”
to “Can I use less code to connect A to B?”
The less code , the less edges to worry about;)