8 ms·

What annoys me most about these metrics is that some days zero lines are written. Anything up to a month without results to show. Where, then, does all this ti

• Bnshsysjab 7y ago
  At one job, I replaced a 10k LOC class with a 20 line function which probably took me to a net negative loc count for that job.
  • tomcam 7y ago
    I would love to hear more details on this one
    • erikerikson 7y ago
      Not the GP but... Reduce a cross cutting concern from a system into an aspect and you get this easily. I once worked on a product and identified an ability to eliminate 100K lines of poorly written, inconsistent tracing code into a robust ~250 line file using AspectJ. Management threw a sh-t fit and thought the risk was untenable.
      • croon 7y ago
        The risk of the new one or the risk of keeping the old 100K lines? Half serious question since I would estimate the risk of the latter to be much larger.
        • gmueckl 7y ago
          To me it sounds like he was introducing a hard dependency on AspectJ, which is as much a risk as any other dependency. I am guessing here, bit it is a scenario where a hissy fit from management has at least some justification.
          • scarface74 7y ago
            How is a dependency on AspectJ any more of a liability than the dozens of other external dependencies in your typical application?
            • gmueckl 7y ago
              It is just as much of a liability, a priori neither more nor less. It needs to be evaluated like any other potential new dependency. Plus, AspectJ is something that you have to be careful with. It injects code at the start or end of methods that can do arbitraty things and the method source code doesn't indicate that this is happening. So it has a great potential for code obfuscation.
              • scarface74 7y ago
                Sort of unrelated rant. Maybe it’s because I’m not as well versed in Java idioms as I am with C# idioms, but using code that implements AOP using AspectJ seems much more obtuse than what I’ve done in C# just looking at the examples. In C#, with the various frameworks - including on the API level with ASP.Net - you can use attributes to decorate the classes/methods with your aspects and it’s pretty easy to see what it’s doing. You get the runtime binding basically by just using dependency injection as you always do.
                • logicalmind 7y ago
                  C# dev here as well, but from a Java background. When I first moved to C# from Java one of the best AOP usages was transaction management. Database transaction management. You could write all of the code, whether it was dependent upon the db or not, and then decorate the methods with a transaction attribute. This decoration contained all the logic to get a db connection, begin a transaction, become part of an existing one, or create a new isolated one. Any unhandled exception caused the final unwinding to rollback any work that had been done in that transaction. So many try/catch/finally's avoided and so much boilerplate code. I have yet to find any equivalent to this .NET world. Especially of you're using EF. Either you use ADO and have your try/catch/finally with manual transaction management, or you have the EF context which is just one big blob you hope succeeds at the end.
      • barrkel 7y ago
        AOP tools that effectively rewrite the app have incredible amounts of leverage. That can work to your benefit but it's also an enormous footgun if you get your aim wrong. It leverages up both cleverness and stupidity.
    • winrid 7y ago
      Not OP but also replaced a class. Very early in my career, I think I was 20, we were upgrading our Thrift version in a PHP/Java stack. For some reason all calls were dog slow. Like minutes for simple pages. Profiling revealed the class in question - and we were spending all our time in deserializing strings. Copied the latest version of that class from the FB repo and luckily the interfaces were the same. Worked for the next two years until we finally deprecated the PHP stuff.
    • Bnshsysjab 7y ago
      It was a C# file for an API that wrapped thousands of reports with a function call for each report, I moved to a design which was a single function for all reports. I think what had happened is somebody had designed the file and everybody else followed suit patching stuff on - the entire codebase for that app was well below average. they had front end devs who didn’t know any JavaScript. In 2016. I lasted 6 months before I nope.png’d the fuck out. It’s still not the worst application I’ve ever worked on though
      • adrianN 7y ago
        Now it's 9980 lines less bad though :)
    • hindsightbias 7y ago
      Not the parent, but I once inherited a bunch of tools that used the same tracing function. Akin to dtrace. 6 people wrote 6 tools over different domains all with their own post-processing, filtering, formatting, etc... It was a support nightmare, so we built a common library and collapsed the code base by 70%. Each tool was probably in the -8k eslocs range. Thankfully it wasnt c++.
  • deleted 7y ago
    [deleted]
  • mtrycz2 7y ago
    Everytime I read posts like this is like if people are arguing about the tiny details of the small picture, and it makes me sad. Expecially because the big picture is easily stated: Write the least amount of clean code while providing value. (PS: code is liability)
    • barrkel 7y ago
      Code is both asset and liability; the asset is the feature set, while the liability has an interest payment in the form of maintenance. The way you put it, you're optimizing for only one side of the books. The fact is that the value in a company is not in minimal clean code; it's in a recurring revenue stream, and ideally profits. Provide the most value with code which has low interest payments. Everything else being equal, smaller code has lower interest payments, but everything else isn't always equal. And depending on cash flow and market opportunity, maximizing value and to hell with minimal clean code - throwing money & devs at the problem - can make sense.
      • MathCodeLove 7y ago
        The distinction here is between code thats clear and concise or code that hacky and confusingly compact. Few people would recommend try and pack a 4-5 line function into a super complex and confusing one liner, but it is reasonable to put a 10k line class into a 20 line function. It's on us, as the developers, to make that tradeoff. I think the spirit of the comment you replied to was closer to the "clear and concise" methodology rather than the "as short as is humanly possible" methodology.
        • tigershark 7y ago
          Only the few people that don’t know anything about the map function or generator expressions and prefer messy imperative code where off by one errors are a given, if you want my opinion..
  • makeset 7y ago
    At one job (porting a colossal legacy UI to Windows), I deleted thousands of LOC every day for months. Coworkers called me "the decoder." 25 years later I'm probably still net negative.
  • gitgud 7y ago
    Less code less problems... However in many cases, code is for; edge cases, input sanitization, type checking, null checking, graceful failure, logging... etc Remember, [1] Docker can be implemented in a 100 LOC bash script, that doesn't mean it's a good implementation... [1] https://news.ycombinator.com/item?id=9925896 https://news.ycombinator.com/item?id=9925896
  • whatshisface 7y ago
    This issue can easily be fixed by switching from delta LOC to the size of the git diff (number of lines changed). The big problem with this strategy is the huge difference between 10 lines of carefully engineered algorithm code and 10,000 lines of blah API calls and boilerplate. I can write API calls and boilerplate as fast as I can type.
    • chx 7y ago
      > I can write API calls and boilerplate as fast as I can type. I can write boilerplate much much faster than I can type, either I or the community have scripted that shit :D
      • whatshisface 7y ago
        I'm sure any shop that counted diff lines would ban editor boilerplate macros due to them being cheating. ;)
  • downerending 7y ago
    At one job, I wrote a moderately complicated Makefile (~200 lines) to build the company's product. Worked great. After I left, I heard the company 10x programmer replaced it with 10KLOC of C++. (sigh)
• Antoninus 7y ago
  Some of my favourite days on the job is when you remove lines of code. Does that metric go against LOC/written?
  • ignoramous 7y ago
    Reminds me of https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li... I once had a senior manager who insisted that developers made at least one commit a day (an internal GitHub like tool gamified this: number of lines committed since last month / top committers in the team etc), and those that didn't, had to up their game. It was frustrating to say the least as this was not the only metric. There were a handful and, frankly, many made a mockery of it by doing just as much or less work than before but achieving or even surpassing the said metrics.
    • technion 7y ago
      It's quite normal for it helpdesk teams doing all the users password reset tickets to "outperform" the teams fixing server issues based on "tickets closed" metrics
    • TeMPOraL 7y ago
      At my last Java job, whenever there was a day I didn't have much or any code to commit (e.g. I was in the middle of going through compsci papers about a nontrivial algorithm I intended to implement), I would open up the IntelliJ's "code inspections" tab. It provided me with a never-ending stream of quick and small fixes to make that not only amounted to a commit, but also occasionally fixed an actual (if not likely) bug.
    • Cthulhu_ 7y ago
      Goodhart's Law in action: "When a measure becomes a target, it ceases to be a good measure"
    • davidrm 7y ago
      What was the turnover rate at that place? This would have me quit within a week.
• spurdoman77 7y ago
  For me the time often goes on 4chan
• agumonkey 7y ago
  Whenever I spend a week without progress I feel like dying. In college I was used to be able to churn immense amount of code. Even if most of it was useless, I'm not well adjusted for long productive-less periods. How did your manager react to these times ? no remarks ? nagging ? trusting ?
  • xchaotic 7y ago
    Then grow up? Producing huge amounts of useless code is not good for you or anyone else???
    • agumonkey 7y ago
      off topic much
    • kickling 7y ago
      Could be relevant for learning purposes.
  • gmueckl 7y ago
    Progress is measured in more things than code written. Define progress using the right metric, i.e. stuff learned, and the feeling of progress and your motivation can be preserved. For me, it is really a top down approach. I can work on goals that take years to accomplish. But the key is to break them down into smaller and smaller bits until you have work items that show progress on a small enough scale to be easily observable. And part of this is sometimes research, so I can't measure myself in terms of code or features. But each task usually has a way to define progress.
    • agumonkey 7y ago
      Good point. I do agree with you vastly. But in my few work experience it was never discussed nor shown. Which led .. well lack of leadership. And ultimately deep anxiety. Do most jobs have a team chat to talk about it before going into actual work ?
• Spooky23 7y ago
  That’s fundamentally a lack of respect for the engineering aspect of software systems and a sort of self-loathing embraced by people in the field. Many software roles require what I would call Home Depot skill levels. People at Home Depot take semi-finished materials in a kit and fix their toilet, without understanding how it works. Likewise, some journeyman skilled developer and “code” a sign in page with an API without understanding the engineering process around OAuth. The problem is many business people don’t understand anything beyond the Home Depot kit... they see stuff on the shelf and don’t understand that at some level that engineering side of the work needs to be done to create something novel. Reinforcing that notion are vendors hawking products.
  • i_haz_rabies 7y ago
    As someone with Home Depot skills, I 100% agree. I really wish that there was a common distinction. I am not the right person to solve a novel or complex engineering problem. I am the right person to build a product that won't require solving a novel or complex engineering problem. I probably shouldn't be paid like the former, nor should I have to have the qualifications of the former to land a job for the latter.
    • dasil003 7y ago
      I think there’s a further subdivision of “hard” which is the fundamental research stuff that pushes the boundaries of CS. Then there’s business problem stuff that’s hard because of scale, surface area and general messiness of the real world. Although the IC salary peaks might not be as high, there is more money overall in the latter, and it’s not as much about raw intellect as it is about moving up and down the abstraction layers, thinking things through and translating technical trade offs to laymen.
  • JeremyNT 7y ago
    I'm another mostly "Home Depot" coder and can glue all kinds of things together without really having to dig deeper. Maybe I could go deeper if I needed to, but that's not what my job demands or requests of me, and what they need is the Home Depot code that bolts all their existing systems together. I think those of us in roles like this can actually bang out a lot more LOC than somebody working on lower level problems, because we aren't solving hard problems, we're using basic data structures and tossing them between (usually/hopefully) well documented interfaces. If that's the case, LOC is just about the worst metric you could imagine.
• deleted 7y ago
  [deleted]
• HillRat 7y ago
  Fundamentally, that’s why SLOC can be useful as an estimating metric, but terrible as a control metric. SLOC, FP and so on all have their limitations, but they demonstrate that most of the effort-time in a project doesn’t go into putting hands on keyboard. Conversely, trying to monitor developer productivity with SLOC simply reintroduces the conceptual error that the estimation effort attempts to prevent.
  • skore 7y ago
    Goodhart's law - "When a measure becomes a target, it ceases to be a good measure." I used to work for a company that bills their customers for dev hours spent. The software they put together worked fabulously well - in the production of billable dev hours.
• rstuart4133 7y ago
  All metrics can be horrible. To take an obvious example, we used to repeatedly see the temperature on one cold day being quoted as proof that global warming wasn't happening. So clearly the temperature must be a horrible metric for global warming, right? It is of course the main metric for global warming, but it can be used badly or very well. Just like Lines of Code, it's hard to even get the measurement right. Do you measure it in the sun, or the shade? Do you measure it in a city which is relevant to the where most people feel the effects, or in the country so you get a repeatable environment. Similarly does LOC include comments and blank lines, what about patches - how do you count them? In terms of LOC per day, so you measure a single person who is churning out the code, or the entire team including the designers and documenters, and do you include the time after the project is completed doing support because of bugs? I don't think you can blame the "temperature metric" for the bad ways it's measured or used. And I don't think you can blame Lines Of Code all of it's bad outcomes either.