Friday, May 25, 2012

Offsets

It's the Friday before Memorial Day weekend. It's projected to be 74 degrees today here in Boston. This reads like a recipe for people leaving work early or just not working today at all. And I can't blame 'em. I mean, really. Look at this! That's the actual park I go to (thank you Boston Public Garden).



Heck, I'd love to take a picnic and a book to the park for lunch, and totally blow off the afternoon.

Ready for the real fun of it? I'm a consultant. I CAN.

But.

Before I get to hit my patch of grass, I have to meet all my obligations for all my clients. I don't get vacation days. I don't get to blow off tasks on the grounds that my boss isn't around to notice.

So I've been working extra all week. I worked a bit late every night and got through almost everything. I'll do the last bit this morning. I pushed meetings to the morning or earlier days. I stayed up late last night writing my Friday status reports. Then, this afternoon, I'll make all the working stiffs jealous with my book in the park.

In other words, I've offset my work this week. So next time you see that slacker in the park, give 'em a wave. Maybe they're not slacking. Maybe they just already did their 40 hours (or 60 or .... you know, I don't count hours and that's probably for a reason!).

Monday, May 21, 2012

Convention and Enforcement

One of my clients is in the midst of a major architectural consideration: do they enforce rules, or govern by convention? The system as it's currently built uses convention; there is pretty much no enforcement or validation of business rules. Instead, it focuses on allowing flexibility and allowing the user to determine business rules. The problem is that the dev team spends a lot of time chasing problems that turn out to be bad or unexpected data.

Hence, the discussion. It goes something like this:
"We're having problems where data doesn't conform to our assumptions, and we're spending time tracking them down. We should enforce the rules we're assuming."
"The rules might change, and our system needs to be flexible to accommodate it. Any rule we're assuming should be considered a bug."
"Some rules won't change - we know, for example, that a widget will belong to exactly one frobble. We can enforce those rules."

And so on.

There's not really a best practice here; some systems will fall closer to the enforcement end of the spectrum, and some closer to the convention end of the spectrum. The thing to consider is this: "Who knows the rules? The creators of the system or the users of the system?" Choosing to enforce rules lessens the chance that a user is going to get themselves in trouble, but will give them less freedom to make business rule changes. Choosing convention puts the onus of rule creation and enforcement on the user of the system. Choosing convention also means that you can't make internal assumptions and then expect people to conform to them - after all, they don't know the internal implementation details. Choosing enforcement means that you have to change the system every time the business rules change.

Hours of log diving have made me lean toward enforcement of rules where we know them, but systems that use convention to enforce rules can work. Just make sure it's an explicit choice.

Thursday, May 17, 2012

Gamifying Programming?

I have a friend who is a teaching assistant in a local college. She teaches introductory programming courses, mostly to eager and not-so-eager 18 year olds. She's been working on engaging her students more, worried about the dropout rates from the Computer Science program.

So we were spitballing about the problem. And a lightbulb came on:
Let's gamify programming!

"Gamification" is - at least in the circles I move in - the hot trend of 2010-2011. Anything and everything is gamified, it seems. Shopping, fitness, training, surveys: you name it, it's probably been gamed. Gamification at its heart is simply applying the techniques of games to other systems. It usually means adding scoring or points, progress bars, leader boards or other challenges.

So let's gamify programming? Woo hoo! How would that work?

We were throwing out ideas like this:

  • Points for shorter methods (rather than thousand line methods of doom)
  • Leader boards for writing programs that accomplish their tasks faster
  • Teaching test driven development (red-green-refactor is totally a game)
It's all nice, but really, for me, programming was already kind of a game. It's just a different kind of game. Anyone remember Black & White?
Black & White was a strategy game that came out in 2001. It was a hugely ambitious game, in which you controlled villagers and a creature, and you had the power to make the creature good or evil (cue maniacal laughter here). Writing software is so much like playing that game, even without gamification elements.  Both things are immersive: I look up and discover that three hours have passed in the blink of an eye, and I have either a creature, or some new feature. It's frustrating: the game was hugely buggy, and writing code can sometimes mean intense effort to come up with.... 2 lines of code (woo too!). Both the game and the programming gives me a god-like feeling: in both the game and the code YOU made that happen (more maniacal laughter). 

I can't really get excited about gamifying software development because to me it's already fun in many of the same ways games are. Maybe that's just me.

But would you gamify programming? If so, how would you do it?

Thursday, May 10, 2012

Is "first" a Code Smell?

I was looking at some code the other day and noticed that it had a line like this:

@product.first.price

And I cringed. Not because I knew it was wrong (it wasn't). But because using ".first" feels like a code smell. (I should note that this isn't specific to the particular syntax. Seeing product[0].price would be equally cringe-inducing.)

So is the use of .first (or equivalent) a code smell?

Arguments for:

  • "first" is arbitrary and not even necessarily in a consistent order. That means it's not deterministic, which is frequently a problem. If you really want random, then wouldn't it be better to use a randomizer explicitly?
  • first means you're working with a collection, and it's inefficient to get the whole collection if you only want one.
Arguments against:
  • if you have a collection in which every element is equivalent in some way, then getting information off the first one (or any random one) is just fine. You may later need it as a collection for something else.
  • some languages have quirks where if you want one then you get a collection of one element.

I'm still not completely sure, but my current thinking is that .first is pretty much always a bad idea except in cases where the language makes you. What do ya'll think?

Monday, May 7, 2012

"No" and "Not Yet"

I work with entrepreneurs. They - like many of us - want things fast, want things great, and want things cheap. That darn iron triangle keeps getting in the way, though.


You can change the shape of the triangle, but you can't grow it. The secret thing that makes a triangle larger or smaller? Money. Microsoft's triangle is a lot bigger than Joe Startup's triangle. They're both still triangles.

So when you're a startup and you need to build a lot without a lot of money, oh and fast, please, then something's going to give. This is when the word "no" starts to come up.

But I rarely actually say, "no." Because "no" really means "never." It's pretty rare that someone comes to me with something that is technically infeasible, so "never" isn't really the right answer. Rather, I wind up saying, "not yet" or "sure, but you'll have to not do this other thing."

And that's okay. That's not me being obstructionist. That's me looking at my fixed triangle points - usually resources and sometimes time - and saying, "here's how big functionality can be". I'd rather everyone know up front that there are constraints than tell a client, "we'll try" and not finish the entire wish list.

It's not "no". It's "not yet".