Was this the original TPS report?
-2000 Lines of Code (2007)
151–160 of 222 posts
Re: -2000 Lines of Code (2007)
#152Earlier quoted context omitted.
"Our job is to solve problems, not to write code." My job is what my employers pays me to do. If my employer agrees with that sentiment then it is. If I'm volunteering on open source, I can do my best, but if my employers rewards lines of code, then I produce LOC. Of course, picking a better employer factors in there somewhere.
Wait, does anyone _actually_ reward lines of code today, in this future year of 2024? Like, I remember people joking 20 years ago about how it was the sort of thing companies like IBM used to do in the 80s.
Lots of people joke about it, but lots of bosses still look at it. When your boss treats the most prolific coders as the best, it sends a message.
Re: -2000 Lines of Code (2007)
#153Counting lines of code as a production metric is very stupid. I remember solving an unsolvable 20 years old bug with a line of code, another 3 years old with a order by. How to measure the impact of a line of code? And in my experience, bad programmers write a lot more code... I will never forget the story[1] of a Microsoft developer rewriting a piece of IBM code that had 33 thousand characters, after rewrite ... 220…
As your examples indicate, one reason it's a bad production metric is that it's a reasonable measure of the burden carried by the maintainers of the codebase. The production metric point of view classifies code as an asset. It's closer to the truth to view the functionality as an asset, and the code itself as a liability.
Re: -2000 Lines of Code (2007)
#154Earlier quoted context omitted.
What specific needs are met by daily status updates? Professionals outside of software don't do that. The best software projects don't do that. It's very popular in CRUD projects led by non-technical middle management with trust issues.
> Professionals outside of software don't do that. How do you know this? Have you done an exhaustive search? For one example, are you quite certain that no part of any military ever does this? What about every factory?
You are not answering my question. No, you ask your acquaintances who work in law, finance or medicine. Neither does academia have any "stand up". What specific needs do CRUD software projects have that are met by infantilizing daily status reports? What needs for daily status reports do these projects have that the Linux kernel doesn't?
Re: -2000 Lines of Code (2007)
#155Counting lines of code as a production metric is very stupid. I remember solving an unsolvable 20 years old bug with a line of code, another 3 years old with a order by. How to measure the impact of a line of code? And in my experience, bad programmers write a lot more code... I will never forget the story[1] of a Microsoft developer rewriting a piece of IBM code that had 33 thousand characters, after rewrite ... 220…
I’m sure there are engineers who fix a critical bug every few months and generate millions of dollars of value, but as a general rule great engineers tend to be prolific and engineers who aren’t prolific tend to not be great.
Re: -2000 Lines of Code (2007)
#156> they stopped asking Bill to fill out the form which is only possible because he's so important. imagine doing this as a stack-ranked IC in an org like AWS. The old days of a software as an artisanal craft is long over imho.
AWS has 136,000 employees. Of course they're mired in management and processes.
Simply work for a smaller company..
Re: -2000 Lines of Code (2007)
#157There is a deeper lesson here: Someone was thinking of lines of code as an asset, not a cost. It's a an error you also see in junior programmers writing reams and reams of code. The lesson is a harsh one for us code lovers, at least it was for me: Code is a means to an end, and an expensive one at that. The best code is the code never written. Our job is to solve problems, not to write code. You can use LOC as a crud…
"Our job is to solve problems, not to write code." My job is what my employers pays me to do. If my employer agrees with that sentiment then it is. If I'm volunteering on open source, I can do my best, but if my employers rewards lines of code, then I produce LOC. Of course, picking a better employer factors in there somewhere.
Sucks doing something you know is a waste. I value my time and personal growth more than my employer does.
Re: -2000 Lines of Code (2007)
#158Earlier quoted context omitted.
Cargo-culting someone else's process is a bad way to develop good process for your specific team and its needs. You could use the same logic to claim that "issues and PRs are not useful" because the Linux devs use a mailing list and patches. I think that's obviously absurd, all that this example shows is that a mailing list and patches can be a useful way to develop programs. It says nothing about alternatives at all…
What specific needs are met by daily status updates? Professionals outside of software don't do that. The best software projects don't do that. It's very popular in CRUD projects led by non-technical middle management with trust issues.
> What specific needs are met by daily status updates?
You are assuming (1) that standups are status updates, and (2) that they are scheduled by manager, and (3) for benefit of the manager.
In the last several teams I’ve managed, it’s the crew that has encouraged meeting daily, and in the standups they are mainly talking to each other. It’s where they cover hot topics and bugs for the day quickly, with the fluidity of spoken conversation instead of Slack, and also there’s a non-zero amount of friendly casual conversation.
Don’t force teams to have standups, but also don’t assume a team won’t like it.
Re: -2000 Lines of Code (2007)
#159Earlier quoted context omitted.
Not just IBM. A few years back I worked on a large project with one of the big international consulting companies as the prime contractor. They threw a party for the whole team when the codebase hit one million lines of code. Those of us who knew better treated the "celebration" as a wake.
It's terrifying working around fintec and seeing how many 20MLOC monoliths are laying around and the code quality issues that crop up in them.
This is cope. those applications are there because they work. Mistakes in "20M LOC monoliths" are exceedingly rare in the financial world. Look how bad "hipster" software is in comparison! Billions in profit means billions in quality
Re: -2000 Lines of Code (2007)
#160For all the people dismissing lines of code as a metric, I want to point out that very early on a line of code was literally a CPU instruction. While there was certainly something to be said for efficiency of your subroutine, lines of code was not a totally unreasonable measurement of things that your program was doing. Obviously we get removed from that the more we abstract and well constructed code is different fro…
One of those CPU instructions (or one class of them anyway) is called a jump. It allows you to move to a different instruction than the next one, including going backwards. There has always been reusability of already written code in digital computers. LOC was no more or less meaningful when code was written in assembly or machine language than it is today.
It only measures something loosely correlated with progress toward completion and only if you know what done looks like.