2 ms·

I disagree that productivity cannot be measured. Measure productivity by the time it takes a developer to achieve a proof of accomplishing the business requirem

I disagree that productivity cannot be measured. Measure productivity by the time it takes a developer to achieve a proof of accomplishing the business requirement through test automation. If it takes a developer 1 hour versus two business days of 8 hours there is a 16x factor of productivity. Tech debt are all the factors that erode productivity. This includes many technical factors from inefficient systems design to unnecessary testing. It also includes slowness from weak developers and developer training. I know it puts me in an extreme minority, but I am a big fan of extreme simplicity, which is not what it might suggest. Extreme simplicity removes everything in a system present for the easiness of the developer so that all that is left is only that which is necessary to accomplish a business requirement as directly as possible. If there is less to read (including dependencies) there is less to maintain and less to test. Simplicity is not easy. The confusion is that a system must achieve a certain level of easiness or it will be rejected by some developers outright or require training at great expense. My basic premise for making any challenging decision is to never compromise on integrity, which includes being honest about the challenge at hand. You can embrace that challenge directly and solve for it or you can hide from it behind layers of easiness.

m0zg 7y ago
This assumes goal complexity is measurable and you can run randomized experiments to measure what you call "productivity". Neither of these assumptions holds in the real world. E.g. changing some business logic can be 10 minutes of work to implement a hack (which will pass tests, mind you), or 2 weeks of strenuous yak shaving for a "principled" solution. Which would you rather pick? And more importantly, are you prepared to select for developers who favor 10 minute hacks to principled solutions?
- austincheney 7y ago
  You measure productivity by the time it takes to complete a task. That is both objective and measurable. How do you define a principled solution versus a hack? All that matters is whether the result achieves the desired business goals without regression, and that is what tests are for. That being said I would gladly pick the 10 minute solution that passes all the tests. So much of development is bullshit posturing for developers to justify their existence with unnecessary tasks to make things easier for themselves.
  - m0zg 7y ago
    You measure productivity that way on the assembly line or other menial tasks where it's obvious how to do things and the work isn't very complicated. Trying to do this with creative professions is a disastrous mistake. >> So much of development is bullshit posturing for developers to justify their existence That applies to any profession. Developers aren't unique in this regard.
    - austincheney 7y ago
      > You measure productivity that way on the assembly line or other menial tasks where it's obvious how to do things Isn't it obvious how to do things in programming? Many developers, in my corporate experience, occupy themselves with how to do things in code. That is exceedingly unfortunate. How to write code should be an obvious disqualifier before obtaining employment. Nobody would hire a lawyer, for instance, who didn't know how to a legal argument. Writing code should be as obvious as writing an essay, but I suspect many developers that are hiring probably have trouble writing essays as well. Anyways, if you had the choice between a 10 minute pizza and a 3 day pizza with ingredients more evenly spaced apart which would you choose?
      - jepcommenter 7y ago
        Writing code is not a problem, changing it without breaking is. Taking tech debt is not a problem, paying interest on it is. And you will hardly hire a lawyer to work in unknown to him legal domain in foreign country in foreigh language.
        austincheney 7y ago
        > changing it without breaking is That is why the software gods invented test automation. > paying interest on it is That is why simplicity is important, because less is more. All code is ultimately debt as it demands some amount of maintenance. When there is less to maintain there is ultimately less debt. > And you will hardly hire a lawyer to work in unknown to him legal domain in foreign country in foreigh language. Has that ever happened to you as a software developer? The one time I was told to learn a new language I was allowed the time and space to learn it.

m0zg 7y ago

This assumes goal complexity is measurable and you can run randomized experiments to measure what you call "productivity". Neither of these assumptions holds in the real world. E.g. changing some business logic can be 10 minutes of work to implement a hack (which will pass tests, mind you), or 2 weeks of strenuous yak shaving for a "principled" solution. Which would you rather pick? And more importantly, are you prepared to select for developers who favor 10 minute hacks to principled solutions?

austincheney 7y ago
You measure productivity by the time it takes to complete a task. That is both objective and measurable. How do you define a principled solution versus a hack? All that matters is whether the result achieves the desired business goals without regression, and that is what tests are for. That being said I would gladly pick the 10 minute solution that passes all the tests. So much of development is bullshit posturing for developers to justify their existence with unnecessary tasks to make things easier for themselves.
- m0zg 7y ago
  You measure productivity that way on the assembly line or other menial tasks where it's obvious how to do things and the work isn't very complicated. Trying to do this with creative professions is a disastrous mistake. >> So much of development is bullshit posturing for developers to justify their existence That applies to any profession. Developers aren't unique in this regard.
  - austincheney 7y ago
    > You measure productivity that way on the assembly line or other menial tasks where it's obvious how to do things Isn't it obvious how to do things in programming? Many developers, in my corporate experience, occupy themselves with how to do things in code. That is exceedingly unfortunate. How to write code should be an obvious disqualifier before obtaining employment. Nobody would hire a lawyer, for instance, who didn't know how to a legal argument. Writing code should be as obvious as writing an essay, but I suspect many developers that are hiring probably have trouble writing essays as well. Anyways, if you had the choice between a 10 minute pizza and a 3 day pizza with ingredients more evenly spaced apart which would you choose?
    - jepcommenter 7y ago
      Writing code is not a problem, changing it without breaking is. Taking tech debt is not a problem, paying interest on it is. And you will hardly hire a lawyer to work in unknown to him legal domain in foreign country in foreigh language.
      - austincheney 7y ago
        > changing it without breaking is That is why the software gods invented test automation. > paying interest on it is That is why simplicity is important, because less is more. All code is ultimately debt as it demands some amount of maintenance. When there is less to maintain there is ultimately less debt. > And you will hardly hire a lawyer to work in unknown to him legal domain in foreign country in foreigh language. Has that ever happened to you as a software developer? The one time I was told to learn a new language I was allowed the time and space to learn it.