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

Google's ‘Gopher Team’

wired.com

Post reply on HN
Print view View original

21–30 of 40 posts

Re: Google's ‘Gopher Team’

#21

Post by JulianMorrison »

edw519 wrote: post #5

If code doesn’t receive constant love it turns to shit, I would prefer "If bad code doesn't receive constant love it turns to shit" I am aware of thousands of examples of heavily used commercial software that hasn't been touched in 5, 10, 15, even 20 years because it just works and always has. Properly designed and written scalable software can last indefinitely with little or no modification, even through geometric…

What causes code to turn to shit is taking a well designed, well-factored solution, and hanging a patch off the side to make it do something new, or to fix a use case it wasn't designed to handle.

The "constant love" needed is that after a change you must redesign or at least refactor. Preferably every time, or you build up a debt of work.

Re: Google's ‘Gopher Team’

#22

Post by atonse »

Robin_Message wrote: post #2

No they don't. One guy started a major rewrite of a broken piece of infrastructure, and "the Go team [which he is part of] now regularly volunteers to help other teams with small projects", so as to learn more about how Go can replace and augment existing systems. This headline is so far beyond journalism as to be a joke. It's just making shit up for the sake of having a "story". I can imagine it now. They heard "gop…

Being married to a Journalist and also hanging out with her journalist friends has made me realize that, VERY OFTEN, the person writing the article isn't the one that writes the headline. And they sometimes hate the headline as much as the readers do, but that's how it goes in that industry, I suppose.

Re: Google's ‘Gopher Team’

#24

Post by JulianMorrison »

kawera wrote: post #6
edw519 wrote: post #5

If code doesn’t receive constant love it turns to shit, I would prefer "If bad code doesn't receive constant love it turns to shit" I am aware of thousands of examples of heavily used commercial software that hasn't been touched in 5, 10, 15, even 20 years because it just works and always has. Properly designed and written scalable software can last indefinitely with little or no modification, even through geometric…

Properly designed and written scalable software can last indefinitely with little or no modification, even through geometric changes. Daniel Bricklin wrote an interesting article[1] related to long lasting software (PDF) [1] http://changethis.com/manifesto/download/6.200YearSoftware

The analogy between bridge building and software is very old and very wrong.

Software can indeed be designed like a bridge, proven and then built for one unchanging use case and set in stone. And unless you are writing for NASA, soon enough that code will be junked as an obsolete millstone because use cases change. No engineer could design a bridge that might have to be rebuilt into an aircraft runway, or a 20-floor apartment complex, at a whim.

Re: Google's ‘Gopher Team’

#25

Post by general_failure »

I hope all journalism majors are sitting up and reading this carefully. This is how you make a nice imaginative story out of a small interview. A good story/link bait needs something in desperate need ('lousy code'). Then it needs a hero ('gopher team'). Then it needs a title which will catch people's attention (people can't help reading about 'google'). Creative journalism at it's best.

In case it isn't clear, the only store here is that one guy wrote Google's download server in Go because it was not working well. That's it, that's the only story. Google doesn't send some task force or anything like that.

Re: Google's ‘Gopher Team’

#26

Post by contol-m »

They should really dispatched to fix the Google Drive Client program for Mac. It consistently maxes out a CPU even when there is no sync going on. I can consistently reproduce this issue on all Macs I own.

Re: Google's ‘Gopher Team’

#27

Post by VikingCoder »

"The team was able to make many improvements to the way the language handles clustering and file transfers."

Either the journalist had no business writing this sentence, or the people who designed Go put things in the language that should have been in the libraries. Or both.

Re: Google's ‘Gopher Team’

#28

Post by dman »

acqq wrote: post #17
edw519 wrote: post #5

If code doesn’t receive constant love it turns to shit, I would prefer "If bad code doesn't receive constant love it turns to shit" I am aware of thousands of examples of heavily used commercial software that hasn't been touched in 5, 10, 15, even 20 years because it just works and always has. Properly designed and written scalable software can last indefinitely with little or no modification, even through geometric…

It doesn't work that way. The underlying assumptions change. The program can be perfect but still not matching what becomes necessary in a few years. The example they write about is exactly such a kind. Sometime in 2007 it was apparently slow to access files from the distributed storage on Google. Therefore, a Python script was written to fetch these files to some local disks. Python was obviously enough since that p…

Not all software operates at scale. The backwards compatibility fostered by posix and wintel has meant many such applications have been silently doing their jobs for many years without (m)any changes.

Re: Google's ‘Gopher Team’

#29

Post by acqq »

dman wrote: post #28
acqq wrote: post #17

Earlier quoted context omitted.

It doesn't work that way. The underlying assumptions change. The program can be perfect but still not matching what becomes necessary in a few years. The example they write about is exactly such a kind. Sometime in 2007 it was apparently slow to access files from the distributed storage on Google. Therefore, a Python script was written to fetch these files to some local disks. Python was obviously enough since that p…

Not all software operates at scale. The backwards compatibility fostered by posix and wintel has meant many such applications have been silently doing their jobs for many years without (m)any changes.

Yes, when the underlying assumptions don't change and the program is already good it will remain good. The point is that the changes of the underlying assumptions can make even the once perfect program one that's suddenly unusable and it's impossible to cover all future possibilities. Targeting realistically is the only way to make the good program at the start.

Re: Google's ‘Gopher Team’

#30

Post by mason55 »

JulianMorrison wrote: post #24
kawera wrote: post #6

Earlier quoted context omitted.

Properly designed and written scalable software can last indefinitely with little or no modification, even through geometric changes. Daniel Bricklin wrote an interesting article[1] related to long lasting software (PDF) [1] http://changethis.com/manifesto/download/6.200YearSoftware

The analogy between bridge building and software is very old and very wrong. Software can indeed be designed like a bridge, proven and then built for one unchanging use case and set in stone. And unless you are writing for NASA, soon enough that code will be junked as an obsolete millstone because use cases change . No engineer could design a bridge that might have to be rebuilt into an aircraft runway, or a 20-floor…

> The analogy between bridge building and software is very old and very wrong.

I disagree. I think that the assumptions and use cases just change much more quickly in software than in the physical world.

The covered bridges from 150 years ago were built with the assumption that they'd be used for horses, carts and people. When cars became the primary mode of transportation then those assumptions no longer held. No one would say that the original bridge was poorly built, just that the use case changed.

Similarly, software that was built with the assumption that network access is slow has had its typical use case change. Software that was built to keep things on disk because RAM is expensive needed to change. Pretty soon we'll all demand that software assume that disk access is fast again because we'll move to SSDs.

Post reply on HN