Monday, April 28, 2014

Don't be afraid of code

Two scenarios of fear to discuss today.

#1. The Legacy App.

It was designed 10 years ago. It grew organically. No one wants to touch it out of fear. The code languishes as everyone searches for a way to work around the beast. Things don't get fixed. Silver bullet syndrome takes over. People would rather leave the company than fix it.

#2. The Low Level Solution.

Things are slow. The most direct solution would be to just write a little C or C++. But that is not clever. It's not smart. C is dangerous. It's unsecure. Surely the Right Way would be to use a stronger typed language or a clever hack distributed across machines horizontally. We prefer it should be unused-language-X, which is Safe and Correct, not C with is Unsafe and Incorrect. It would never be to write C, which is only used by hardcore kernel and game programmers. Web programmers can't use C. That's too hardcore.


These fears are bunk. These are illusions that prevent real work from getting done. It's time for managers and programmers to own up to them and get a handle on them.

* You need to fix the problem directly.

There's just no sense in indirect fixes. Indirect fixes are hacks. Or, worse, ineffective at solving the problem. If you have a legacy app that's a problem, you need to schedule the refactor. If the best fix is tackling a problem in C, then that's the best fix. Working around all of your problems is ultimately just fooling yourself.

* Be like a brain surgeon.

You know how brain surgeons know they're doing the right thing in there? They keep the patient awake and talk to them. They don't know if they're doing the right thing unless they pull on the nerve and see what it does.

Code is like that. It's an inexact science. No one can have total code awareness once it gets to a certain size. It's impossible. You need to use the tools (if your language has them) or simply be okay with breaking some eggs to make changes.

And you can't be afraid to break things. Big changes mean problems, and you have to accept them. This is where management has a large part in determining an outcome.

* Stop with the silver bullet

Beware the conversations like "OMG did you see that new open source ... THIS NEW LANGUAGE HAS... Twitter is doing it this way because..."

Stop.

Your problems are your own. Twitter is Twitter. Facebook is Facebook. Your company is different unless you're making a direct clone of those.

And adopting any solution -- internal or external -- incurs overhead. One must recognize what the tradeoff is, especially if that solution is open source and unlikely to be popular amongst other adopters (and hence fade away, like many solutions have done over the years).

* Please just use C and C++ when warranted

They're really not that hard. You can write very simple C++ using Boost and have it be a billion times better than some randomness you've twisted into a pretzel to avoid writing in C++. Again, every abstraction you add to avoid writing in these languages incurs its own overhead down the road (see the silver bullet point)

Do not be afraid*

* - Is written 365 times in the Bible? What's up with that.

Thursday, April 03, 2014

Why Node is the Future of the Web Tier

Everyone I know hates Javascript. Including people who do it professionally.

I hate Javascript. I long for the day where it's been completely destroyed in favor of something else, I don't even care what. Typescript and Dart both look really promising, though I question whether either will ultimately make a dent in the dominance of Javascript.

Node is a gigantic hack. A browser Javascript engine pulled into the server layer? Single threaded?

Node is slower than most alternatives. Even the most rudimentary JVM-based framework will blow it away.

And Node is the future? Yeah, it is. I told my coworkers this the other day in our internal IRC and they couldn't believe it. I thought I should explain my position a little bit more clearly in a blog post.

The reason is a people reason

The server-side web tier is quickly becoming the place where no one specializes. At our company, we have "Front End" and "Back End" positions to hire for. What does that mean?

  • Front End: Javascripty, CSSy and HTMLly stuff.
  • Back End: Servery, Databasey stuff
As the front end becomes more sophisticated and contains more logic, the Back End folks are no longer interested in writing a simple DAL/CRUD web-tier for Front End people to call into. That kind of work is a solved problem, and if the real interesting application logic lives in Javascript, it's no fun. Rather, they're more interested in working on scalable internal services and systems that the lightweight web tier can call back into and work on.

This was our problem when I was back at Groupon. No back-end systems people wanted to take on new work in our Rails stack. The API layer, and related search and database services, sure. But not the web tier. So when it came to do a rewrite, who would own this and what tech would thye use?

The answer is, the front end people need to own this web tier. It cuts down on iteration time and makes for clear ownership. Then back-end people will focus their efforts on scalable systems in Java that the web tier calls out to.

Small companies have been cutting this loop for a long time with Node, but now you see major companies making this transition. Wal-mart. Groupon. Front end tooling relies on Node: Twitter relies on Node for Bower. Microsoft is supporting Node for Windows and has several projects that use it. Everyone everywhere uses it for unit testing their JS.

And it's trivial to get started -- something that seems to lead to adoption in the modern age. NPM is really easy to use and getting a basic Node site set up is easy. There's a lot of hosting as well.

Anyway, I hope this shows why Node and Javascript will continue to eat the future, even though everyone hates it and it's a gigantic hack. Don't ever forget the wisdom of Stroustrup: "There are only two kinds of languages: the ones people complain about and the ones nobody uses".