One hour from now...

So, I'm a long-time Java guy, wading into Ruby/Rails and really liking it so far. I know most of you who have made the transition are already aware of how much nicer many things in RoR-land are, but I thought I'd start just collecting a series of posts on my own personal findings. Just 'cause.

Case in point, this morning I was writing a unit test in Java, and needed to use two dates in my test code, one that was further in the future than the other. In Java, this looks something like this:

Date now = new Date();
Calendar calendar = new GregorianCalendar();
calendar.setTime(now);
calendar.add(Calendar.HOUR, 1);
Date oneHourFromNow = calendar.getTime();

I know I don't need to explicitly set the calendar to 'now', however, I use the 'now' reference in the tests, so it seemed to be slightly more correct and explicit to do so. Further, the only reason for this setup code is to use the now and oneHourFromNow references in my tests.

In Rails, I would simply reference:

Time.now

when I wanted to get the current time, and then use the nice time-related functions that Rails adds:

Time.now + 1.hour

when I needed a time that was in the future. If I wanted the exact same semantics as the Java code, I suppose I could do this:

now = Time.now
one_hour_from_now = Time.now + 1.hour

but that doesn't seem to add much in the way of comprehensibility, so I'd likely skip that altogether.

So, in reality, what would take me five lines of code in Java, essentially takes zero in Rails, which, as I calculate things, is infinitely better.

Startup CTO mistakes I'd rather not repeat...

I write this as I am seemingly on the cusp of getting involved in another startup, one way or another. Either the game I'm working on will start making money, or I'll get dragged into one of the many projects my friends and acquaintances are dreaming up. So now seems a good time to reflect on some of the bigger mistakes I've made, and in the process hopefully avoid repeating them.

Now, we shouldn't be too hard on ourselves for making mistakes. In all of my personal, educational and business pursuits, I have yet to see a method of learning that doesn't involve making some as part of the process. This is a reality I'm trying to impress upon my seven year old daughter, who has somehow gotten into her head the notion that she should be able to do anything she sets her mind to the first time she tries it, and will typically go into hysterics upon discovering that it's not that easy. She's starting to get the idea, and she's starting to recognize that laughing at your mistakes, owning them, and moving on is a lot better than wasting a bunch of time crying over them.

That said, with mistakes as the basis for learning, I learned a lot at my first startup. What follows are just a few of the highlights. Enjoy!

Not getting involved in "the business"

This seems to be far and away one of the bigger mistakes I've made; assuming that the "T" in the title somehow absolves the Chief Technology Officer of worrying about or considering much what "the business" is doing. In reality, there is no "business side". Chances are good the technology is the business. The CTO needs to be on top of what marketing has up its sleeve, what countries/demographics/markets/opportunities the CEO is dreaming about, what the CFO thinks of the IT budget, never mind the fact that HR is dying to get an intranet going. If you don't touch base with these people regularly, and become part of helping them achieve their plans, they'll find ways to get things done without you. And it's almost guaranteed to be in a fashion that's not in alignment with your technology vision. About that...

Keeping the technology vision in your head

While there's a lot of conflicting opinions with respect to what the CTO role actually involves, it appears there is some consensus that evangelism is part of the role. Do you see your niche product actually becoming the platform for your vertical or beyond? Do you see your company's expertise in a particular technology being leveraged beyond the confines of its current product or market? Well then tell somebody. Tell everybody. A typical reason for not doing so is the ever-present product backlog. "There's no point talking about our technology vision, 'cause we won't be in a position to fulfill it for two years and I don't want folks to get distracted", you might tell yourself. Know what? You're wrong. You won't get around to it ever with that attitude, because it will never become part of anybody's reality unless you make it so. Besides, two years from now your product backlog will be even bigger.

Adopting bleeding-edge technology

So, back in the day (around 1999 or so), I really figured part of being a good CTO was finding that heretofore-unknown-but-up-and-coming piece of technology that would give you The Edge over your competitors. You know, that magic, silver bullet that would run 10x faster and enable 10x faster development cycles. So I went out and got us an object-oriented database.

The result? Well, I did think that it enabled slightly faster development times. There were significant caveats, however. Using their easiest "transparent" API meant that all servers in the cluster had to run the latest schema (no incremental deployment for you, my friend). Further, online backups were problematic, and we really loved it when the database server needed a restart and would come up in "recovery" mode with no progress indication, staying that way for a half hour or so.

Details aside, think twice before looking to fancy technology as a core piece of your strategy. If you think you need it, at least try to sandbox the financial and technical risk.

Giving up control of the development process

Some CTOs operate solely as a "technology visionary", and operate from the sidelines, much like a cheerleader (see "Model 2: CTO as Big Thinker" from The Role of the CTO: Four Models for Success by Tom Berray). However, I find Eric Ries' comments more in agreement with my own experience. As a CTO, it became much harder to drive product and technology innovation once I shifted managerial responsibilities sideways.

Staying too hands-on and not getting hands-on enough

This is a tough one to get right. Right up to the point where I had a team of about thirty people, I could still write a little code, and assist with design of every major feature. But that was pretty much the breaking point. However, as I tried to teach myself to let go, inevitably some features made it out the door in, let's say, a less than desirable state. I chalk this one up to focusing on the wrong things. I had focused on the product too much, and didn't spend enough time with people and process. As a CTO, it's important to stay somewhat hands-on. Write a little code. Do a little design. But choose wisely, and use each of these hands-on efforts as an opportunity to teach and mentor. Let your team make some mistakes in the early days, but more importantly, have a process in place that makes recovery easy and automatic.


So those are five fairly big mistakes I hope not to repeat. Maybe you've made some of the same ones. There are, of course, many more. Stick around!

Scrumy update...

I sent my comments in to the Scrumy guys, and Dan responded by saying "We converted your seven bucks into 17,276 Colombian Pesos and we're swimming in it Scrooge McDuck style, thanks for upgrading!" Now you know how developers spend their hard-earned money. Anyway I'm impressed that Dan didn't just make the number up and actually converted seven bucks US at the current exchange rate.