- (1) More resources don't always make things go faster.
- (2) Compromising does not always compromise quality of work. You can always cut scope as you mention in (4) and ship less features at a higher level of quality. Although what I was getting at was more that we have a tendency when given time to go about refactoring and rearchitecting things that don't necessarily need to be done, or introducing unnecessary / premature abstractions and optimizations. Deadlines tend to curb instinct to do that.
- (3) You can miss deadlines, but that's not a clean win either. It hurts morale, allows for feature-creep (oh you're not shipping next week, well boy do I have some extra things you could do with your newfound time) and hurts relationships with teams depending on what you're setting out to deliver all across the company.
- (4) Adjusting scope can make sense, so long as you're very good at figuring out what doesn't need to go out. Not every team is.
tl;dr: Shipping the right 70% of the feature set at 100% quality without premature / unnecessary optimizations and abstractions can be pushed along by aggressive timelines. This must always be balanced with sustainability.
The root problem seems to be that committing to getting something done is somehow tied into honesty and dependability. I feel like in Software Engineering at least, we should be careful to not make that association right away simply because the nature of the work is kinda unpredictable, especially when working with new/unfamiliar systems.
It looks like a few people have reached somewhat similar conclusions and create frameworks around this idea (Agile, Extreme, TDD etc.) to formalize the processes. But it perhaps makes sense to realize that they are just that: processes and heuristics trying to make a hard problem (delivering software predictably on schedule) more manageable.
- (2) Compromising does not always compromise quality of work. You can always cut scope as you mention in (4) and ship less features at a higher level of quality. Although what I was getting at was more that we have a tendency when given time to go about refactoring and rearchitecting things that don't necessarily need to be done, or introducing unnecessary / premature abstractions and optimizations. Deadlines tend to curb instinct to do that.
- (3) You can miss deadlines, but that's not a clean win either. It hurts morale, allows for feature-creep (oh you're not shipping next week, well boy do I have some extra things you could do with your newfound time) and hurts relationships with teams depending on what you're setting out to deliver all across the company.
- (4) Adjusting scope can make sense, so long as you're very good at figuring out what doesn't need to go out. Not every team is.
tl;dr: Shipping the right 70% of the feature set at 100% quality without premature / unnecessary optimizations and abstractions can be pushed along by aggressive timelines. This must always be balanced with sustainability.