Artwork

Content provided by Jayme Edwards. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Jayme Edwards or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.
Player FM - Podcast App
Go offline with the Player FM app!

Are Programmers Really To Blame For BAD Estimates?

16:51
 
Share
 

Manage episode 334072020 series 1756036
Content provided by Jayme Edwards. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Jayme Edwards or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.

When programmers are forced to estimate code on software projects and they turn out wrong, who's to blame? Are there other reasons why estimating software development projects are so hard, that are outside the control of each programmer?

In this episode, I share some of the unique properties of estimating code, and why programming estimates are different than many other types of work. Most of it boils down to treating software development like manufacturing, which is a repeatable process that doesn't involve as much teamwork. Programming on the other hand, is usually done on a team. And to meet the commitment forecasted by our estimate, we need help from other developers.

There are also complexities to our work that make estimating increased the chance that things go bad that are a symptom of misunderstanding the nature of programming by project managers, product managers, and scrum masters at some companies. They need help from software developers to understand why the number of variables increases the chance that estimates turn out bad, and that the degree of things being wrong can have disastrous consequences for business commitments that relied on estimates.

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Chapter markers / timelinks:

(00:00) Introduction(01:19) 1. Why Programming Is Unreliable(01:26) 1.1 Not Repeatable(02:06) 1.2 Too Many Variables(02:50) 1.3 Surface Understanding(04:06) 1.4 Unique Integration(04:59) 1.5 Low Diagnostic Output(06:08) 1.6 Knowledge Work Mismatch(07:19) 1.7 Undervalued Teamwork(08:20) 2. Reduce Impact of Bad Estimates(08:42) 2.1 Reduce Estimated Work(10:06) 2.2 Keep Estimates With Estimators(11:26) 2.3 Estimate In Components(12:50) 2.4 Choose Familiar Technologies(13:56) 2.5 Find Native Integrations(15:04) 2.6 Stop Using Estimates(16:10) Episode Groove

Visit me at thrivingtechnologist.com

  continue reading

165 episodes

Artwork
iconShare
 
Manage episode 334072020 series 1756036
Content provided by Jayme Edwards. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Jayme Edwards or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.

When programmers are forced to estimate code on software projects and they turn out wrong, who's to blame? Are there other reasons why estimating software development projects are so hard, that are outside the control of each programmer?

In this episode, I share some of the unique properties of estimating code, and why programming estimates are different than many other types of work. Most of it boils down to treating software development like manufacturing, which is a repeatable process that doesn't involve as much teamwork. Programming on the other hand, is usually done on a team. And to meet the commitment forecasted by our estimate, we need help from other developers.

There are also complexities to our work that make estimating increased the chance that things go bad that are a symptom of misunderstanding the nature of programming by project managers, product managers, and scrum masters at some companies. They need help from software developers to understand why the number of variables increases the chance that estimates turn out bad, and that the degree of things being wrong can have disastrous consequences for business commitments that relied on estimates.

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Chapter markers / timelinks:

(00:00) Introduction(01:19) 1. Why Programming Is Unreliable(01:26) 1.1 Not Repeatable(02:06) 1.2 Too Many Variables(02:50) 1.3 Surface Understanding(04:06) 1.4 Unique Integration(04:59) 1.5 Low Diagnostic Output(06:08) 1.6 Knowledge Work Mismatch(07:19) 1.7 Undervalued Teamwork(08:20) 2. Reduce Impact of Bad Estimates(08:42) 2.1 Reduce Estimated Work(10:06) 2.2 Keep Estimates With Estimators(11:26) 2.3 Estimate In Components(12:50) 2.4 Choose Familiar Technologies(13:56) 2.5 Find Native Integrations(15:04) 2.6 Stop Using Estimates(16:10) Episode Groove

Visit me at thrivingtechnologist.com

  continue reading

165 episodes

All episodes

×
 
Loading …

Welcome to Player FM!

Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.

 

Quick Reference Guide