Google's ‘Gopher Team’
wired.com
wired.com
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 "gopher", thought of another animal, then thought about how awesome some of the coders on the Go team are (look at the blinking lights!), and BAM! invented an elite squadron of coders who fix whatever problem you have based on a combination of the navy Seals and the A-team.
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 changes.
But I like OP's quote. I think it should become part of every code reviewer's checklist:
Will this turn to shit without constant love?
No: Pass.
Yes: Then fix it now.Daniel Bricklin wrote an interesting article[1] related to long lasting software (PDF)
[1] http://changethis.com/manifesto/download/6.200YearSoftware
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.
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.
Not sure what your example of untouched code represents. The OP says that what makes code turn bad is accumulated local changes and bug fixes without thinking about the big picture. Of course if no one ever touches the code, its quality doesn't change.
The problem is that what may be "proper" today (thinking, say, 5-10 years out) may fail the test in 10-15 years. One has to design software under some constraints, usually defined by the problem boundary and thus it by definition cannot be infinitely scalable and flexible.
Also, the problem is the code ends up being maintained by programmers of varying levels of competency. Even if competency is not a problem, the varying styles inadvertently lead to spaghetti and inconsistent code.
Still, until 2013 a lot of assumptions based on which the program was written changed completely: Accessing files from the distributed storage became faster. The typical computer which is to deliver the data seems to have much more free RAM, allowing using RAM for caching purposes instead of the local hard disk. The nature of the load changed so much that accessing the local hard disk became the bottleneck anyway. Which is not so surprising: one disk seek is still around 10 ms, which means as soon as you can't deliver something from RAM you can deliver only up to 100 items from the disk per second, when they are not in the same block of data.
Don't tell me you have to write the program for "all possible assumptions." Unless you have unlimited time, you write it to solve the problem under existing assumptions. Once they change, you change the implementation.
Moreover, to achieve the changes related to the underlying assumptions, Go wasn't needed in the current example, but it was the most convenient approach for Brad, who is by the way obviously an extraordinary programmer.
What I agree with you is that if the program is bad even under the initial assumptions, it's certainly something that should be observed and tracked by the good manager: he must know that he can't rely on such program and that whenever the program gets any heavier load, the problems will happen.
See also: A Tale of Two Bridges http://hintjens.com/blog:16
A decade later you find that you don't just have one half-assed solution to rewrite, you have a decade's worth. And because you're spending every second of your working life maintaining that teetering pile of kludges the idea of setting aside enough time to do a proper rewrite is sheer fantasy.
Certainly there is a good case to be made for accepting technical debt as a necessity in order to get products into the market and revenue coming out of the market, but on the other hand the typical software development organization tends to be drowning in technical debt. Pay down your technical debt regularly and quickly, not after a decade. For every example of the half-assed temporary solution that made the company money there is a story of development hampered by the burden of maintaining more technical debt than is wise.
Whereas if you don't have a good sense of priorities, and you don't get your product out the door, a decade later your company's been dead for nine years.
One of the biggest downsides of taking on a lot of technical debt is that the cost tends to be indirect and diffuse. And that's the sort of thing that organizations find it easiest to ignore. It's only when the pain becomes acute and obvious that it tends to be addressed, but by then the cost of addressing it is often several orders of magnitude higher than it would have been if it was addressed at a more appropriate time. This can cause a severe stoppage of development velocity and has doomed a sizable number of major projects and products over the years.
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.
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.
You can see this in the response to "we can't serve files correctly" in that there was to rush in write new code in a Google language (Go), as if there weren't thousands of existing ways to solve this with an open source component already.
Perhaps the problem was that dl.google.com was being used for too many things at once, but this doesn't excuse building custom software that offers worse performance than free off-the-shelf products that literally everyone else has been using for years.
Also, nginx doesn't have such...interesting ideas as the custom server: http://talks.golang.org/2013/oscon-dl.slide#19
I mean, if by "rather uncommon challenges" you're referring to the "what are threads?" design philosophy of the original... then yeah, it does require "custom software".
* Package importing is easy and a first-class language structure
* Fast compiles (related to no circular dependencies)
One of the more controversial features is no inheritance -- only composition. It's an interesting break from vertical/horizontal inheritance schemes.
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.
[1] http://grokbase.com/t/gg/golang-nuts/12asyfnbea/go-nuts-dl-g...
But it sounds like this code was receiving "love", only the "love" was coming from run-of-the-mill "just get it to work" C++ programmers.
I guess we need context to understand Fitzpatrick's statement. Perhaps he just means code at Google.
Are there any examples of code that has survived for many years without "constant love"? Netcat has not received "constant love" over the years. It hasn't turned to shit. Neither has the original awk. I can think of many other examples. These programs have proven to need very little maintenance.
I posit that simple programs that are well written do not need "constant love". They only need love when there's a bug. And there are plenty of programs that are in constant use where no bug has been discovered for many years. The bugs were vetted and fixed early on, decades ago.
Hence I disagree with Fitzpatrick.