31–40 of 40 posts
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.
[1] http://grokbase.com/t/gg/golang-nuts/12asyfnbea/go-nuts-dl-g...
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…
Or just deploy the half-assed solution, which will get the job done and allow your limited engineering staff to focus on higher priorities. Then, a decade later, when the company is worth hundreds of billions, you can rewrite it from scratch the proper way. 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.
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.
Earlier quoted context omitted.
Or just deploy the half-assed solution, which will get the job done and allow your limited engineering staff to focus on higher priorities. Then, a decade later, when the company is worth hundreds of billions, you can rewrite it from scratch the proper way. See also: A Tale of Two Bridges http://hintjens.com/blog:16
It's a good sentiment, but it doesn't usually work that way. 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 technic…
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.
I really don't understand why dl.google.com isn't just running Nginx or some web server. It's just serving files. Why does it need software written in house?
Nginx was built with 'single server' architecture in mind while Google generally operates on a 'distributed everything' architecture. This involves stuff like distributed file systems/data stores. My guess is it's not compatible with the single file system interfaces of Nginx. Also note that dl.google.com serves stuff on a massively bigger scale than the majority of the rest of the internet. On that scale I'd guess t…
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".
I really don't understand why dl.google.com isn't just running Nginx or some web server. It's just serving files. Why does it need software written in house?
Google is the only company on the planet with anything approaching its scale requirements. It's entirely possible that even nginx breaks down at their level of speed/concurrency/distribution.
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.
Earlier quoted context omitted.
It's a good sentiment, but it doesn't usually work that way. 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 technic…
> 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.
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.