What's it all about, Alfie?

This morning I need to do some simple timing comparisons for the Salesforce Team here at The Shop so they can push this back to the Salesforce.com guys and ask what's going on. I'm taking the overnight runs of Production and UAT hitting the production and staging sandboxes, respectively, and comparing that to running the UAT hardware against the new API sandbox, and simply comparing times for actual runs.

At the same time, I'm gathering some DEBUG logging information for NewRelic as their newrelic-rpm 3.5.0.1 Gem is not sending back to them the method call instrumentation data in jruby-1.7.0 that it is in jruby-1.6.7.2. I know this because our NewRelic graphs go silent the same instant we moved from 1.6.7.2 to 1.7.0. However, we do get the CPU usage and the memory usage and even the deployment markers - so I know we're sending something, but it's just not sending the right instrumentation data.

So they asked me to send them a DEBUG log, which seems really reasonable. So I'm getting it as I'm doing the final UAT-to-API timing test.

UPDATE: they have sped up API significantly from yesterday. Whatever they did - it's working and that's OK with me.

This morning I noticed that Google Chrome dev 24.0.1213.1 was out and the big change appears to be in the new WebKit (537.17) and a bunch of fixes related to the bookmark syncing and stability issues. I have to say that I really like the new look of the blog as it's much cleaner than the old, and it's also nice they are moving along with WebKit updates.

Good news.

I really don't like the "shortcuts" a lot of people put into code. They don't really make it more readable, and they certainly make it a lot more brittle. Case in point, today I realized that the code in a rule was written:

  if days_since_assignment && days_since_activity
    # do something
  end

where these variables/methods are nil for those times when there is no respective date. This seems OK, but it's really not. In order to do a good, robust, check, we need to see if it's not nil and then check the value or include it in an inequality. There's no other way.

Now your typical Ruby Code Monkey will say "No! That's not the Ruby Way!" and they'd be right, and the Ruby Way is, in this instance, horrible for so many reasons.

I'm a fan of making things comparable wherever possible, and that means get rid of the nils. Make it simpler - use Float::INFINITY for the return value of a "days since" method if the date doesn't exist. At least that way, it makes sense in all comparisons, and it's at least no worse in some edge cases for testing values. Most often times, it's exactly what you want.

So I had to go in and change what appeared to be "working" code to something that actually worked as intended all because of this desire to minimize typing. Had the original author said:

  if !days_since_assignment.nil? && !days_since_activity.nil?
    # do something
  end

then at least it would be clear what was going on. Returning an INFINITY now makes it clear that we're never going to fail these checks as a nil is never a possible value.

It's all this maturity that I see missing: no comments… minimal typing… over the top refactoring… fascination with new and shiny things… I believe these guys could be great, but they limit themselves and they don't have to. They can see what they should be doing, and they even know they should be doing it. But they choose not to.

I wish they didn't make that choice.

This morning I come in to see that we're horribly behind in processing the UAT divisions! The new Salesforce sandbox is a joke! I've got to trim back what we're doing in UAT and get the Salesforce Team on this because we can't let this go on… it's simply unusable.

UPDATE: it took 16 hours to finish this run! That's up from about 3.5 hrs last night - all due to the new Salesforce sandbox. This can't stay this way… I'm moving UAT back to the Staging sandbox as it had decent performance.

This afternoon I had to move our development and UAT environments to a new Salesforce sandbox. This one is supposed to be the place we'll be doing our development and releasing code to the Salesforce Team's promotion process, so it made sense to get it right and just do it.

The process wasn't hard - I've got it all documented from the last time I had to do this, so it went pretty smoothly. Just needed to get it done.

I've been thinking a lot about a conversation I had with my manager about producing versus well thought-out design. He seemed to think that it was a trade-off, and the more I think about it, I think he's wrong. Oh sure, there are tons of trade-offs in engineering and software development, but there isn't a trade-off in putting out good code every day, and doing it "right". There can't be.

If I'm putting out a bunch of features in a day - every day, then they can't be hacks, or some day they are going to catch up with me and make it impossible to go forward. That's not sustainable. What is sustainable is to make sure that you're writing good code… well thought out code… but you're doing it like you mean it.

For example, today I had to go through a lot of code written by one of the Code Monkeys that was really slapped together and included no documentation at all. It was a rules system and it wasn't working cleanly because the methods were quite the rules, and they weren't quite the factors of the rules, so there were nasty dependencies, etc. that made it very hard to figure out what was happening and how to fix it.

I had to clean it all up, make the methods either condition checks or rules, and all rules simply were collections of condition checks, had to clean up some of the tests based on the logging strings, and in general, just make it a lot cleaner.

This didn't take me long, and it took me a lot less time - even under pressure of fixing bugs, then it did to create it by the original author. So it's not about the time required, it's the actions that are taken.

There's no trade-off here. You have to be good at what you're doing or you're going to make a mess. Period.

This morning I'm still getting used to the OS X 10.8.2 changes - specifically, Notification Center. This is clearly a take on Growl, and as a long-time user of Growl, I know there are apps that are only recently Growl 2 compliant, so I really doubt they are wired into Notification Center. Thankfully, there's a mode in Growl to ship all notifications to Notification Center. But there's a catch…

All notifications that are redirected from Growl come into Notification Center as Growl notifications. That's no good. You loose at least half the really useful information in this. You need to be able to tell what app sent it, and then what the message is. Thankfully, someone thought of this and created Bark.

It's a Growl 2 plug-in, and it requires OS X 10.8 Mountain Lion, and it redirects all Growl notifications to Notification Center - leaving the application intact. You simply download it, install it, and then set the 'Default Action' to be 'Bark', and the 'Default Style' to 'No Default Display', and you're done!

I'm hoping this is going to do what it says it does, but I haven't seen any notifications come through, but I've got my fingers crossed, and I'm hoping this works exactly as advertised.

This evening I decided to update my main laptop to OS X 10.8.2 Mountain Lion because it's about time and I think they've got the vast majority of the bugs worked out, and it's ready for prime time. I'm not exactly certain how I'm going to feel about it… I've heard good things and bad, but it's where Apple is going, as with Xcode 4, and I need to just realize that it's time to get with it and make the move.

I will say that I'm a little nervous, but I'm sure it'll all work out in the end.

UPDATE: it took about 40 mins to download and another 30 mins to install, but it's working so far. Lost all app positioning and startup, but that's not totally surprising. Working well - so far.

I can see when code has been lazily copy-n-pasted and not really incorporated properly. I can see when coders leave in hard-coded values when they thought they were changing things out. It's not all that hard. This morning I've been doing quite a bit of this kind of bug fixing. It's not all that hard - it's pretty easy stuff to spot, but it makes me sad for the guy that wrote it, because I'm not going to see him in the same light as I had.

Also, comments would be nice when I'm digging in a new web framework (Sinatra), and I really need to get up to speed on these Ruby web systems sooner rather than later as it's going to become more important to me that I'm able to write these - as opposed to just bug fixing them.

I suspect they just don't care, and aren't motivated in the least to care. So I really have to try very hard not to think it's who they are - just how they are responding to the job.

I know I've written about my lack of understanding with the apparent desire by Ruby devs to write no comments, but today I officially said out loud: "This is my grown-up Christmas wish: Comments in the code", and I really mean it. I was in the middle of trying to figure out a Sinatra app, and the entire file had one comment, and it was a TODO: as opposed to mentioning what the code was actually doing.

I think I have an idea why this is the case… face it, comments can "ruin" the look of code. It spoils the "line" and "flow" of the code. The only reason they are there is to save time for the developer trying to understand what's happening. But suppose you had a developer that didn't care about the time it took to understand the code?

Then you'd have a person that didn't like comments.

It's not about caring about the "next guy". It's about the beauty and ascetic of the code. And if you simply don't care that it takes you more time to figure things out, then there's no downside. I didn't understand - until now, that it wasn't that they were lazy… it was that they simply didn't care about getting things done.

Certainly not in comparison to the style and look of the code.

Which explains so much.

Why is it that there's so much ping-pong and pool played during regular hours? Well… if you're not concerned about delivering things, this is easy - you have friends here, and the table is right there. It makes perfect sense when you realize that they just don't care.

But Why? That's the biggie, right?

I have a theory, and it's based on a conversation I had with someone here. The focus is on sustainability. If you want to keep people at a position, you pay them well, staff the projects well, and expect a moderate amount of work from them. This allows them time to learn, grow, and rest - while getting a little work done. Consequently, they don't see "management" sweating about a few lines of code… or a few hours to re-learn what it's doing. So no big deal.

This might be the wave of the future, I have no idea. But it seems to me that in comparison to the other places I've worked - including my own company, this is only sustainable as long as they have money to burn. When money gets tight, they will expect more for less, and then things will have to change. At that point, there may be such an entrenched culture, it's impossible. No way to know.

I just know what I want for Christmas, and have a feeling I'm not going to get it...