Wednesday, December 16, 2009

New Relic is awesome!

We setup New Relic in production yesterday. Its awesome! If you're running a rails project of any size, I would say its an indispensable tool.

Here's a brief review:

What it has meant to us:

  • Helped us fix 2 new performance problems in 2 hours.
  • Helped us identify an intermittent performance problems that we hadn't been able to figure out for the last 3 months (that was mainly because we weren't allowed to increase log level or access apache logs, because of IT bureaucracy. NewRelic allowed us to side-step all of them).

Pros:

  • Easy to setup. All it took was to vendorize a gem and add a yml file.
  • The ability to see what action is taking the longest and what partial rendering is taking the longest and what sql is taking the longest is awesome.
  • Made for rails
  • Pretty graphs. Keeps managers busy for hours. ;-)
  • Doesn't seem to make any material impact on the performance of the app.

Cons:

  • No visibility into Java code (we run on JRuby in JBoss and have to access some Java code - which is usually the problem). I wonder if there's a way to instrument it so certain calls are visible to New Relic. UPDATE: Yeah, there is a way to see what the Java stuff is doing. It works as advertised, but not as automagically as the Rails logging. Also, we weren't able to get it to log to the same "application". Had to give it a new name.
  • Rails only as far as I can tell. It won't work for your Java or .NET project. Sorry!
  • Have noticed a couple of stack traces with "new_relic" in them. Need to investigate why.
  • newrelic.com was down for a few minutes today. That meant we couldn't stare at the pretty graphs for that time period. Will have to see if uptime is good enough for what we're doing over the next month or so

Sunday, December 13, 2009

On Maven

Maven sucks. It's evil. It makes me want to scream! Why? Three big reasons: it hides problems, it promotes the dysfunctional organization of your team and it stains to your code like blood on cotton.

I know, I know, I shouldn't be quick to judge. Any tool can be misused. Maybe if people learned to use the tool better.

Uh, no!

After spending several months working extensively on fixing (or introducing) continuous integration across industries, team sizes, geographies and levels of complexity, I have no doubt in my mind that Maven is the problem. And I swear I went into each engagement with an open mind - even towards Maven.

The first thing that hit me is that it hides all kinds of problems. I get a jar from someone else's code. Great! I keep working, everything is great. Now I want him to add a new feature. I need to upgrade to the latest version! Oh no! The two code bases have deviated too much! Lets make a rule. We need things to be backwards compatible. Lets not change API. Lets only add new methods. Oh, and maybe if I depend on a SNAPSHOT of the other person's code. But now, he can't change his code willy-nilly. We need a change manager to coordinate changes between teams.

Then the next problem hits. Hey, why are you touching that code? Its my team's code. If you want it to do that, you need to come through the change manager. Lets meet and discuss why you need to upgrade your JDK.

Then a consultant comes along and says "WTF?" - you can do all this by not having artificial divisions in teams and code bases. Lets collectively own the code. If different things need to behave differently at different times, then lets refactor the code to meet these needs. But, uh, fixing it within Maven's world is cheaper and takes less time than combining all the code. Oh, and refactor - that sounds risky! Lets just keep going with what works for now even if we're a little less efficient.

Little does anyone see that their development velocity is excruciatingly low and the incremental investment in maven over time is a lot larger than following a simpler path. And they are completely missing what they really need to be doing: communicating more, gelling as a team, and getting into a flow.

AAARRGGGHHHH!!!!