Enjoy the sausage, but if you have a weak stomach, don’t watch how it’s made.
(I work for AWS but not on the DynamoDB team and I have no first-hand knowledge of the above claim. Opinions are my own and not those of my employer.)
Enjoy the sausage, but if you have a weak stomach, don’t watch how it’s made.
(I work for AWS but not on the DynamoDB team and I have no first-hand knowledge of the above claim. Opinions are my own and not those of my employer.)
This is true though there's only so much technical debt and internal process chaos you can create before it affects the outcome. It's a leading indicator, so by the time customers are feeling that pain you've got a lot of work in front of you before you can turn it around, if at all, and customers are not going to be happy for that duration.
Technical debt is not something to completely defeat or completely ignore, instead it's a tradeoff to manage.
One concrete problem with technical debt the article highlights is it that negatively impacts the time to deliver new features. Customers today usually expect not only a great initial feature set from a product, but also a steady stream of improvements and growth, along with responsiveness to feedback and pain points.
Additionally, the business cares about the outcome, not the internal process.
Ostensibly, the business should care about process but it actually doesn't matter as long as the product is just good enough to obtain/retain customers, and the people spending the money (managers) aren't incentivized to make costs any lower than previously promised (status quo).
When this is the case it’s often nice to state this conflict of interest, so others can take your appraisal in the appropriate context.
I’m not implying anything about the post, just stating what I assume to be the reason for the disclosure.
This is designed to reduce the chances of eager employees going out and astro-turfing or otherwise acting in trust-damaging ways while thinking they're "helping".