3 ms·

I think you're identifying something adjacent but materially different: an attempt to estimate and wrangle ongoing maintenance, rather than an estimate for an i

by wkirby 2y ago

I think you're identifying something adjacent but materially different: an attempt to estimate and wrangle ongoing maintenance, rather than an estimate for an initial development effort. It's worth calling out that we (Apsis) are a software development agency; our estimates are for our clients, usually for greenfield work, and usually are part of the process of bidding for projects. A very different situation from an engineering team in year 5 of production deployment. That said, even as a member of an internal engineering team, you'll need to coordinate work with the other areas of the business: you can't maneuver a large organization with no calendar for when new features, new products, etc., will become available. Estimates are an inherent part of engineering interacting with the rest of an organization, and I think this framework is still applicable.

lifeisstillgood 2y ago
So I think that the idea of “you cannot maneuver a large org without a calendar” is going back to tommdemarco and risk management as the soul of project mgmt If you run a company and ask me for an estimate on when software will be ready because the rest of the company depends on it, then what you are doing is making a huge bet on the software team delivering to time and quality (and cost!). Now that’s just hoping. There is plenty to do to fix it (reduce scope, improve team dynamics and psychological safety, dual delivery teams etc). But in the end it’s a bet, a guess. Now perhaps there are better ways. I would suggest we look twice at using calendars and deadlines as ways of acgieveing co-ordination - software is waaay better at co-ordination than people and calendars are. Adjust the business model, early releases for special Clients - these can be non-software approaches to risk mitigation, but we find the tech solutions more fun.
- wkirby 2y ago
  > If you run a company and ask me for an estimate on when software will be ready because the rest of the company depends on it This is only one framing. The rest of the company might not depend on it, but they also have work to do that might be best done in parallel instead of serially. A really basic example: I’m the CEO, and I’m speaking at some industry event. I want to know if feature X will be ready so I can announce it at the event, or will should we prepare something else. Engineering is going to need to back into an estimate so that the rest of the org can prepare for a calendar date — marketing, sales, whoever is writing the presentation, whoever is printing the materials for our booth. This is a totally reasonable ask of an engineering org without it being as high stakes as “this is a massive bet on our ability to estimate software timelines” Other parts of the org also have deliverables, and ensuring those deliverables can be coordinated to land at roughly predictable times is the job of management. It seems unfathomably crazy to imply that software is some magical discipline that is immune from having to set expectations.
  - lifeisstillgood 2y ago
    If the CEO is announcing it at a conference, it’s a top line feature that will / should move the needle for the company - ie this is a sizeable bet for the company. Otherwise no-one is listening to the CEO or she is talking at the wrong conference. If it’s a commitment of that size then “here’s a date, rely on it” is terrible management. Yes of course other things need to be co-ordinated My argument is three fold Let’s imagine the company offers an app to record activity on a building site we are adding a photo feature where materials are scanned situ by CV - improving compliance, reducing fraud. It’s worth millions. 1. Co-ordinate with software. What levels of reliability do we want, what milestones will we hit and then turn on certain other activities in the compmay. So set up tests or milestones 2. What’s the idea that software is some Distinct part of a company. It’s everything everywhere. If your marketing team and accounts team and logistics are not up to their eyeballs in software somethings wrong 3. The last point - management has a job. I think we over-play what management can and cannot do. I believe management is being disaggregated by software - and far too often the co-ordination job is a political compromise job not a white hit directive. Edit: I have played with deleting this but it’s a half formed thought - but I am writing a book where the whole software / management idea is being expanded. Maybe it’s only going to stay half formed - but I hope not

by wkirby 2y ago

lifeisstillgood 2y ago

So I think that the idea of “you cannot maneuver a large org without a calendar” is going back to tommdemarco and risk management as the soul of project mgmt If you run a company and ask me for an estimate on when software will be ready because the rest of the company depends on it, then what you are doing is making a huge bet on the software team delivering to time and quality (and cost!). Now that’s just hoping. There is plenty to do to fix it (reduce scope, improve team dynamics and psychological safety, dual delivery teams etc). But in the end it’s a bet, a guess. Now perhaps there are better ways. I would suggest we look twice at using calendars and deadlines as ways of acgieveing co-ordination - software is waaay better at co-ordination than people and calendars are. Adjust the business model, early releases for special Clients - these can be non-software approaches to risk mitigation, but we find the tech solutions more fun.

wkirby 2y ago
> If you run a company and ask me for an estimate on when software will be ready because the rest of the company depends on it This is only one framing. The rest of the company might not depend on it, but they also have work to do that might be best done in parallel instead of serially. A really basic example: I’m the CEO, and I’m speaking at some industry event. I want to know if feature X will be ready so I can announce it at the event, or will should we prepare something else. Engineering is going to need to back into an estimate so that the rest of the org can prepare for a calendar date — marketing, sales, whoever is writing the presentation, whoever is printing the materials for our booth. This is a totally reasonable ask of an engineering org without it being as high stakes as “this is a massive bet on our ability to estimate software timelines” Other parts of the org also have deliverables, and ensuring those deliverables can be coordinated to land at roughly predictable times is the job of management. It seems unfathomably crazy to imply that software is some magical discipline that is immune from having to set expectations.
- lifeisstillgood 2y ago
  If the CEO is announcing it at a conference, it’s a top line feature that will / should move the needle for the company - ie this is a sizeable bet for the company. Otherwise no-one is listening to the CEO or she is talking at the wrong conference. If it’s a commitment of that size then “here’s a date, rely on it” is terrible management. Yes of course other things need to be co-ordinated My argument is three fold Let’s imagine the company offers an app to record activity on a building site we are adding a photo feature where materials are scanned situ by CV - improving compliance, reducing fraud. It’s worth millions. 1. Co-ordinate with software. What levels of reliability do we want, what milestones will we hit and then turn on certain other activities in the compmay. So set up tests or milestones 2. What’s the idea that software is some Distinct part of a company. It’s everything everywhere. If your marketing team and accounts team and logistics are not up to their eyeballs in software somethings wrong 3. The last point - management has a job. I think we over-play what management can and cannot do. I believe management is being disaggregated by software - and far too often the co-ordination job is a political compromise job not a white hit directive. Edit: I have played with deleting this but it’s a half formed thought - but I am writing a book where the whole software / management idea is being expanded. Maybe it’s only going to stay half formed - but I hope not