DEV Community

Discussion on: The ONE chart every developer MUST understand

Collapse
lewiscowles1986 profile image
Lewis Cowles

One of the biggest problems with this is that it centres around a single keystone in-depth study. It was an interesting choice but I'm not sure I could give it to our product & eng teams to improve their work.

Collapse
bosepchuk profile image
Blaine Osepchuk Author

I'd agree with you if that were true but it's not.

I chose to focus this post narrowly because it's such a big topic and it seemed like a good idea to focus on the strongest evidence. But there are many, many studies backing up this conclusion from many different angles.

Rapid Development contains extensive footnotes so you can look up all those studies.

But you don't have to take anybody's word for anything. Every team should probably be measuring their ROI (results divided by effort) in whatever way is meaningful to them and doing experiments to improve it given how costly software development is.

I'd be shocked if you found your team is more efficient/economically productive if you focused less on defect prevention, pretest defect removal, and the 36 classic mistakes and more on testing, debugging, and rework. But I suppose it's possible.

Cheers.

Collapse
lewiscowles1986 profile image
Lewis Cowles

I'd be shocked if you found your team is more efficient/economically productive if you focused less on defect prevention, pretest defect removal

Whoa there... I never said that, I said this write-up focused on a single keystone.

I did not state if it was wrong or right, just that the article itself doesn't provide dev teams the tools to reduce.

FWIW it was merely a call out to think about action items, not down your work or the concept of the article.

I think other works such as boringtechnology.club/ offer more clearly actionable alternatives which focus.

Thread Thread
bosepchuk profile image
Blaine Osepchuk Author

Apologies, Lewis. I didn't mean to put words in your mouth. It's easy to misinterpret blog comments.

I read your link and I agree with the author's conclusions on the benefits and costs of adding technologies to your stack. But I'm not sure how that relates to the topic of my post. Can you help me understand the connection?