Also it’s such a “junior” level of understanding the process it’s downright cringeworthy.
What you describe is measuring work going in rather than results coming out, when it’s the latter that matters and you actually want to minimize the ratio of the former to the latter (it’s literally the definition of “efficiency”), not maximize it - some of the most effective and advanced software development involves lots of time of what looks like “sitting on your hands” (i.e. analysing the problem) so that a correct and complete result can be delivered directly and without wasting time because “unexpected” things were found, often with less time spent coding than analysing (in management speak: you spend time turning your known unknowns into known knowns so that you can address them upfront instead of wasting time of multiple people later (or worse) due to “unforseen” gaps and problems in the software.
It’s a massive sign that management hasn’t got a fking clue what they’re doing when, in IT they’re engaging in the whole “tracking hours going in” rigmarole, because that actually measuring and ultimatelly rewarding the very opposite of what is good for the company - unless we’re talking about an IT Consultancy, that company’s (or that division within the company’s) product is not lots of well tracked hours worked, it’s software that correctly serves internal or external customer needs, it’s problems solved, it’s good integrations that are completed and delivered in a timelly fashion without the stupid ping-pong between teams as they found “stuff we forgot about” because they didn’t spend time analysing it upfront since they were being measured in “coding hours” (or are too junior to know the value of it or never worked in an effective IT environment).
In IT measuring time-in does nothing to help deliver good results: generally it just incentivises rushed coding that produces little more than constant fires and hence constant firefighting (which, and this is the most hilarious part, then gets measured as hours spent working hence a good thing)
And this is is just the time static stuff. Then there’s all about preparimg for tomorrow whilst you’re doing for today (i.e. maintenability and extendability considerations) which are how you can keep productivity high as the codebase grows, an outcome which is not only not even dectable by simply measuring “hours in”, and requires a time investment which is actually punished when all that is measured is “hours in” because it looks like time waste.
I’m sorry but you’re probably working under a management team that has no clue about software development processes and, worse, you’re celebrating as a great thing the visible artifacts of management incompetence.
Metrics are at best guidelines to help ground subjective observations. They all have huge gaping holes and if you want to plug those you’ll spend more time measuring than working. The best guide of if you are doing ok is how good other people think you are doing. Does the PO think you deliver fast enough given the complexity, do you help out other devs when possible, do other devs respect the quality of your work?
The best Software Designers have much lower rates of “surprises” in Production (i.e. stuff is put in production and only then people figure out something is missing, is not quite doing what’s necessary or worse).
Doing analysis upfront does help with doing the right code from the start (or close to it) rather than often going down directions that turn out not to work well and having to go back, AND it also helps with doing the right software design from the start (say, figuring out that you need a certain kind fast access persistent data stored hence need to structure the design taking it into account that you’ll have database access), AND it also helps with implementing the right Requirements with the right features (say, have the full details to integrate with other systems or how figuring out that “static” data elements are actually something that does change at sometimes, at an “admin” level rather than during normal use at a “user” level, so the whole thing needs some kind of admin layer).
This kind of stuff gets reflected in a more broader “customer” (internal or external) satisfaction of the “this software/software-changes usually do what we need straight out of the box and we don’t need to go back and forth to get it right” kind, which is even harder to measure and takes time.
First, I never said I was in programming. Second, the topic was that there is no way to track productivity, which is just wrong. May not be 100% accurate, but it can be tracked.
That all sounds like a deeply mismanaged process.
Also it’s such a “junior” level of understanding the process it’s downright cringeworthy.
What you describe is measuring work going in rather than results coming out, when it’s the latter that matters and you actually want to minimize the ratio of the former to the latter (it’s literally the definition of “efficiency”), not maximize it - some of the most effective and advanced software development involves lots of time of what looks like “sitting on your hands” (i.e. analysing the problem) so that a correct and complete result can be delivered directly and without wasting time because “unexpected” things were found, often with less time spent coding than analysing (in management speak: you spend time turning your known unknowns into known knowns so that you can address them upfront instead of wasting time of multiple people later (or worse) due to “unforseen” gaps and problems in the software.
It’s a massive sign that management hasn’t got a fking clue what they’re doing when, in IT they’re engaging in the whole “tracking hours going in” rigmarole, because that actually measuring and ultimatelly rewarding the very opposite of what is good for the company - unless we’re talking about an IT Consultancy, that company’s (or that division within the company’s) product is not lots of well tracked hours worked, it’s software that correctly serves internal or external customer needs, it’s problems solved, it’s good integrations that are completed and delivered in a timelly fashion without the stupid ping-pong between teams as they found “stuff we forgot about” because they didn’t spend time analysing it upfront since they were being measured in “coding hours” (or are too junior to know the value of it or never worked in an effective IT environment).
In IT measuring time-in does nothing to help deliver good results: generally it just incentivises rushed coding that produces little more than constant fires and hence constant firefighting (which, and this is the most hilarious part, then gets measured as hours spent working hence a good thing)
And this is is just the time static stuff. Then there’s all about preparimg for tomorrow whilst you’re doing for today (i.e. maintenability and extendability considerations) which are how you can keep productivity high as the codebase grows, an outcome which is not only not even dectable by simply measuring “hours in”, and requires a time investment which is actually punished when all that is measured is “hours in” because it looks like time waste.
I’m sorry but you’re probably working under a management team that has no clue about software development processes and, worse, you’re celebrating as a great thing the visible artifacts of management incompetence.
I’m a senior dev. This is exactly it.
Metrics are at best guidelines to help ground subjective observations. They all have huge gaping holes and if you want to plug those you’ll spend more time measuring than working. The best guide of if you are doing ok is how good other people think you are doing. Does the PO think you deliver fast enough given the complexity, do you help out other devs when possible, do other devs respect the quality of your work?
Even then, the measuring should be multilayered.
The best Software Designers have much lower rates of “surprises” in Production (i.e. stuff is put in production and only then people figure out something is missing, is not quite doing what’s necessary or worse).
Doing analysis upfront does help with doing the right code from the start (or close to it) rather than often going down directions that turn out not to work well and having to go back, AND it also helps with doing the right software design from the start (say, figuring out that you need a certain kind fast access persistent data stored hence need to structure the design taking it into account that you’ll have database access), AND it also helps with implementing the right Requirements with the right features (say, have the full details to integrate with other systems or how figuring out that “static” data elements are actually something that does change at sometimes, at an “admin” level rather than during normal use at a “user” level, so the whole thing needs some kind of admin layer).
This kind of stuff gets reflected in a more broader “customer” (internal or external) satisfaction of the “this software/software-changes usually do what we need straight out of the box and we don’t need to go back and forth to get it right” kind, which is even harder to measure and takes time.
First, I never said I was in programming. Second, the topic was that there is no way to track productivity, which is just wrong. May not be 100% accurate, but it can be tracked.