4 ms·

Many of these points seem to mask larger issues and be focused on a particular type of application. Very technical, experimental, or fault-intolerant applicati

Many of these points seem to mask larger issues and be focused on a particular type of application. Very technical, experimental, or fault-intolerant applications may need a different balance of factors. > Engineers should operate their code. Are engineers the customers? What matters is the customer experience. Getting engineers directly involved risks lowering of customer priorities. > Buy ... beats build It depends on how much control you need. Sure it can be quicker and cheaper overall, but if available systems are not actually a match it is only a matter of time before some customization or a custom system is needed. Try to find and commit to the right balance as soon as possible. > Make deploys easy This really depends on the kind of system and its usage. In fault intolerant systems it makes sense to take deploys as slowly and carefully as possible because the risk of problems even from changes that are considered fixes is not tolerable. > Trust the People Closest to the Knives In the larger picture this is marketing who must focus on knowing the customer and their needs. > QA Gates Make Quality Worse Some interactions are difficult to automate. It often makes more sense to slow things down to get the quality right than to go fast and increase risk. > Boring Technology is Great. Depending on your goals and context. Does boring sell? Are your customers requesting boring? > Simple always wins That is similar to the boring rule above, but with the added complication that simple is subjective and context dependent. Perhaps some complex existing mechanism can be adapted, so is that really simple or not? > Non-Production Environments Have Diminishing Returns But they are essential returns. If the engineers can get the thing to work on their desks then it isn't likely to work for customers. > Things Will Always Break This is pure squittering. In some context providing services that do not break is the key feature. For many products markets will reject this modern view of moving fast because it is okay to break things. Some customers are tolerant and will pay extra for special functionality, but others are intolerant and would prefer robust functionality to engineer maximization.

axlee 6y ago
> In the larger picture this is marketing who must focus on knowing the customer and their needs. Is Marketing responsible for UX research in your organization? > Depending on your goals and context. Does boring sell? Are your customers requesting boring? I'd argue that your customers do not give a flying crap whether or not you're using GraphQL or a plain old relational database behind the scenes, as long as their experience isn't affected. Unless you are a vendor of a non-boring alternative to one of the aforementioned boring tools, boring is absolutely superior...until it doesn't fulfill the needs of your platform. But by then, your company will have reached the point where you can put dozens of engineers on that single issue, and come up with the new flavour of "boring" standard. > But they are essential returns. If the engineers can get the thing to work on their desks then it isn't likely to work for customers. I think one of core tenets of this approach is to make local development as close as possible to production. Staging servers do not always capture production issues either, and IMO their main use is for internal collaboration and demoing, not finding out about issues. If you can replicate an issue locally, you do not need to test on staging. If you can't replicate an issue locally, it's very unlikely that the issue would arise on staging either. Of course, if your codebase has vastly different runtimes in local and in prod, all of the above does not apply.

axlee 6y ago

> In the larger picture this is marketing who must focus on knowing the customer and their needs. Is Marketing responsible for UX research in your organization? > Depending on your goals and context. Does boring sell? Are your customers requesting boring? I'd argue that your customers do not give a flying crap whether or not you're using GraphQL or a plain old relational database behind the scenes, as long as their experience isn't affected. Unless you are a vendor of a non-boring alternative to one of the aforementioned boring tools, boring is absolutely superior...until it doesn't fulfill the needs of your platform. But by then, your company will have reached the point where you can put dozens of engineers on that single issue, and come up with the new flavour of "boring" standard. > But they are essential returns. If the engineers can get the thing to work on their desks then it isn't likely to work for customers. I think one of core tenets of this approach is to make local development as close as possible to production. Staging servers do not always capture production issues either, and IMO their main use is for internal collaboration and demoing, not finding out about issues. If you can replicate an issue locally, you do not need to test on staging. If you can't replicate an issue locally, it's very unlikely that the issue would arise on staging either. Of course, if your codebase has vastly different runtimes in local and in prod, all of the above does not apply.