3 ms·

Thats usually not possible. We're not doing pure science, we're doing engineering - which happens to mix science AND economics. This means the "no deadlines" w

Thats usually not possible. We're not doing pure science, we're doing engineering - which happens to mix science AND economics. This means the "no deadlines" wet dream is usually a recipe for "oh shit, we ran out of money" for most projects. Also programmers are usually big babies; give them unlimited time and they'll give you unlimited bloat. Other than doing R&D it usually is impossible to have no deadlines. Most people are not doing R&D, but when you really do your government usually has programs to finance it. That's precisely how you can afford to not have deadlines because your company is paid to advance the state of the art. And even then you usually get paid after the project is over and after you've filled a bunch of forms to clearly state the problem, your solution as well as existing work in the area and why it did not apply to your case. Or if you're doing servicing work you get paid by shipping at predetermined milestones. Building software is a LOT more complex than just writing down the code and too many developers are clueless when it comes to politics, economics or management. I used to think the same when I was still new to the software industry. It took me years to understand theres a whole world around programming required for programming to happen in the first place.

BurningFrog 10y ago
People can use "we have no deadlines" as an excuse to never do anything useful. This is why one part of the Agile Manifesto that isn't talked about as much as it maybe should be is about how you need to build trust with your customer by constantly delivering value. Demanding that trust from strangers is hard sell, and it probably should be. The big problem with deadlines is that it's impossible to predict how long something will take, so you end up in a game of lies and bluffs to create and take away buffers to account for the uncertainty, which leads to horrible relations between the dev team and it's customers. Also, it falls apart, when priorities change.
- jeremiep 10y ago
  This only applies to servicing contracts, when you're the customer constant delivery is very well overrated. Even with servicing contracts shipping every week or two is a definite recipe for mediocrity. You're wasting all that upfront analysis for the sake of early delivery and then suffer from all the bad technical decisions made to build it in a rush. Expect insane amounts of overtime to reach the last milestone on time for such projects. Deadlines are not that hard when you properly plan to reach them and give yourself a large buffer of time for debugging and QA. You just need to properly analyse the requirements, the existing solutions in your problem's domain, what is known and unknown (keeping meta-ignorance in mind - you dont know what you dont know) and then re-analysing it all every time the requirements change, even slightly. This means you're going to spend a lot of time upfront before coding starts, and the first deliverable will be months away. Solid foundations yield by far the most agility to any project I've ever seen, and continuous delivery prevents these foundations from being built in the first place. You definitely won't see any proper abstractions at such a pace, what you're most likely to see is an endless sea of indirections. Same for testing, I've seen many teams starting to write tests for requirements that weren't well understood yet. Then they start piling code up until the tests passes, and finally wonder why there's tons of new bugs in Jira every week. All the tests passed! The type checker passed! But now there's no time left for debugging and the project gets over time and over budget. The smoothest servicing projects I've ever done were with customers understanding the nature of our work and not minding a long time window before the first delivery, not interfering with the work. The worst servicing projects were having two weeks sprints where the managers would bend over to every single customer demand for fear of losing the contract at the cost of burning out the team and having no quality whatsoever in the finished product. You get trust with new customers based on your own track record of successfully shipped projects, not continuous delivery over arbitrary milestones. And then you can manage the customer, instead of being managed by them. They pay you because they can't do the work in the first place after all.
wpietri 10y ago
Thanks, but I understand the economics of software reasonably well. Note that we are discussing "no deadlines or release dates for specific features", not just a magical world without consequences. If you are looking for how this works, Poppendieck's books on Lean Software Development go into both the theory and practice. But the basic notion is that you control costs via scope control, waste reduction, minimizing WIP, and continuous improvement. One still delivers things quickly and efficiently; it's just that deadlines are not used as a control mechanism. Once you're through Poppendieck's work, I recommend "Priniciples of Product Development Flow": https://www.amazon.com/dp/B007TKU0O0/ https://www.amazon.com/dp/B007TKU0O0/

BurningFrog 10y ago

People can use "we have no deadlines" as an excuse to never do anything useful. This is why one part of the Agile Manifesto that isn't talked about as much as it maybe should be is about how you need to build trust with your customer by constantly delivering value. Demanding that trust from strangers is hard sell, and it probably should be. The big problem with deadlines is that it's impossible to predict how long something will take, so you end up in a game of lies and bluffs to create and take away buffers to account for the uncertainty, which leads to horrible relations between the dev team and it's customers. Also, it falls apart, when priorities change.

jeremiep 10y ago
This only applies to servicing contracts, when you're the customer constant delivery is very well overrated. Even with servicing contracts shipping every week or two is a definite recipe for mediocrity. You're wasting all that upfront analysis for the sake of early delivery and then suffer from all the bad technical decisions made to build it in a rush. Expect insane amounts of overtime to reach the last milestone on time for such projects. Deadlines are not that hard when you properly plan to reach them and give yourself a large buffer of time for debugging and QA. You just need to properly analyse the requirements, the existing solutions in your problem's domain, what is known and unknown (keeping meta-ignorance in mind - you dont know what you dont know) and then re-analysing it all every time the requirements change, even slightly. This means you're going to spend a lot of time upfront before coding starts, and the first deliverable will be months away. Solid foundations yield by far the most agility to any project I've ever seen, and continuous delivery prevents these foundations from being built in the first place. You definitely won't see any proper abstractions at such a pace, what you're most likely to see is an endless sea of indirections. Same for testing, I've seen many teams starting to write tests for requirements that weren't well understood yet. Then they start piling code up until the tests passes, and finally wonder why there's tons of new bugs in Jira every week. All the tests passed! The type checker passed! But now there's no time left for debugging and the project gets over time and over budget. The smoothest servicing projects I've ever done were with customers understanding the nature of our work and not minding a long time window before the first delivery, not interfering with the work. The worst servicing projects were having two weeks sprints where the managers would bend over to every single customer demand for fear of losing the contract at the cost of burning out the team and having no quality whatsoever in the finished product. You get trust with new customers based on your own track record of successfully shipped projects, not continuous delivery over arbitrary milestones. And then you can manage the customer, instead of being managed by them. They pay you because they can't do the work in the first place after all.

wpietri 10y ago

Thanks, but I understand the economics of software reasonably well. Note that we are discussing "no deadlines or release dates for specific features", not just a magical world without consequences. If you are looking for how this works, Poppendieck's books on Lean Software Development go into both the theory and practice. But the basic notion is that you control costs via scope control, waste reduction, minimizing WIP, and continuous improvement. One still delivers things quickly and efficiently; it's just that deadlines are not used as a control mechanism. Once you're through Poppendieck's work, I recommend "Priniciples of Product Development Flow": https://www.amazon.com/dp/B007TKU0O0/ https://www.amazon.com/dp/B007TKU0O0/