> As a person who runs a small software business, coding most of the functionality myself
I'm not even sure you disagree with the article, given you are in a radically different position; how often do you think, as an implementer, that your business ideas are complete bullshit, sometimes even just because you don't know all the details you are thinking about on the business side?
Project management is about communication. Having that problem reduced to communicating mainly with yourself changes a little what is effective and what is not.
> That said, most of time pressure should only be applied at the decision-making level. Once you have decided to ship feature X with framework Y, it's useless to nag on your devs to do it in half the time by dropping unit tests, or doing 60-hour work weeks. Instead, you should have picked feature Z with 50% the complexity and 80% user impact.
So yeah, we could continue to interpret that as you mainly agreeing. Implicit cultural incentives are a thing and it is illusory to think that "devs" won't be aware of schedules and won't drop half of unit tests if there is a risk of looking "bad" at short term if they stuck with state-of-the-art practices.
Note that the solution is not in the extreme opposite, of course. It never is. There is a system of values to be tuned, and I'm not sure a lot of projects exist where the date of completion does not matter at all. Your example of Duke Nukem Forever was on point :) But being date driven would mean the date is the most important thing: this also is rarely the case.
I'm not even sure you disagree with the article, given you are in a radically different position; how often do you think, as an implementer, that your business ideas are complete bullshit, sometimes even just because you don't know all the details you are thinking about on the business side?
Project management is about communication. Having that problem reduced to communicating mainly with yourself changes a little what is effective and what is not.
> That said, most of time pressure should only be applied at the decision-making level. Once you have decided to ship feature X with framework Y, it's useless to nag on your devs to do it in half the time by dropping unit tests, or doing 60-hour work weeks. Instead, you should have picked feature Z with 50% the complexity and 80% user impact.
So yeah, we could continue to interpret that as you mainly agreeing. Implicit cultural incentives are a thing and it is illusory to think that "devs" won't be aware of schedules and won't drop half of unit tests if there is a risk of looking "bad" at short term if they stuck with state-of-the-art practices.
Note that the solution is not in the extreme opposite, of course. It never is. There is a system of values to be tuned, and I'm not sure a lot of projects exist where the date of completion does not matter at all. Your example of Duke Nukem Forever was on point :) But being date driven would mean the date is the most important thing: this also is rarely the case.