191–200 of 522 posts
Earlier quoted context omitted.
They PHB should put extra bonuses on kLOC, like 1k$ per 1kLOC, and watch the codebase increase exponentially and since documentation is better than code, double the amount for line of comments.
That's a literal Dilbert strip, 1998-ish, IIRC.
I recall a story about someone at a government contractor who did a major refactoring and removed thousands of lines of code from a project, increasing its performance, only to be told by management that they'd signed a contract that said the company got paid by lines of code delivered, and his improvement would cost them tens of thousands of dollars, so revert the whole thing.
As long as we are counting LOC before compiling, that can be solved easily: if (false) { /* original code stays here, as we are payed by LOC */ } else { /* write your new code here */ }
Get 80k commits in, before lunch.
A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…
A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…
In software we can put a few shapes on a screen in just the right context and people will believe there's an operation as sophisticated as the wite-out bottle factory behind it.
Earlier quoted context omitted.
That’s true. And I guess depending on the job/manager you could replace lines of code with “user-visible changes to app”, etc.
That'll be exploited as well. The number of pointless UI and feature changes would skyrocket without the app actually getting better or gaining meaningful functionality. Meta-metrics might be much more helpful, though harder to come up with, quantify and monitor. Things like defect rates, user reported incidents, user satisfaction, stuff like that. Things that cannot easily be gamed from within the development proces…
Do people actually have fights like this with management at their companies? Not trying to knock the author, but I'm just surprised anyone would actually hear this kind of comment in 2020. I'd think by now any and all metrics tying lines of code to productivity would be long dead.
They don't always make the comment out loud, but you can tell they're thinking it. They absolutely use lines of code metric at my company. I don't miss any chance to tell my manager it's complete bullshit. His answer: "Engineers are supposed to write code, just like construction workers are supposed to build houses."
Earlier quoted context omitted.
1. Being in a position where you have the privilege of being able to pick a good manager is important :)
I remember hearing somewhere that the reason n.1 people leave their job was their manager. Don't know if that's true but the idea's there. So it makes sense that your manager should be a major decision criteria when you pick a job (being able to actually pick a job is also a privilege, but it's fairly common in SWE)
Earlier quoted context omitted.
They don't always make the comment out loud, but you can tell they're thinking it. They absolutely use lines of code metric at my company. I don't miss any chance to tell my manager it's complete bullshit. His answer: "Engineers are supposed to write code, just like construction workers are supposed to build houses."
Oof, that's a false equivalence. Construction workers have blueprints for how things are supposed to be built. You're (generally) making the blueprint as you go along, based on vague specifications in many cases. This can depend a lot on how your organization designs software, of course.
And I can assure you, they were not judged on the number of views or pages on their drawing, or on the number of variables in their structural calculations.
A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…