3 ms·
This only applies to servicing contracts, when you're the customer constant delivery is very well overrated. Even with servicing contracts shipping every week o
by 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.