You’re Doing it Wrong If | Hacker News Reader

You’re Doing it Wrong If

postal-code.com

22 pointsraganwald35 comments

You're joking right? Most of these are actually counter-productive, and god help anyone who follows all of them. It's the most beautiful collection of group-think in programming I've seen in a long time.

I've been doing web apps programming for a few years now, and I do admit there are better technologies out there. That's why I've been dipping my feet in lisp for the past year, and lately spending my nights with Clojure. But what he's advocating isn't good programming, it's sheep mentality, and I'm disapointed to see it here.

But since it's not nice to just be a critic:

    * You’re not building atop an open-source framework
    * You’re writing your own framework upon which to build

I have open source above, open source below and open source in the database. But holding it all together is a thin layer written by me, simply because I want to be able to adjust it as much and as often as I feel like.

    * You’re not using an ORM layer
    * You’re writing your own ORM layer

I actually played with writing my own a few year back. In the meantime I thought a lot of times about its benefits and I ultimately decided against using one. Why? Because I only ever use one database engine, and if I change it it will definitely happen on a new app. Also I value too much development speed and flexibility. I saw code developed with ORM, and I still have see xml in my nightmares. Granted, it will probably work in many contexts, and if/when I switch to lisp I will probably use a persistance engine instead of a database, but now and for me it's definitely not an advantage.

    * You believe you can write it faster or better or more efficiently than any available library

You can, always. It's only a matter of effort invested. In most cases, the years necessary are not worth it, but very ocasionaly it pays.

    * You have more than one developer on your project and no written coding style guidelines

I usually poke them on the head when they forget spaces. I most certainly don't waste time with written specs.

    * Your bug tracker serves as your functional scope or your development roadmap

Actually it does. Took it from google: the best project management tool is a queue. Put stuff at one end, solve at the other. And also, we don't believe in deadlines.

    * You aren’t using source control

We are and like it.

    * You comment the what but not the why

We never comment. Ever. We spend lunch breakes thinking up intelligent variable names.

    * You tend to pass properties instead of instances to functions

No idea what this is, but we probably do it.

    * Your “deployment procedure” involves any combination of FTP and/or drag n’ drop

More like scripting and ssh. This one's ok.

    * You write code in a manner that cannot be unit tested

We don't unit test. True, it hurts ocasionaly, but at the amount of new (good) code we write, it's not really necessary. What we do (well, I at least and I'm evangelical about it) is read and re-read code, preferably before compiling.

    * Your primary method of code reuse is copy/paste

No comment.

    * You don’t read any development blogs focused on your primary and secondary languages or technologies

LOL

    * You haven’t been to a conference or birds-of-a-feather meeting in the past year

Really lol'ed this time.

    * The only code you read at work is your own

And my coworkers. True.

    * You worry that some day someone else will read your code and know it was written by you

Don't. True.

I don't understand object-relational mapping. At all.

If your data is not organized relationally, why are you using a relational database?

So the people that built Rails, Django, Lift, various ORM libraries, and optimized libraries, such as Boost, all did it wrong? Hell, I hope everyone is that wrong at least once in their lives.

Edit: I also question the necessity or even the marginal utility of conferences.

I think his point is that if your goal is to create a web site, building your own framework is a waste of time. On the other hand, if your goal is to create a framework, knock yourself out. I don't know that I entirely agree but it's a decent rule of thumb.

I'd say the best frameworks and tools in general appear as a byproduct of a bigger project. It's quite hard to start with a mindset of "I want to build a framework that does everything."

Not only is it hard to start with that mindset, it's noxious. Any framework should have a solid footing in reality, and that means developing it alongside a project that needs it.

No they weren't, but I suggest that the number of people who got a net win out of developing their own frameworks is statistically insignificant.

We can both reel of lists of great frameworks, but that's survivor bias at work, because we remember the winners. For every Rails, there are hundreds or even thousands of terrible in-house frameworks all competing to be the subject of a DailyWTF post.

Of course, this leads to an age-old debating point, namely if you can find a few exceptions to a rule, should you toss the rule out? Add a lot of fine print disclaimers? Or keep the rule and trust that anyone who knowingly violates it has a good reason in mind?

Next time you're in the bookstore, check out the chapter on conferences in Keith Ferrazzi's Never Eat Alone. It will provide a good counter-perspective.

At my own company, we had our founder and a director present at a recent conference, and the contacts and credibility they gained there will probably directly contribute to doubling our revenue over the next 2 or 3 years.

You believe you can write it faster or better or more efficiently than any available library

Unless you're right.

Yeah. That's a pretty small percentage of people though. There are only so many DHH's out there...

Maybe he didn't know he had those skills before trying...

He didn't. He wrote RoR precisely because there was nothing to do what he wanted for Basecamp.

Exactly. You don't get progress without arrogant bastards re-inventing things every now and then. Overeager re-inventing is often a recipe for disaster, but categorically dismissing it is too simple.

The arrogant bastards aren't going to listen to a "you're doing it wrong if..." piece.

This is even more true for non-webapps; one of the worst assumptions you can make in a performance-critical app is that your libraries are already fast.

Take memcpy, for example; a while back I noticed that the win32 memcpy was atrociously slow for small blocks, significantly increasing runtime (since our program, x264, did loads of small memcpys). So I wrote my own; it was almost 10 times faster. And that isn't bragging--the function itself was utterly trivial--it just goes to show that system libraries are not always well-optimized.

You're doing it wrong if you don't build your own framework at some point.

Blindly using rails or even merb or any other framework will only get you so far. To truly transcend, you must build your own or heavily alter an existing framework.

This is hacker news right? Go out and build your own framework already dammit!

# You’re not building atop an open-source framework

# You’re writing your own framework upon which to build

# You’re not using an ORM layer

# You’re writing your own ORM layer

I'm glad DHH and the boys over at django did it wrong, to be honest.

As am I, since I use Rails every day. However the number of DHHs and Ezras in the world vs. the number of us regular ol' web developers is quite small. There's a reason the rest of us should take advantage of the labours of the few rather than attempting to duplicate them.

DHH, JKM, and AH were a "regular ol' developers" until after they built rails and django.

They're smart cookies, and but so are many web devs. While I agree that we should benefit from their labours, if there are times when we are confronted with the problems they had, we should be as bold as they were.

Anyone who should be as bold wouldn't heed that advice anyway.

Cetainly, and if you're setting out to build a framework then by all means build a framework. Or if you're setting out to improve a library then by all means, improve the library.

But if you're setting to build a web app chances are it's folly to build your own "framework" and ORM and libraries first (note for the absolutists in the crowd: that is purposely _not_ an absolute statement; we can all come up with suitably contrarian one-off edge cases).

You tend to pass properties instead of instances to functions

What does this mean?

I obviously don't speak for Chris, but I took it to mean that instead of:

   ira_account.register_with_irs(customer.get_ssn())

He suggests:

   ira_account.register_with_irs(customer)

Which I think is a roundabout way of getting at looser coupling and working at a higher level of abstraction.

(update: obviously, I cast this in OO rather than functional terms. I suspect the point is isomorphic to FP).

But doesn't that stright-up violate the Law of Demeter?

http://en.wikipedia.org/wiki/Law_of_Demeter

Good question. That being said, I'm a long time Demeter Scofflaw...

I was just going to post that. If that's what he means it's the opposite of what you should usually do; in that example you're making register_with_irs() depend on the implementation of customer when it doesn't need to

And therein lies the trade-off. It may be that one day you need an address as well as an SSN to register an IRA. If you chose door A, you update the calling code to either pass both properties or pass a customer object. If you chose door B, you update the callee code to extract the address as well as the SSN.

In one case we're arguing that the registration code shouldn't have to know how to work with a customer. In the other case we're arguing that code initiating a registration shouldn't have to know what the IRS wants from a customer.

Seems like there's room for reasonable people to empty a bottle of single malt while debating the alternates.

That is indeed what I meant though of course it is not an absolute statement. As a general rule of thumb, inside your own web application, passing objects rather than raw data will lead to easier to read & debug code, quite likely at the risk of tighter coupling, you are correct.

'Course unless you're building a framework or library coupling should probably not be your main priority when building a web site.

As for the Law of Demeter, like my list that too is a rule of thumb and not an absolute, requiring judgement calls.

Ah. In that case, it depends on the situation. If you're going to do something that depends on a property of an object, you're going to have to pass the property itself as an argument eventually. E.g. if you want to see if the ssn is a valid one, or equal to some other ssn.

I wonder if he's talking about some problem that happens with people who've converted from other languages, and that's why I don't understand it.

I agree, there's obviously a trade-off involved. I think the real issue is trying to identify RW-B's "Roles, responsibilities and Collaborations" in a design. There's (a) a piece of knowledge that a customer is involved, (b) a piece of knowledge that an SSN is involved, and (c) a piece of knowledge that an SSN can be extracted from a customer.

I suspect the issue here is making good decisions about which entities/modules/functions/objects/thingummies should know a, which should know b, and which should know c.

Oddly I didn't expect the "property/object" one to be the most contentious! Who knew? Perhaps that one suffers more from brevity than all the others.

The observation stems from seeing reams of web app code that take in form data (or raw database data) and then proceed to move it around the app without encapsulating it in any way. The result is functions like:

function display_user( user_first_name, user_last_name...user_valid)

Look at twenty or thirty functions like that in an app and one starts to think "perhaps you need a user object?"

I certainly didn't mean to suggest we should all start tightly coupling all our classes together willy-nilly.

It suffers from resembling a bikeshed ;-)

Like almost all rules in that list, this seems way too broad -- often enough it makes more sense to pass some more primitive value, even if you get it from a property.

func(SSN, DOB, Fname, Mname, Lname);

vs.

func(PersonInstance);

The first one is more tightly coupled. But there are no hard and fast rules in good design.

You're doing it wrong if you don't look at everything you're doing with a critical eye.

That means you'd better think critically about the ORM/Framework/Fairyland you're using to build things.

Reply on news.ycombinator.com