3 ms·

I’ve been thinking a lot about this exact problem lately. If we accept the concept of “better / faster / cheaper”, but the velocity and cost of a team is fixed,

I’ve been thinking a lot about this exact problem lately. If we accept the concept of “better / faster / cheaper”, but the velocity and cost of a team is fixed, then the only variable is “better”. This means that we can either reduce the feature count or we can reduce the code quality. If we stick to the plan (which inevitably talks about features) then it’s quality that will suffer, but reducing quality has a significant cascading effect on the entire project. So the only real option is to change the plan - change the deliverables timing. But if the value of the plan was predictability, this option suggests that long term planning isn’t particularly valuable anyway.

xorcist 4y ago
> If we accept the concept of “better / faster / cheaper” The idea that these are somehow constant is one of those things that looks superficially reasonable but really is not. I often hear people wanting to reduce quality to increase velocity. But that's not how any of this works. Code that is hard to read, issues with tooling and papercut-type bugs that aren't showstoppers are the velocity tarpit. And these are the first things people skimp on in order to move faster. It's not just a long- versus short term thinking either. Part of it is that nobody really knows what "quality" is in a software development context. Except for the people who specialize in software quality, but they mean something different than the rest of us.
- doctor_eval 4y ago
  To be clear I’m not suggesting (and don’t believe) that velocity can be improved by reducing quality - that’s actually my point. To put it another way, the dimensions of software projects are mostly invariant; absent an unlimited budget and unlimited time, one of the few effective knobs to fiddle with is the number of features shipped by a given time. The problem is that long term plans and detailed road maps attempt to make feature delivery invariant as well, which - IMO - is why at least 30% of IT projects still fail [0] - and of those that are said to have succeeded, many of them seem to have redefined success post-hoc. When we start to believe that delivering features to some inflexible plan decided 12 months ago is why we’re here, we’re well on the path to building crap. What’s important to me is to ship good software as quickly as possible, learn from the users, and be flexible and respectful about the future. [0] I’m sorry but it’s late and I’m too tired to pull out the PMI stats URL, but a cursory search should find the latest stats.

xorcist 4y ago

> If we accept the concept of “better / faster / cheaper” The idea that these are somehow constant is one of those things that looks superficially reasonable but really is not. I often hear people wanting to reduce quality to increase velocity. But that's not how any of this works. Code that is hard to read, issues with tooling and papercut-type bugs that aren't showstoppers are the velocity tarpit. And these are the first things people skimp on in order to move faster. It's not just a long- versus short term thinking either. Part of it is that nobody really knows what "quality" is in a software development context. Except for the people who specialize in software quality, but they mean something different than the rest of us.

doctor_eval 4y ago
To be clear I’m not suggesting (and don’t believe) that velocity can be improved by reducing quality - that’s actually my point. To put it another way, the dimensions of software projects are mostly invariant; absent an unlimited budget and unlimited time, one of the few effective knobs to fiddle with is the number of features shipped by a given time. The problem is that long term plans and detailed road maps attempt to make feature delivery invariant as well, which - IMO - is why at least 30% of IT projects still fail [0] - and of those that are said to have succeeded, many of them seem to have redefined success post-hoc. When we start to believe that delivering features to some inflexible plan decided 12 months ago is why we’re here, we’re well on the path to building crap. What’s important to me is to ship good software as quickly as possible, learn from the users, and be flexible and respectful about the future. [0] I’m sorry but it’s late and I’m too tired to pull out the PMI stats URL, but a cursory search should find the latest stats.