You never want to built anything shoddily, but there is a lot of value in doing minimum scope. Testing, clean code, etc shouldn't be negotiable in most shops, but scope can be really trimmed down in a lot of scenarios.
Universe Z:
- Programmer X implements feature A in 1 week with tiny scope
- Feature B is mothballed and never gets built
Universe A:
- Programmer X implements feature in 2 weeks
- One year later: This functionality is broken apart into a well defined microservice with additional responsibilities. This needs a total rewrite as a v2 API.
Universe B:
- Programmer implements a feature in 1 week
- One month later with that extra week they were able to squeeze in an unrelated enhancement to the system that delivered .5% extra revenue during Black Friday.
I find most of the productivity metrics fail because you're squeezing the wrong end of the process. You want to spend the most time making sure you're doing what matters and has value, and then it will almost always be worth the time. This makes people feel engaged, which will lead to a lot more productivity than when you're pushing them to build something they don't care about.
If you really wanted to get into waste, how about the building to spec process?
Spec universe: engineer makes thing. bean counters believe they will be out of business if others see how thing is made and copywright their code. another engineer wants to make the same thing. a second engineer has to be brought in to write up a spec. the other engineer now tries to reinvent this wheel from basically a telephone game description on how it should work and behave. as a result any time an engineer needs a wheel you need a second engineer to describe it to you so you can reinvent the wheel.
open source universe: engineer makes thing. second engineer forks thing.
Universe Z: - Programmer X implements feature A in 1 week with tiny scope - Feature B is mothballed and never gets built
Universe A: - Programmer X implements feature in 2 weeks - One year later: This functionality is broken apart into a well defined microservice with additional responsibilities. This needs a total rewrite as a v2 API.
Universe B: - Programmer implements a feature in 1 week - One month later with that extra week they were able to squeeze in an unrelated enhancement to the system that delivered .5% extra revenue during Black Friday.
I find most of the productivity metrics fail because you're squeezing the wrong end of the process. You want to spend the most time making sure you're doing what matters and has value, and then it will almost always be worth the time. This makes people feel engaged, which will lead to a lot more productivity than when you're pushing them to build something they don't care about.