Did I miss the Developer Productivity discussion?
-
Uh, yeah, pretty much everyone here agrees with that. But that's just the tip of the iceberg.
Indeed. I had a coworker who had a negative line count. He refactored an old library and got rid of thousands of lines, while maintaining functionality. That was the best thing that had ever happened to that library, which suddenly became a lot more manageable.
-
Indeed. I had a coworker who had a negative line count. He refactored an old library and got rid of thousands of lines, while maintaining functionality. That was the best thing that had ever happened to that library, which suddenly became a lot more manageable.
I had to upgrade an industrial line with a robot. The program of the robot was around 15k lines of code and over 1200 positions. When I ended, my program had a bunch more functionality while being more stable and having not even 2k lines and around 350 positions. The maintenance guy bought me a bottle of wine because I had made his life waaaayyy easier with that changes.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
I've not been on here for a few days, so maybe I missed it. So if this has already run it's course, please ignore. But, anyway, I'll pitch in with my two lines... If a manager can only figure out who the good and bad developers are, by counting lines of code written: He/she shouldn't be a manager.
Or by counting the number of hours worked. Had a manager at a previous job whose "best worker" clocked in 60 - 70 hours a week. The problem was this worker took 60 - 70 hours to complete the same amount of work everyone else completed in 30 hours.
"I reject your reality and substitute my own." -- Adam Savage
-
I've not been on here for a few days, so maybe I missed it. So if this has already run it's course, please ignore. But, anyway, I'll pitch in with my two lines... If a manager can only figure out who the good and bad developers are, by counting lines of code written: He/she shouldn't be a manager.
To be honest, and as a manger... In the beginning, all we had was "Code" and "Needs". As Needs were filled, "Code" was created. But even by the mid-late 1980s NOBODY seriously use LOC of a meaningful amount of work/complexity. My first job tracked "Change Requests" completed. And for us, that meant from assignment, to coding, testing, validating, having the customer/client sign-off, modifying the documentation, having the Operations Staff sign-off and potentially the user Managers sign-off that the documentation was complete. In some cases, the "Systems and Specifications" Manual was updated, and the Flowcharts, and other diagrams updated... [There was a pretty big checklist, (Does this Apply: Y/N completed Y/N)] Given those details. The ABSOLUTE insanity of measuring LOC as EFFORT was terrible. We simply took to measuring how many CRs (Change Requests) each developer completed. Which, too, was not fair. Some things were as MINOR as "Bold this text ON this condition". And others were, change the intrinsic calculation of Insurance Premiums for vehicles over $x and below $y between 0 and 3 yrs old. Then some CRs had like 15 user requests (all related) merged into one. The point was that measuring SOMETHING gave you an idea. FWIW, the LEAST productive programmer was the ONLY ONE with a degree, and he had a Masters. I was 19, and I learned so much from that environment (like there is more to coding than CODE, and SUNK COSTS apply to fixing a horrible program that should be rewritten)
-
I remember reading in Dr. Dobbs about 20/25 years ago that there was a manager who used a tool that would count semicolons to determine number of lines. This information got leaked to some junior programmers who then started writing lines as -
;;;;;;;;;;;;;;;;;;;;;;;;;;;;
And thus is revealed a great problem :-) No matter what you do to try and leverage a metric out of what we do as software developers, there will ALWAYS be someone who figures out how to game the system.
-
Or by counting the number of hours worked. Had a manager at a previous job whose "best worker" clocked in 60 - 70 hours a week. The problem was this worker took 60 - 70 hours to complete the same amount of work everyone else completed in 30 hours.
"I reject your reality and substitute my own." -- Adam Savage
Upvote is for the Tag line ;-)
-
To be honest, and as a manger... In the beginning, all we had was "Code" and "Needs". As Needs were filled, "Code" was created. But even by the mid-late 1980s NOBODY seriously use LOC of a meaningful amount of work/complexity. My first job tracked "Change Requests" completed. And for us, that meant from assignment, to coding, testing, validating, having the customer/client sign-off, modifying the documentation, having the Operations Staff sign-off and potentially the user Managers sign-off that the documentation was complete. In some cases, the "Systems and Specifications" Manual was updated, and the Flowcharts, and other diagrams updated... [There was a pretty big checklist, (Does this Apply: Y/N completed Y/N)] Given those details. The ABSOLUTE insanity of measuring LOC as EFFORT was terrible. We simply took to measuring how many CRs (Change Requests) each developer completed. Which, too, was not fair. Some things were as MINOR as "Bold this text ON this condition". And others were, change the intrinsic calculation of Insurance Premiums for vehicles over $x and below $y between 0 and 3 yrs old. Then some CRs had like 15 user requests (all related) merged into one. The point was that measuring SOMETHING gave you an idea. FWIW, the LEAST productive programmer was the ONLY ONE with a degree, and he had a Masters. I was 19, and I learned so much from that environment (like there is more to coding than CODE, and SUNK COSTS apply to fixing a horrible program that should be rewritten)
During my reign working in the mobile comms industry here in the UK, we had a massive problem with that. Some faults would always be simpler than others, and we had a daily target of "reported issues" to deal with. Once the management figured out however that we were only keeping our targets by literally picking off the easy ones, and leaving the hard ones, that practice stopped, and the shift leaders where tasked with giving each team member a cross section from the "in queue" each day, some of which were easy tasks, some of which were hard. The next big complaint from management was then "why can't folks complete the assigned x tasks per day?" To those not down on the floor, every task to them was a line on a spread sheet, and every line on the sheet had and arbitrary time assigned to it based on what management thought the issue & resolution was.
-
To be honest, and as a manger... In the beginning, all we had was "Code" and "Needs". As Needs were filled, "Code" was created. But even by the mid-late 1980s NOBODY seriously use LOC of a meaningful amount of work/complexity. My first job tracked "Change Requests" completed. And for us, that meant from assignment, to coding, testing, validating, having the customer/client sign-off, modifying the documentation, having the Operations Staff sign-off and potentially the user Managers sign-off that the documentation was complete. In some cases, the "Systems and Specifications" Manual was updated, and the Flowcharts, and other diagrams updated... [There was a pretty big checklist, (Does this Apply: Y/N completed Y/N)] Given those details. The ABSOLUTE insanity of measuring LOC as EFFORT was terrible. We simply took to measuring how many CRs (Change Requests) each developer completed. Which, too, was not fair. Some things were as MINOR as "Bold this text ON this condition". And others were, change the intrinsic calculation of Insurance Premiums for vehicles over $x and below $y between 0 and 3 yrs old. Then some CRs had like 15 user requests (all related) merged into one. The point was that measuring SOMETHING gave you an idea. FWIW, the LEAST productive programmer was the ONLY ONE with a degree, and he had a Masters. I was 19, and I learned so much from that environment (like there is more to coding than CODE, and SUNK COSTS apply to fixing a horrible program that should be rewritten)
"I'm gonna write me a mini-van!" -- Wally Change Request 1: Implement Feature X. Change Request 2: Fix the bug in Feature X. Change Request 3: Improve the performance of Feature X. Change Request 4: Fix the bug in Feature X. etc.
-
"I'm gonna write me a mini-van!" -- Wally Change Request 1: Implement Feature X. Change Request 2: Fix the bug in Feature X. Change Request 3: Improve the performance of Feature X. Change Request 4: Fix the bug in Feature X. etc.
Ah, but we TRACKED those... If it was a REQUEST that came back... That was VERY VERY BAD. (One programmer made a calculation error, and cost the company like $30,000 in penalties!) So, those are: Change Request 1: ... FIX Request 1a: ... With Sitdown with manager... FIX Request 1b: ... Client complains it's too slow... (Employee writeup begins, record in permanent file) FIX Request 1c: ... New EMPLOYEE Assigned to the problem. Honestly, we rarely made it passed a... If EVER. And WE were always more concerned about performance then the client. In fact. I rewrote a piece of code, and took it from 5-7 SECONDS to < 1 second... It was so fast, that I GOT IN TROUBLE because NOBODY thought it actually worked, and were complaining to their manager (they were not reading the screen, it was clear it worked. But there is NO WAY it could be that fast. LOL)...
-
Ah, but we TRACKED those... If it was a REQUEST that came back... That was VERY VERY BAD. (One programmer made a calculation error, and cost the company like $30,000 in penalties!) So, those are: Change Request 1: ... FIX Request 1a: ... With Sitdown with manager... FIX Request 1b: ... Client complains it's too slow... (Employee writeup begins, record in permanent file) FIX Request 1c: ... New EMPLOYEE Assigned to the problem. Honestly, we rarely made it passed a... If EVER. And WE were always more concerned about performance then the client. In fact. I rewrote a piece of code, and took it from 5-7 SECONDS to < 1 second... It was so fast, that I GOT IN TROUBLE because NOBODY thought it actually worked, and were complaining to their manager (they were not reading the screen, it was clear it worked. But there is NO WAY it could be that fast. LOL)...
-
During my reign working in the mobile comms industry here in the UK, we had a massive problem with that. Some faults would always be simpler than others, and we had a daily target of "reported issues" to deal with. Once the management figured out however that we were only keeping our targets by literally picking off the easy ones, and leaving the hard ones, that practice stopped, and the shift leaders where tasked with giving each team member a cross section from the "in queue" each day, some of which were easy tasks, some of which were hard. The next big complaint from management was then "why can't folks complete the assigned x tasks per day?" To those not down on the floor, every task to them was a line on a spread sheet, and every line on the sheet had and arbitrary time assigned to it based on what management thought the issue & resolution was.
Wow, yeah, I've been in those environments (luckily not for long). We had a situation where for 2-3 months, I literally had 80% of a 3 person teams productivity. (One guy was useless), I was pounding UNPAID overtime in. Amazing what an extra GOOD hour adds up to, each week. Then the owner sat us down, was needing an estimate on man-hours to bring a new business online... We gave him the number... Like 800 man-days (excluding our current work getting done). He looked around the table, and and saw 5 people (3 Devs, 2 managers) and said so if we bring in 3 more people, we can have this in 100 days... (as if 100 days was 100 work days, as IF managers were programmers, as IF new developers would be useful...) I stood up and said. Come to think of it. If you hired 100 people, you could have it in about a week! Problem solved. And I walked out of the meeting. Went back to work. My manager called me in his office and said "You know that meeting wasn't over?"... "For me, it was!" I replied. That level of AI (Arrogance + Ignorance) should not be tolerated! ==> For the estimates. I usually push back with: How much is this worth in Developer Hours? At which number of Hours should we NOT do this? THEN I ask them what their estimate is (it's useless, but I can usually point out... Any change to the system requires like 4hrs, just to get it through testing and published, updating docs, scheduling downtime. And that's to change the VERSION #... LOL). Most of the time, they are just not educated as to how hard it is to do our jobs. They have no idea what we do.
-
A great manager uses metrics to highlight the great work his/her team is doing, a poor manager uses metrics like a slave master to try and protect his/her position.
Absolutely. My claim to fame as a manager is that 90% of the developers that worked for me in the past, would work for me again! I have 3 reporting to me on my team. 2 Have been with me over 20 years. The "new" guy has been with me for like 14 years! Treat people well and with respect... And they tend to appreciate it!
-
To be honest, and as a manger... In the beginning, all we had was "Code" and "Needs". As Needs were filled, "Code" was created. But even by the mid-late 1980s NOBODY seriously use LOC of a meaningful amount of work/complexity. My first job tracked "Change Requests" completed. And for us, that meant from assignment, to coding, testing, validating, having the customer/client sign-off, modifying the documentation, having the Operations Staff sign-off and potentially the user Managers sign-off that the documentation was complete. In some cases, the "Systems and Specifications" Manual was updated, and the Flowcharts, and other diagrams updated... [There was a pretty big checklist, (Does this Apply: Y/N completed Y/N)] Given those details. The ABSOLUTE insanity of measuring LOC as EFFORT was terrible. We simply took to measuring how many CRs (Change Requests) each developer completed. Which, too, was not fair. Some things were as MINOR as "Bold this text ON this condition". And others were, change the intrinsic calculation of Insurance Premiums for vehicles over $x and below $y between 0 and 3 yrs old. Then some CRs had like 15 user requests (all related) merged into one. The point was that measuring SOMETHING gave you an idea. FWIW, the LEAST productive programmer was the ONLY ONE with a degree, and he had a Masters. I was 19, and I learned so much from that environment (like there is more to coding than CODE, and SUNK COSTS apply to fixing a horrible program that should be rewritten)
I worked quite hard throughout my career to get bad managers fired... I had over a 90% kill-rate...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com