Hacker News Reader

Comment by zzalpha | Hacker News Reader

Do we really care that much about LoC? I understand that more code means more opportunity for bugs, but I'd be far more concerned about performance, battery usage, code quality metrics, etc, not to mention maintainability and codebase stability, access to talent who understand the language/frameworks/idioms, etc.

Don't get me wrong, I'm sure Swift is a big improvement in a lot of ways, but LoC is a weird measure to focus on, IMO... though, I can't say I blame them. LoC is easy to compute. Turns out measuring actually useful things can be rather hard...

View on HN

Yes.

  Here is a list of activities that grow at a more-than-linear rate
  as project size increases:
  - communication
  - planning
  - management
  - requirements development
  - system functional design
  - interface design and specification
  - architecture
  - integration
  - defect removal
  - system testing
  - document production

Code Complete section 27.5. Size in this section is referring to LOC.

Smaller code bases tend to make it easier to find things. Also I find in my old ObjC code there's a lot of lines to do one thing, often related to getting some object and casting it, then running some function on it. The kind of thing that should really be one action.

The bulk of the LOC reductions were elimination of header files, I'm sure, and the fact they wrote something a second time, but knowing what the picture on the box was.

Do I believe Swift is better? Sure.

Do I believe they eliminated some bugs in the original code? Yep.

Do I believe they introduced a whole whack of new bugs they now don't know they have? Most definitely. That's what happens when you re-write software (http://www.joelonsoftware.com/articles/fog0000000069.html).

I've been waiting on writing Swift in production until Apple stops making breaking changes to the syntax. Running a converter over a million line codebase every few months and then checking it in is simply not a good answer. I think we're either there, or very close. That said I'm definitely, super double not rewriting large swaths of code. There's no value there. New stuff? Totally.

A million LOC is a lot of work to create. Any chance you were exaggerating?

I joined a startup recently and the product was over engineered by a huge amount. I think I could have rewritten it in around a tenth of the code. The result makes it far harder for new devs to get up to speed with the application, and bug fixe take far more effort as there is so much more code to read through.

Is about 200/3700 words really 'focusing on' LoC? I didn't really feel like the OP stressed that point too hard. I'd also argue that less code is (generally) more maintainable.

Good point, there's a lot more to the article than that.

Unfortunately, it's the only objective measure offered.

Where are the defect rates? Coverage in unit tests? Time to delivery? User satisfaction measures?

Fair! He does mention improved throughput and responsiveness, but I don't see what metrics they're using for that.

Reply on news.ycombinator.com