Live data from Hacker News

Mythical man month: 10 lines per developer day

blog.ndepend.com

191–200 of 212 posts

Re: Mythical man month: 10 lines per developer day

#191
post #83

Earlier quoted context omitted.

I'm consulting a client right now and their C++ codebase is full of gems of this caliber. I eviscerate every single PR, and tell them what's wrong and why, and then their CTO just merges them into master without changing anything. All the while they pay me for it. Why? Fuck me if I know. They hired me to provide advice. I provide advice, and it's pretty expensive. I _know for a fact_ they will regret merging this shi…

Fear of missing out... 'This code was already worked on and we paid for it... it can't surely be that bad' If you deliver something broken it's better than delivering nothing... you'd be surprised how often we get 'We'll improve it later' compared to 'You didn't deliver anything?'

But it wouldn't even take much effort to fix. It's not like all of it has to be rewritten or anything. And once my contract ends, they're kinda fucked - they don't have, and aren't going to be able to hire, anyone with my C++ and multithreading/concurrency expertise. If I were in their shoes, I'd take my advice like word of God while it's available, and try to learn to write better C++.

Re: Mythical man month: 10 lines per developer day

#192
post #83

Earlier quoted context omitted.

I once opened up a government code base (in C) that lead with this: "void * * * * x;". It took a while to learn that code. Taking time is fine and good managers will support you, so long as you have something to explain what your time is spent on.

I'm consulting a client right now and their C++ codebase is full of gems of this caliber. I eviscerate every single PR, and tell them what's wrong and why, and then their CTO just merges them into master without changing anything. All the while they pay me for it. Why? Fuck me if I know. They hired me to provide advice. I provide advice, and it's pretty expensive. I _know for a fact_ they will regret merging this shi…

Are your reviews more like suggestions of how to do things better, or more like "this sux and here's why"? If any of your criticisms are related to something that a linter or static analyzer could catch, have you tried to get that tooling established in the project?

Re: Mythical man month: 10 lines per developer day

#193
post #99
post #83

Earlier quoted context omitted.

I'm consulting a client right now and their C++ codebase is full of gems of this caliber. I eviscerate every single PR, and tell them what's wrong and why, and then their CTO just merges them into master without changing anything. All the while they pay me for it. Why? Fuck me if I know. They hired me to provide advice. I provide advice, and it's pretty expensive. I _know for a fact_ they will regret merging this shi…

You might be going into conflict/criticism mode, which would make them unresponsive. Being right isn't enough to get people to change. I don't know at all if this is the case, just mentioning it, because you seem to be frustrated by the situation.

I actually asked them if this want me doing this. They said they did. This is only a minor part of what I'm doing for them - my work is mostly on the AI side.

Re: Mythical man month: 10 lines per developer day

#195
post #60
post #40

Earlier quoted context omitted.

When you refactor code you do not deliver value to customers.. You do though, by reducing the future cost of delivering features. That has tremendous value. Find a company that sees good engineering as a long term investment rather than a short term way of extracting money from customers and you'll enjoy software development a lot more.

Again that isn't customer facing value. Users do not care about the costs of your business, I cannot understand how so many developers don't seem to understand the basic premise of b2c relationships. At best it's the proposition of future benefits and those benefits are all to the company not the customer.

> Again that isn't customer facing value.

It absolutely is customer facing value. If shipping this feature 2 weeks later means you can ship the next 10 features in 6 months, and the alternative is shipping this feature today but with so much tech debt that you ship the next 10 features in 12 months, then that is value the customer will see.

Similarly, if your code is so shitty that you're adding bugs to the backlog faster than you're able to fix them, that's a negative for the customer. If instead you spend 2 weeks refactoring so that your bugs+ rate is lower than your bugs- rate, that's customer value right there!

I cannot understand how you don't seem to understand this basic premise of a b2c relationship. Users don't just care about the features they have today, and if your competitor gets to market slower than you but has twice the features a year or two later (due to less tech debt), you're gonna be left in the dust.

Re: Mythical man month: 10 lines per developer day

#196
post #192
post #83

Earlier quoted context omitted.

I'm consulting a client right now and their C++ codebase is full of gems of this caliber. I eviscerate every single PR, and tell them what's wrong and why, and then their CTO just merges them into master without changing anything. All the while they pay me for it. Why? Fuck me if I know. They hired me to provide advice. I provide advice, and it's pretty expensive. I _know for a fact_ they will regret merging this shi…

Are your reviews more like suggestions of how to do things better, or more like "this sux and here's why"? If any of your criticisms are related to something that a linter or static analyzer could catch, have you tried to get that tooling established in the project?

I am, of course, diplomatic. It's more along the lines of "This is not thread safe, if threads A and B call this function at roughly the same time, you will end up dereferencing a null pointer. Here's how to avoid this: ". Tooling would catch some of this, if they were running it, which they aren't. But it would not catch bad design.

Re: Mythical man month: 10 lines per developer day

#197
post #183

My company has been experimenting with doing our feature estimations in LOC changed instead of points (1, 2, 3, 5). The general idea being that point estimation can vary between engineers based on ability, but LOC changed should be similar among engineers. This is supposed to make it easier to answer management's favorite question of "How long is this gonna take?". The answer is calculated using a team's historical a…

I wonder if LOC changed isn't often reversely proportional to time taken. 500 LOC feature: Add a new route that does something boring; 5 story points. 5 LOC feature: Fix mysterious performance degradation in X; 13 story points.

I think for defect estimation you are right, but for feature estimation (new code, not fixing bad code) the correlation is positive.

Re: Mythical man month: 10 lines per developer day

#198

Earlier quoted context omitted.

LOC is a terrible measure for productivity, but I like to think about it more as a measure of capacity. LOC/day is useful as an upper bound in the same way pages per day is an upper bound for authors. Stephen King is notorious for being one of the most prolific writers, and he can’t produce more than 8 publishable pages a day (top hit on google suggests his average may be close to 6). Knowing that the number of LOC/d…

Isaac Asimov, another prolific author, averaged something like 2800 words per day[1] over the most productive period of his career, which works out to about 9 pages, so that seems like a good estimate. 1: Google is giving a much higher number but they all seem to go back to the same estimate which is more hand-wavy than a printed source I found in college when researching it. Sorry I don't have it to source. The othe…

Interesting, I'd never thought to look much at other authors output on this topic. There was a post the other day talking about Jules Verne's corpus, and I now wonder what his output was like.

I've another thought on the topic as well, which is that I have a friend who hired a lot of former newspaper journalists circa 08 when there were mass layoffs in that industry. He said they were able to most consistently churn out content for his book over other writers, but that it was significantly lower quality, and needed a lot more rework and polish. For him the tradeoff was worth it, and he organized his time and resources around this increased quantity. But this adds to the idea that you really can't look at pages/day (or LOC/day) on an individual basis either, since it's the whole pipeline that matters. And if you really want to improve total output, you need to look at variables outside of individual contributors. Things like code reviews and QA can perhaps greatly increase total output.

Re: Mythical man month: 10 lines per developer day

#199

Earlier quoted context omitted.

TransactionScope has been around forever in the .Net Franework version of EF. It just came back to EF Core in 2.1 https://www.google.com/amp/s/codewala.net/2018/05/06/transac...

Yes, this is exactly the type of boilerplate I am talking about. All those usings and try/catch blocks which add needless code. It is possible to compose all of this into an aspect which then decorates your methods. Maybe I'm not being clear, so here is what I mean. Say you have a method that does some work, but calls some other thing to do some auditing. The auditing is nice, but it failing shouldn't halt the world.…

There should only be one using/try catch block on the highest level. All of the methods being called within that using block should just throw errors.

You could put the logic in attributes but I don’t consider a transaction a cross cutting concern. It would create a spooky action at a distance situation.

Re: Mythical man month: 10 lines per developer day

#200

Guys, can I be honest? I have never actually met anyone who has worked in a LOC-optimized company. This stuff seems like the outrage porn of software engineering.

> I have never actually met anyone who has worked in a LOC-optimized company.

Not only that, but the higher-level concept I took away is that, given the size of his features (~6k loc), it takes about 75 days to write a feature. Assuming those are workdays, that's 15 weeks, a little over a quarter. And, indeed, tech companies do seem to measure their process and projections in quarters, and everything tends to slip to the right a bit, on average.

Also, the code coverage numbers line up with other estimates I've seen: life-critical systems should have upwards of 95% code coverage. Standard project: 85-90% coverage.

Post reply on HN