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 "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.
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 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.
"If code doesn't receive constant love, it turns to shit."
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.
> A decade later you find that you don't just have one half-assed solution to rewrite, you have a decade's worth.
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.
Of course, but these are ends on the spectrum, it's important to find the happy medium.
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.
True, but a static-file server should be trivially scalable. That is, scalable by placing it behind a load balancer(or using any number of alternative methods that don't acutally touch the server itself).
Even if the server implements Access Control, it should still be trivially scalable.
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".
True, but it isn't the only company serving apt packages, and it isn't even the biggest one. Considering that their apt server was as slow as it was(http://talks.golang.org/2013/oscon-dl.slide#9) - they obviously did something wrong that everyone else was doing right.
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.
11 comments
[ 9.7 ms ] story [ 72.9 ms ] threadThis 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.
http://talks.golang.org/2013/oscon-dl.slide
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:
Daniel Bricklin wrote an interesting article[1] related to long lasting software (PDF)
[1] http://changethis.com/manifesto/download/6.200YearSoftware
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.
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.
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".
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.