Narcissism of small code differences | Hacker News Reader

Narcissism of small code differences

weblog.raganwald.com

53 pointsdangoldin25 comments

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?

> 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?

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.

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.

Not very often.

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.

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).

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.

Nope. Unit Tests are specs that automatically verify themselves.

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.

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.

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.

I agree completely, and I guess I should have pointed out that your main point (that programmers take it on themselves to narcissistically fiddle with functioning code) is an excellent one. My comment wasn't meant as a criticism, but as pointing to an unstated assumption-- that the folks fiddling with the code assumed they knew what it was supposed to do-- and that documentation of the actual business requirement ought to be a) present somewhere, and b) consulted before anyone takes it on themselves to mickey with the code.

Another argument for starting your own startup.

Only if you don't plan to have employees.

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.

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).

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.

Why not delete code? Old/stale/unused code gets only in the way and doesn't serve any purpose. And if you really happen to need it later, it is readily available in your version control system.

I fully agree with your rule about quick and dirty. I'm currently rewriting a module that was "designed" with the "I just want to get it done" approach to software engineering.

What's the old saying? A few weeks of coding can easily save you 5 minutes of design?

We're also missing a deadline. But what is the point of meeting the deadline if we have to throw out the code afterwards and start over anyway? It is better to do it right the first time. A solid system a few days late beats a crappy system on time.

In my opinion, if the code is so complex and messy that you can't see whether individual pieces are correct, then it must be considered broken, even if it compiles and does something.

"And if you really happen to need it later, it is readily available in your version control system."

Of course. I was referring to code deleted from everything, including the version control system. By the time someone noticed, it wasn't findable even on backups. Believe it or not, in some shops it does happen.

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.

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.

On the topic of code standards. PEP 8.

And more importantly. Every standard is meant to be broken. It's just supposed to make you think about why you're breaking the standard. Cost-benefit and all that jazz.

This is a new phenomena that is unfortunately gaining a lot of traction in Silicon Valley. I used to work with guys who know and love your guys and all the other guys who have the blogs and the tweets and the meetups and whatnot.

I actually left my last startup because they hired an engineering manager who was more into test/code ratios and migrating to the latest deployment framework instead of fixing longstanding user complaints. 6 months after I left, the (easy to implement) features our users were complaining about are still not up on the site, and I see job postings looking for a new engineering manager.

Right, but I don't think the problem is people who love test ratios. It's companies that don't know what's important or why.

Reply on news.ycombinator.com