I think that only scratches the surfaces and the devil lies in the detail.
Or in other words: Developers tend to not agree what “well designed” means.
Outages are treated as systemic because most of them are. That’s because testing practices are so good that individual errors are caught long before they become impactful failures.
I’d argue that if you believe that tests will catch all errors “long before they become impactful failures” the IT landscape would look very differently.
I agree overall, but that’s probably because it’s very vague general statements. Yes, you obviously want to have tests, trust in code, deployments, etc., have good code reviews and yes you don’t want to work at a place full of psychopaths and have actual staging environments.
I have never ever ever found or encountered a company that would value and define quality or give room to quality as defined in this post.
(I have seen company bragging and building up the story telling with similar messages).
Also, I believe not only the company is to blame, but also an ego-market-yourself kind of sociology/mentality that privilege individual visibility, “influencer profiles” and loves the story telling around it which ends up in teams mentality/incentive/rewards mechanisms & dynamics..
When the starification of tech has slowly replaced the fun…
My humble 2 cents as a nobody
While I agree with your point, this isn’t new. There have been people beating their own drum since the beginning. Think for example about Dijkstra’s famous egomania, DJB’s self-aggrandizement, and Jamie Zawinski’s inflated war stories, or Eric Raymond’s way of inflating his contributions to the hacker’s dictionary and fetchmail.
Dijkstra’s famous egomania, DJB’s self-aggrandizement, and Jamie Zawinski’s inflated war stories, or Eric Raymond’s way of inflating his contributions to the hacker’s dictionary and fetchmail.
I agree with this. My goal is to develop systems and environments that lead to quality, and I believe that it can’t be an afterthought. You can’t test quality into a system, it has to come from within.
I’m probably more open than most to the idea of this affecting everything in a software project, including architecture and design patterns. Design-for-test is a common phrase in hardware, I believe in design-for-quality in software.
Quality is systemic, but you need very good people to build the system and shepherd it successfully. The system is the tool that allows them to force-multiply.
I think that only scratches the surfaces and the devil lies in the detail.
Or in other words: Developers tend to not agree what “well designed” means.
I’d argue that if you believe that tests will catch all errors “long before they become impactful failures” the IT landscape would look very differently.
I agree overall, but that’s probably because it’s very vague general statements. Yes, you obviously want to have tests, trust in code, deployments, etc., have good code reviews and yes you don’t want to work at a place full of psychopaths and have actual staging environments.
I have never ever ever found or encountered a company that would value and define quality or give room to quality as defined in this post. (I have seen company bragging and building up the story telling with similar messages). Also, I believe not only the company is to blame, but also an ego-market-yourself kind of sociology/mentality that privilege individual visibility, “influencer profiles” and loves the story telling around it which ends up in teams mentality/incentive/rewards mechanisms & dynamics.. When the starification of tech has slowly replaced the fun… My humble 2 cents as a nobody
While I agree with your point, this isn’t new. There have been people beating their own drum since the beginning. Think for example about Dijkstra’s famous egomania, DJB’s self-aggrandizement, and Jamie Zawinski’s inflated war stories, or Eric Raymond’s way of inflating his contributions to the hacker’s dictionary and fetchmail.
One of those things is not like the others!
But which one? :-P
I agree with this. My goal is to develop systems and environments that lead to quality, and I believe that it can’t be an afterthought. You can’t test quality into a system, it has to come from within.
I’m probably more open than most to the idea of this affecting everything in a software project, including architecture and design patterns. Design-for-test is a common phrase in hardware, I believe in design-for-quality in software.
Quality is systemic, but you need very good people to build the system and shepherd it successfully. The system is the tool that allows them to force-multiply.