There are many reasons why software projects fail. In this post I will cover one of the main reasons I think outsource product development fails to deliver the right product at the right time. The reason is that customers outsource product management as well. They think their job is done after sharing the wireframes. These wireframes are typically created by a third party design agency. Customer product team usually works closely with the design agency. They will usually call this an MVP. The only thing they get from the whole MVP concept is that it needs to be delivered faster to the end customer. They completely ignore the minimal part. I usually see MVPs with more than 500 screens. These do not include failure states. I know screens are not the right measure of the application complexity but during the proposal phase this is the max you will get.
Continue reading “You can’t outsource product management”Month: December 2021
Key Insights From Amazon Builder Library
For the last couple of weeks I have been going over articles and videos in the Amazon Builder library. They cover useful patterns that Amazon uses to build and operate software. Below are the important points I captured while going over the material.
Reliability, constant work, and a good cup of coffee – Link
- Amazon systems strive to solve problems using reliable constant work patterns. These work patterns have three key features:
- One, they don’t scale up or slow down with load or stress.
- Two, they don’t have modes, which means they do the same operations in all conditions.
- Three, if they have any variation, it’s to do less work in times of stress so they can perform better when you need them most.
- There are not many problems that can be efficiently designed using constant work patterns.
- For example, If you’re running a large website that requires 100 web servers at peak, you could choose to always run 100 web servers. This certainly reduces a source of variance in the system, and is in the spirit of the constant work design pattern, but it’s also wasteful. For web servers, scaling elastically can be a better fit because the savings are large. It’s not unusual to require half as many web servers off peak time as during the peak.
- Based on the examples given in the post it seems that a constant work pattern is suitable for use cases where system reliability, stability, and self-healing are primary concerns. It is fine if the system does some wasteful work and costs more. These are essential concerns for systems which others use to build their systems on. I think control plane systems fall under this category. The example of such a system mentioned in the post is a system that applies configuration changes to foundational AWS components like AWS Network load balancer. The solution can be designed using both the push and pull based approach. The pull based constant work pattern approach lends to a simpler and reliable design.
- Although not mentioned in the post, constant work that the system is doing should be idempotent in nature.
Shekhar Gulati 