Ship it and iterate often bugs me because sometimes it really works and sometimes it really doesn’t.
Summary being the example of where it needed to be iterated on more before release from labs. It could have been shipped as it was, had a couple of iterations and then been really useful when launched. As it was, it was not very useful at all at release and felt very rushed to fit the “Ship it and iterate” ideal.
This isn’t always the case and there have been a lot of features that didn’t suffer this problem. I personally feel that sometimes it needs to be treated on a case by case basis rather than “Ship it and iterate” no matter what
As mentioned in the article these are not rules to be dogmatically adhered to, but we believe they are generally-applicable enough to be a useful guide
Great blog post! I think there’s a few wise words there that would benefit any engineer.
I love “Solve problems at the root”. I think it’s fundamental to know deeply your application, as it’s the only way to improve/fix it in the right (and often fast) way, and implementing a good set of tests helps a lot to understand how the application works.
Also it is very important to be flexible and open to changes, it doesn’t matter how many hours you spent on a solution, if it doesn’t work, you need to change it, or add it to your technical debt.
Something that I often struggle, it’s to work for companies that knows how to proper handle the technical debt. Too often they behave like countries, thinking they can increase their debt forever