4 ms·

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 us

by zzalpha 11y ago

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...

ciaranm 11y ago
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.
- zzalpha 11y ago
  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?
  - ciaranm 11y ago
    Fair! He does mention improved throughput and responsiveness, but I don't see what metrics they're using for that.
lordnacho 11y ago
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.
arcticbull 11y ago
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 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.
- ryanmarsh 11y ago
  A million LOC is a lot of work to create. Any chance you were exaggerating?
shoover 11y ago
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.
collyw 11y ago
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.

by zzalpha 11y ago

ciaranm 11y ago

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.

zzalpha 11y ago
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?
- ciaranm 11y ago
  Fair! He does mention improved throughput and responsiveness, but I don't see what metrics they're using for that.

lordnacho 11y ago

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.

arcticbull 11y ago

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 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.

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

shoover 11y ago

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.

collyw 11y ago

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.