

Narcissism of small code differences - dangoldin
http://weblog.raganwald.com/2008/05/narcissism-of-small-code-differences.html

======
sanswork
I honestly thought this would be about how every time someone anywhere posts a
code snippit online 10 people attack how it is written suggesting differing
opinions(3 of which won't work at all, 2 will be in a different language, and
2 will solve completely different problems).

I see it everywhere I look and I'm really getting sick about it. How about the
rest of you?

~~~
raganwald
> I honestly thought this would be about how every time someone anywhere posts
> a code snippit online 10 people attack how it is written suggesting
> differing opinions(3 of which won't work at all, 2 will be in a different
> language, and 2 will solve completely different problems).

Does Freud's "Narcissism of Small Differences" help explain why this happens?

------
menloparkbum
The problem with this article is that the examples suggested never happen.

Once in a while with dynamic languages you come across a "librarian" who likes
to use the arcane language features. Perhaps more often, if you use Java, you
will encounter code where a lot of AbstractWhatTheFracktory design pattern
abuse is going on. However you will never, ever find the "ascetic" who
rewrites the zipcode-padder using lambdas.

Sadly, most of the time you just see the typical egregious dailyWTF mess.

~~~
raganwald
Of course you never see people use the y combinator to write a string padding
algorithm. But do you ever see people overuse metaprogramming or abuse open
classes?

The story was not meant to be taken literally.

~~~
menloparkbum
Not very often.

------
stcredzero
This is one place where Unit Tests help nicely. If the group were using Test
First, then the zealots would've had to read and revise tests before they
rewrote code. They would've been able to read the test code and would've known
about the business logic requirements. If they didn't do that, then failing
tests would've clued them in.

~~~
jeroen
If the function had a descriptive name then its purpose would be even clearer,
and the calling code would be more readable too.

Nothing against unit tests, but I don't think they should serve as comments
(which is more or less what you suggest).

~~~
iseff
Actually, I think it's important not to think of tests necessarily as
"comments," but rather as "specs." This is pretty much the thesis of Behaviour
Driven Development.

If your tests define what your program _should_ do, then your tests can become
(a) more understandable and (b) more valuable to new folks familiarizing
themselves with your code.

It's a subtle but important (IMHO) distinction.

------
michael_dorfman
I think the key (unstated) point here is that the actual business purpose of
the code was not obvious to the others reading/editing the code-- business
rules like "Anything with fewer than three digits is supposed to be an invalid
code" were not made explicit. Anyone attempting to find a more elegant
solution to the problem needs to be able to fully understand what the problem
is.

~~~
raganwald
Fault/Blame/Responsibility does not neatly add up to 100%.

Therefore, even if we can find ways the Agnostic could have documented this
requirement in the code, or if we installed a build server that would have
rejected the rewrites for breaking unit tests, this does not absolve the
others of responsibility for:

1\. Making changes without understanding the requirements. They weren't
documented as comments, fair enough. But did those fictional characters
examine the entire system? Did they review which code produced this function's
input and which consumed its output? Did they ask the Agnostic why his code
didn't handle strings of fewer than three characters?

One day the Agnostic will be gone, and one day soem hapless programmer will
have to do the detective work to figure these things out. And that's a great
reason to document things... to save someone the detective work. But a lack of
documentation is not an excuse to skip the detective work.

2\. Nowhere in the story was there a bug report filed, nor an individual
"tasked" (I hate verbifying) with a rewrite. Nor did the story describe
someone updating the unit tests to include the "missing cases."

3\. Many folks have identified the need for these fictional characters to
communicate. Note that in the story, even after the problem is identified, all
four characters carry on behaving exactly the same way. The Agnostic at least
tries to talk to the others, then gives up and just codes. None of them step
back and ask the kind of questions you are asking here. None of them step back
and figure out that there is more at stake than what to do with two-character
zip codes.

So... what I am saying is that I agree with you, and on top of my agreement I
am suggesting that even if we are finding ways the fictional Agnostic could
have been a better developer, we shouldn't stop right there. We shouldn't let
the others off the hook.

~~~
cstejerean
I think either I missed the point of this post or pretty much everyone else
did. A post titled "The Narcissism of Small Code Differences" can't possibly
be about what the proper way to write something is, about comments, or testing
and build servers.

If I read it correctly the story is supposed to illustrate the problems that
can arise when developers are tempted to rewrite something just for the sake
of writing it differently. This should normally get people to think about what
causes said urge, but I'm guessing nobody followed that train of thought. Then
in your update you brilliantly stated

"it’s about the dynamic of programmers eager to rewrite code in their own
image, and the hypothesis that our [...] motivation for doing so is to
emphasize the small differences between ourselves and others."

Since this is something I'm guilty of myself I would have liked to see more
comments on your hypothesis and other possible reasons for this interesting
phenomenon. I still don't know if I have anything intelligent to say on the
topic, I'll have to give this some thought and if I get any insights I'll
probably reply on my blog.

------
edw519
Another argument for starting your own startup.

~~~
ojbyrne
Only if you don't plan to have employees.

~~~
edw519
Either

a. I won't have employees or

b. They will follow standards.

Either way, I'll never have the problems in the original article.

We'll be far too busy addressing issues to be arguing over details. I have
never tolerated that from employees and I don't imagine I ever will.

~~~
tonystubblebine
I used to manage a group of engineers who were very keen on maintaining their
standard of software craftsmanship. They had a high test/code ratio and were
always up to date on the latest idioms. That was their idea of craftsmanship
and something that written standards could easily support.

However, our customers were complaining bitterly about bugs and missing
features. They had a totally different idea of craftsmanship. Certainly our
written standards could have been expanded but I found that the core issue was
that the engineers had latched on to code quality when our customers really
wanted them to latch on to software usefulness. The fault probably lay with
the managers, as we couldn't figure out what was the useful thing we wanted to
build. Thankfully one of the engineers invented Twitter in his spare time and
we were all saved (a simplified but mostly true story).

~~~
edw519
This whole issue is a sore spot for me. Seems like I've always had someone who
missed their deadlines but "cleaned up" something that didn't need cleaning
up. I've even done it myself. It's an easy trap to fall into, after all, we
tend to be optimizers, maximizers, and perfectionists.

The best approach to this I've ever found is the solicit agreement to a few
simple rules and standards. Things like:

\- Don't fix it unless it's broken.

\- Don't delete any code. Ever. (Did I say ever.)

\- Don't bypass tools we've agreed to use.

\- Don't violate standards we've agreed to follow.

\- Quick and dirty isn't quick. It's only dirty.

Often the violator doesn't even realize what he's done until you point it out.
OP was obviously a caricature, but you still gotta stay on top of it.

~~~
sofal
The "don't fix it until it's broken" is an interesting discussion. From what
you've said, customers and developers can have a very different definition of
what "broken" means, and the customer's definition trumps the developer's. I
don't imagine you'd throw out all the refactoring and "cleaning up" jobs
though. There'd have to be some consensus case-by-case on what is really
broken and what isn't. Managers can overlook some serious code rot just
because the front end seems okay. I'm guilty of being the perfectionist
though, and it'd be wise of me to keep my pragmatic hat on more often.

I'm a little wary of code standards. I've found that they can be a bag full of
cargo-culted banalities like "never use break statements", "never have more
than one return statement", "the tertiary operator is the spawn of the Devil",
"if you use a one-liner if-statement you will hang", or "duplicate all of the
version control history by hand at the top of every file". I'd feel much more
comfortable if I worked in a small team and we all got together and agreed on
some important and useful standards rather than have them dictated by a
manager who used to code back in the 90s.

~~~
tonystubblebine
Maybe the rule should be "don't fix it unless you're capable." Then you could
have some guidelines for when someone is capable. Some of that might have to
do with skill/experience but even with my own code I don't like to make fixes
unless it's related to a feature I'm in the middle of. Otherwise I'm at risk
for making subtle functional changes that I don't have any capacity for
understanding or predicting.

