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.
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
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.
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
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?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
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.
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.
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?