3 ms·

The article begins with: Engineering leaders have long sought to improve the productivity of their developers ... A goal every organization can support, n

The article begins with: Engineering leaders have long sought to improve the productivity of their developers ... A goal every organization can support, no doubt. What the rest of the article fails to discuss is how upstream-processes determine developer productivity far more than the three dimensions identified. To wit, the clarity and focus of "what and why" for an effort determines the "how and when." Which makes the answer to "knowing how to measure or even define developer productivity" no longer elusive, but instead quantifiable. Few, if any, qualified developers I have worked with have a poor DevEx when the work needed to be done is well-defined (what) and can be explained such that a solution is identifiable (why). Solutions almost always flow from these (how), with an ability to communicate the work effort possible (when). Skip the up-front investment by stakeholders on "what and why", "how" will remain nebulous, and "when" will be just a guess.

brutusborn 3y ago
I agree the types of data they consider could be widened. How would you quantify how much “what and why” has been defined? Some kind of diff between the planned architecture or requirements on day 0 and the final codebase?
- AdieuToLogic 3y ago
  > How would you quantify how much “what and why” has been defined? Has been defined or needs to be? I'll assume the latter for sake of discussion. When skeletal feature specifications can be coded against requirements such that stakeholders and engineers can have a meaningful discussion of the functional expectations (as captured by the specs), along with the engineers having enough understanding to perform impact analysis on the existing system (if any). This is usually an iterative process engaged before any significant implementation is undertaken. Essentially, the upstream-processes I reference regard establishing a shared understanding. As such, most delivery metrics are not relevant at this point. However, an important benefit is that unneeded effort is often identified and not engaged. > Some kind of diff between the planned architecture or requirements on day 0 and the final codebase? In general, system architecture and code bases exist in the "how", not in the "what and why." At a macro (business) level, sometimes architecture decisions such as whether or not to use a cloud provider or data centers do influence the "what." It's kind of like branching in a programming language. Typically, the earlier an execution flow is determined, the less are needed later. So, too, the sooner stakeholders clearly define "what and why", the less effort is needed to identify "how."
budgi4 3y ago
Good call out. Depending on how you're organised, product own the 'what' and 'why'. Engineering own the 'how'.

brutusborn 3y ago

I agree the types of data they consider could be widened. How would you quantify how much “what and why” has been defined? Some kind of diff between the planned architecture or requirements on day 0 and the final codebase?

AdieuToLogic 3y ago
> How would you quantify how much “what and why” has been defined? Has been defined or needs to be? I'll assume the latter for sake of discussion. When skeletal feature specifications can be coded against requirements such that stakeholders and engineers can have a meaningful discussion of the functional expectations (as captured by the specs), along with the engineers having enough understanding to perform impact analysis on the existing system (if any). This is usually an iterative process engaged before any significant implementation is undertaken. Essentially, the upstream-processes I reference regard establishing a shared understanding. As such, most delivery metrics are not relevant at this point. However, an important benefit is that unneeded effort is often identified and not engaged. > Some kind of diff between the planned architecture or requirements on day 0 and the final codebase? In general, system architecture and code bases exist in the "how", not in the "what and why." At a macro (business) level, sometimes architecture decisions such as whether or not to use a cloud provider or data centers do influence the "what." It's kind of like branching in a programming language. Typically, the earlier an execution flow is determined, the less are needed later. So, too, the sooner stakeholders clearly define "what and why", the less effort is needed to identify "how."

budgi4 3y ago

Good call out. Depending on how you're organised, product own the 'what' and 'why'. Engineering own the 'how'.