Having an intern write a good blog post for the engineering blog is a great recruiting move.
Undebt: How We Refactored 3M Lines of Code
31–40 of 143 posts
Re: Undebt: How We Refactored 3M Lines of Code
#32Why pyparsing, not ply or regex?
regexps are error prone better use ASTs see Facebook's jscodeshift
Re: Undebt: How We Refactored 3M Lines of Code
#33How do web applications explode out to 3 Million lines of code? Yelp, to me, looks like a typical CRUD app and I would have been surprised if it were more than 100,000 lines of code. The software I develop is pretty large and typically doesn't surpass 40,000 sloc written in-house (i.e. excluding third party libs). Does anyone here maintain such large codebases? Are they truly that big or are people just counting thir…
Is the 3M across all applications they developed? That may be much more than just the customer facing part. Plus like others have said, it's also years of development; I've heard a lot of stories that a lot of the high-profile companies and applications (paypal, ebay, linkedin, skype, etc) have huge and rather bad codebases.
Re: Undebt: How We Refactored 3M Lines of Code
#34How do web applications explode out to 3 Million lines of code? Yelp, to me, looks like a typical CRUD app and I would have been surprised if it were more than 100,000 lines of code. The software I develop is pretty large and typically doesn't surpass 40,000 sloc written in-house (i.e. excluding third party libs). Does anyone here maintain such large codebases? Are they truly that big or are people just counting thir…
I am responsible for a 1.1m LOC application. It's a whole bunch of separate DLLs.
Re: Undebt: How We Refactored 3M Lines of Code
#35The amount of code you have in a company is usually a function of the amount of engineers you have.
Re: Undebt: How We Refactored 3M Lines of Code
#36"...time that could be better spent working on new features and shipping new code" Can we please stop putting forth this idea that features >>> reliable product? The amount of dev time that a company will save from removing technical debt will likely be more than the extra sales the company will get from a new feature. I look forward to the day where the executive team comes to the developers and ask why they are wor…
There's a pervasive idea that software is just a laundry list of features. This idea isn't just wrong, it's dangerous. You can pick lots of examples of software where the competitors are in theory feature comparable but the experience of using one is vastly superior to the other, with a consequent huge impact on market success.
Re: Undebt: How We Refactored 3M Lines of Code
#37"...time that could be better spent working on new features and shipping new code" Can we please stop putting forth this idea that features >>> reliable product? The amount of dev time that a company will save from removing technical debt will likely be more than the extra sales the company will get from a new feature. I look forward to the day where the executive team comes to the developers and ask why they are wor…
Yes! 3M is way way way too much, and too few viscerally feel this. Yelp is far from the only offender, of course.
Re: Undebt: How We Refactored 3M Lines of Code
#38Earlier quoted context omitted.
The front-facing system is the smallest part The admin and back-office system is deeper. Beyond the reviews you also have: events, mailing list management, profile management, messages, i18n, search, etc Example: http://engineeringblog.yelp.com/2015/10/how-we-use-deep-lear... Edit: still, 3Mi lines is massive. However, I think there's something that contributes significantly: HTML and CSS
Hmm, well even with all those, the amount of code just blows my mind!
Once I was talking to someone from SAP. He told me about their Netweaver framework is 1 billion LOC and 40k SQL tables. That does not include any application, yet.
The biggest reason for the bloat: People are not allowed to change code. You only add code. Now try to add a button to some GUI without changing a single line of the existing code. At this moment I understood, why enterprises produce those overengineered AdapterFactorySingletonDecoratorBridge stuff.
Re: Undebt: How We Refactored 3M Lines of Code
#39"...time that could be better spent working on new features and shipping new code" Can we please stop putting forth this idea that features >>> reliable product? The amount of dev time that a company will save from removing technical debt will likely be more than the extra sales the company will get from a new feature. I look forward to the day where the executive team comes to the developers and ask why they are wor…
There is an old Joel On Software blog post I was reading recently that talked about a methodology at Microsoft they called "Zero defects", where fixing known bug _alway_ had priority over working on new features. Here - pont 5 in this post: http://www.joelonsoftware.com/articles/fog0000000043.html
I want to believe we can someday gave the same policy for bad abstractions.
Re: Undebt: How We Refactored 3M Lines of Code
#40"...time that could be better spent working on new features and shipping new code" Can we please stop putting forth this idea that features >>> reliable product? The amount of dev time that a company will save from removing technical debt will likely be more than the extra sales the company will get from a new feature. I look forward to the day where the executive team comes to the developers and ask why they are wor…
There is an old Joel On Software blog post I was reading recently that talked about a methodology at Microsoft they called "Zero defects", where fixing known bug _alway_ had priority over working on new features. Here - pont 5 in this post: http://www.joelonsoftware.com/articles/fog0000000043.html
I like this policy, but it doesn't directly help to reduce the technical debt.