Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Undebt: How We Refactored 3M Lines of Code

engineeringblog.yelp.com

Post reply on HN
Print view View original

61–70 of 143 posts

Re: Undebt: How We Refactored 3M Lines of Code

#61

Post by chimprich »

lmm wrote: post #55
wcdolphin wrote: post #43

Earlier quoted context omitted.

I challenge that; I don't think a "bug free code base" actually exists. Joshua Bloch has a great article about this which I think may be of interest to other readers: https://research.googleblog.com/2006/06/extra-extra-read-all... . To paraphrase: We programmers need all the help we can get, and we should never assume otherwise. Careful design is great. Testing is great. Formal methods are great. Code reviews are gre…

That bug exists because it's written in a language where + is permitted to silently do surprising things, for reasons that made sense as a performance optimization for general-purpose computers in the '70s and embedded systems in the '90s (the original target of Java) but do not make sense for general-purpose computers today. Better languages are possible. Provably correct software is possible. We really can eliminat…

> Provably correct software is possible.

Ah cool, so you've solved the halting problem then?

Re: Undebt: How We Refactored 3M Lines of Code

#62

Post by jbergens »

lmm wrote: post #55
wcdolphin wrote: post #43

Earlier quoted context omitted.

I challenge that; I don't think a "bug free code base" actually exists. Joshua Bloch has a great article about this which I think may be of interest to other readers: https://research.googleblog.com/2006/06/extra-extra-read-all... . To paraphrase: We programmers need all the help we can get, and we should never assume otherwise. Careful design is great. Testing is great. Formal methods are great. Code reviews are gre…

That bug exists because it's written in a language where + is permitted to silently do surprising things, for reasons that made sense as a performance optimization for general-purpose computers in the '70s and embedded systems in the '90s (the original target of Java) but do not make sense for general-purpose computers today. Better languages are possible. Provably correct software is possible. We really can eliminat…

Often when people mention provably correct software what they mean is software that don't crash and always produces output for correct input. It usually doesn't mean that the output is correct...

Re: Undebt: How We Refactored 3M Lines of Code

#63

Post by vertex-four »

miguelrochefort wrote: post #59
Someone wrote: post #48

Earlier quoted context omitted.

I don't know exactly what Yelp does, but assuming that they have listings for restaurants that aren't their customers, one cause could be that they take in data from lots of sources. Ideally, that is all in the same format, with an enforced data scheme. However, if you require that, you'll notice that very little data manages to make it through your entry port. Few suppliers will want to bend their system for you to…

> On top of that, once you operate world-wide, you'll learn the joy of differences in addresses. Does a country have states? Zip codes? If so, where does one specify them in an address? If you want to localize that in your app (in yelp's case, people may want to show an address to a taxi driver. For that, it would help if the address followed local conventions) line count skyrockets. This is not the first time this i…

Yelp would likely wind up forking such a library, if they used one, when it shows bugs.

Re: Undebt: How We Refactored 3M Lines of Code

#65

Post by PhilipA »

ajdlinux wrote: post #7
wRastel27 wrote: post #5

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

"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." Not always true (though it often is!), but particularly not always true in the timespan that the company needs to get sales in...

The problem is that this is very hard to measure. You can't really measure how much time you save on new features after you fixed the old spaghetti-code.

Re: Undebt: How We Refactored 3M Lines of Code

#66

Post by weavie »

chimprich wrote: post #61
lmm wrote: post #55

Earlier quoted context omitted.

That bug exists because it's written in a language where + is permitted to silently do surprising things, for reasons that made sense as a performance optimization for general-purpose computers in the '70s and embedded systems in the '90s (the original target of Java) but do not make sense for general-purpose computers today. Better languages are possible. Provably correct software is possible. We really can eliminat…

> Provably correct software is possible. Ah cool, so you've solved the halting problem then?

They didn't say it had to be Turing complete.

Re: Undebt: How We Refactored 3M Lines of Code

#68

Post by distances »

throwawayReply wrote: post #45
rhizome wrote: post #30

Earlier quoted context omitted.

Oh man, I would love to work at a place like that. If only there was a "Sandi Metz" specialization in software development. The worst part might simply be managing the egos of people whose work is refactored.

You can find these places everywhere. Look for jobs where the software department isn't the core business and you'll find small groups of devs bogged down trying to implement another customization among code that looks like switch(clientId){ case 42: //todo: Make sure database agrees ... } before each calling what are essentially copies of otherwise identical thousand line functions. Because the "risk" of actually ch…

Rewarding in which way? Getting to really improve the codebase? Compensation?

Re: Undebt: How We Refactored 3M Lines of Code

#70

Post by codedokode »

bigiain wrote: post #10
wRastel27 wrote: post #5

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

Also Joel wrote another article where he says that rewriting the code from scratch (removing technical debt or switching to a new popular framework) is generally a bad idea: http://www.joelonsoftware.com/articles/fog0000000069.html

Improving and perfecting the code is a task that can take infinite amount of time.

Post reply on HN