

Have You Met Your Dog, Patches? - bdfh42
http://www.codinghorror.com/blog/archives/001299.html

======
jcl
Summary: Jeff read the Gamasutra article about bad coding practices. He then
notes that "Apache" is a play on "a patchy", and that he recently refactored
some StackOverflow code that had been patched in the past (code not provided).

Also, there is a picture of a dog.

~~~
DannoHung
Jeff Atwood's blog would be improved immensely if it was _just_ pictures of
dogs.

------
ajb
Back in the eighties, my mother had a job as a programmer on a maintenance
contract. 'In order to reduce risk', the contract specified that bug fixes
should change _the minimum number of lines of code_. Really.

I remember her bringing home a listing (remember listings?) and trying to
figure out how to change some loop. It had already been 'fixed' a number of
times using this methodology, so it was a mess of nested if statements. I
suggested that it needed rewriting. (Although this was the right answer, I
didn't actually have the programming experience to know this at the time).
Unfortunately, she thought that was too large a change to be acceptable to the
client.

------
wwalker3
Patches grow on our code because it's easier to patch than it is to figure out
the paradigm-changing code simplification that will encompass all previous
functionality _plus_ the new thing we want to add. That's hard work!

I'm elbow-deep in patch remediation right now, and even though I'm not worried
about breaking anything (I have good code coverage and a big automated test
suite), it's still mentally draining to do it right.

------
RyanMcGreal
Cf. Jeff's partner:
<http://www.joelonsoftware.com/articles/fog0000000069.html>

~~~
Davertron
That article is about not throwing away your whole codebase; in fact, he even
talks about doing exactly what Jeff Atwood mentions:

 _These problems can be solved, one at a time, by carefully moving code,
refactoring, changing interfaces. They can be done by one programmer working
carefully and checking in his changes all at once, so that nobody else is
disrupted. Even fairly major architectural changes can be done without
throwing away the code._

Joel, I'm sure, is not advocating never re-writing anything at all, and if you
think that, sheesh, I'd hate to see the code you work on...

~~~
RyanMcGreal
I was offering Joel's essay as _context_ , not contradiction. I just thought
it was worth comparing the two arguments, given that the authors work together
on stackoverflow.

~~~
Davertron
Still, even in your comment, you're suggesting that there are _two arguments_.
I guess what I'm saying is that there aren't any arguments here at all.

------
blasdel
His blathering might hold up a bit more if Apache wasn't such a kitchen-sink
heap of shit that would have been end-of-lifed a long time ago if the ASF
hadn't lost itself in SOAP, WS-*, and Java for a goddamn decade.

~~~
icey
What web server do you use?

~~~
blasdel
Whatever's most appropriate for the job! For dynamic content I use the HTTP
abstraction native to the language I'm using (WSGI, Rack, Servlets, etc.), and
a single-purpose HTTP server that supports it: twisted.web,
cherrypy.wsgiserver, GAE, mongrel, etc. For production, separate HTTP servers
(possibly in multiple layers) reverse-proxy the app servers: handling client
interaction, caching, routing, dispatch, etc.

Apache's design is completely degenerate: you're encouraged to do all of these
logically independent things in one process, even the app execution!

Years ago I used lighttpd and even hacked it's webdav implementation for using
on localhost as an alternative to FUSE on OS X. I eventually realized that
they made all the same design mistakes as Apache, they just had the courtesy
to use epoll (the Apache MPMs are a cruel joke).

~~~
icey
Would you consider Apache appropriate for the job for someone who doesn't want
to have to try six different solutions to serve their webpages?

I hear what you're saying about it being monolithic, but I do think it has its
place.

~~~
blasdel
You generally don't need the reverse proxies in front until you're doing
something sizable (or that fits into something of size). I haven't done a
project that needed them in a while! You can just use a single app server
capable of processing multiple requests -- twisted.web is a solid event-driven
one.

If you just need to serve static pages nginx is _perfect_ by itself. If you
really need a monolithic swiss-army-knife, lighttpd is at least a pretty good
implementation of a mediocre idea.

I really dislike a lot of things about Rails, but I will be eternally grateful
for the way their community accidentally demonstrated to the world that the
ASF's crap was not the alpha and the omega of webserving. At the time the only
options that people thought viable were httpd and overarchitected babel towers
(lots of Java crap, WS-*, Zope, etc.).

