Posts

Elevator Pitch

Have you ever had a conversation with someone where both of you make agreements, set expectations, time goes by and the results were different than agreed/expected? I refer to this as: "Dealing with people is like dealing with the command line for the first time, You give a command arguments/options assuming you know what you will get and then you realize it is not that easy." Why is it not easy? You don't understand the purpose of a certain command and by default its options/arguments. In short, you don't understand the intent. Why call it "uptime driven development"? Because it is simple. Because it makes people try to define it and come to pretty accurate conclusions from the get go. Pretty accurate doesn't mean people understand the point Because people don't understand the point I think an exercise will help. Example: You tell a Project Manager we are doing "uptime driven development" and let this person define what...
Post a Comment
Read more

Design for uptime (Rough draft)

What design for uptime is not is not about telling people which programming language to use is not about telling people how to solve a problem is not about telling people which set of technologies to use is not one sided. Both parties (Provider and Consumer) commit to provide X experience and consume it in Z way/form What design for uptime is is a methodology for developing/maintaining products/services is about defining what a customer/consumer can expect from a service/app/daemon like: Uptime Time to response/reply Data structure is about defining how a customer/consumer should use a service/app/daemon B amount of requests per second/hour/day (Only if necessary) C Data is available at https://service.domain.tld/path/that/makes/sense/data/would/be/at is about setting a basic/base communication layer As an example, HTTP as the basic/base communication layer between our different services HTTP Methods GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS,...
Post a Comment
Read more