Inter-sections.net : Category technology, everything about technology

Technology recruitment in an early start-up

Wed, 03 Sep 2008 13:00:00 +0000

So, you have an idea for a startup, but need a tech guy to build it… how should you find him?

Last week I ripped into a job advert with, I hope, some good comical results. Some people asked, more specifically, what I would do in Redline’s place (Redline was the company that produced the advert). How do you make that first technical hire?

Of course, you want the company to sound personable and friendly, and that was probably the noble impulse that drove the poor anonymous job ad writer to write that awful ad. A formal, stiff job ad is indeed not going to attract good early employees - let alone a start-up CTO, which I believe is what they were trying to hire in this case.

First of all, let’s define our terms a little. Everyone has different terms for these things, but there’s two general stages to recruitment of technical guys in a really early start-up (one with fewer than 10 techs). Please note that when a company grows beyond that size, things shift and evolve. This applies to very small technology start-ups only and, as ever in the start-up world, there are and will always be exceptions.

The CTO

The first person that needs to be recruited is what I call variously the start-up CTO, the technology director, or the technical co-founder. For a technology start-up whose bread and butter will be developing a technical product that people will want to pay money for, this “hire” is the most important that the founder can make in the entire history of the company. Here, I’m assuming that the first founder is non-technical or not technically strong enough.

Strong enough to do what? Well, to develop the whole product by himself! Wait a second… can anyone develop a whole product by themselves? It depends on the product. I’ve done it. My best friend is doing it now on his own start-up. My current start-up employs only two people to build our product. So yes, it is possible, if you’re using the right technologies and if you’re building the kind of product that is amenable to being built by a very small team.

You might decide to hire more than just this guy, even though he can build the whole product by himself, in order to speed things up a little. After all, if your cofounder can write the whole product by himself, but it will take him 3 years to get to version 1, that’s probably not good enough. But you won’t be struggling to hire his team - he’s more than capable of doing that himself. Ah yes, that’s another thing a start-up CTO needs to be capable of: finding and attracting other technically talented team members to joint the start-up.

What else? Well, he also needs to have a good head for business, to understand where the start-up is going and be able to pick the technologies to meet those goals. He needs to be capable of working with maniacal productivity despite the chaotic, highly constrained environment of an early start-up. He needs to have enough managerial skills to manage the early start-up team once it comes into existence. What you (as a business-minded founder) might be doing for the business, i.e. pulling the entire thing from a mere idea into existence out of your sweat and determination, he needs to do for the product.

It’s worth emphasizing here: I’m not saying this guy will build the whole product by himself, only that he needs to be able to do so if need be.

He’s a One-Man IT Department. He’s the person on top of which you’ll build your company. He’s not a rock star. He’s a rock, and on this rock you can build your company.

The early employees

Early (technical) employees also need to be very competent, flexible and driven, but less so than the technical co-founder. They can specialise a bit more, and can focus on getting things done without quite so many business distractions. It will be the CTO’s job to figure out what technical skills are needed to continue to grow the start-up, once there’s budget for other people, and to find and hire the right people to fill those holes.

Early employees do need to be willing to have a go at whatever needs to be done at the moment. If it’s network administration that you need to do today, so be it. But they don’t need to bring all those skills to the job - it’s something they can learn from their colleagues, from howto’s downloaded from the web, books, etc.

As a start-up CTO looking for early employees, you should look not for someone who can do your job, but for someone who is reasonably well rounded and flexible, but more importantly is better than you in one of the key areas that really matter to the start-up.

Where to find them

So, where do you find these rare and wond’rous creatures? Let’s start with the CTO. Most important hire in the company. Defines the product that you will build. Is a job site a good place to look for one of those?

Of course not. You find technical co-founders the same way you find any co-founder: through personal relationships. If you want to start a technology start-up and you’re not technical, you need to locate your technical co-founder amongst your network of friends, and if there isn’t one there, you need to expand that network until there is. Until you have found your technical cofounder, your company cannot be started (at least not with any reasonable chance of success). Maybe there are even better ways of finding co-founders, but I don’t know them. Paul Graham’s experience seems to agree: “Usually the founders have been friends for at least a year before starting the company.”

I’m sorry if you were expecting a simple, easy answer, like “Go on find-a-CTO.com”. In my experience, the kind of people you want as technical cofounders are either doing it already, or productively employed. Finding your technical co-founder is hard work, but the pay-back from this work is huge.

What about early employees? Well, those are a little easier. At least, you can let your CTO do most of that job. He or she should have the network to find the people that he wants to hire. There, as well, I’d recommend networking as the primary means of finding great people to work with. However, for early employees, in some rare cases, you might use a carefully constructed job ad to fish for possible hires. Bear in mind, though, that at this stage, it’s usually better not to hire anyone than to hire the wrong person.

Taking on a cofounder: final note

One last note on cofounders: you can’t treat them as employees. They’re not employees, they’re cofounders. You want them to feel that it’s their company, and to do that, you have to give them equity - not options, not promises of options, but actual founder’s equity. Don’t feel like you’re giving stuff away here. If you’ve got the right person for the job, ensuring that they feel ownership of the company will ensure that your share is worth something. It’s better to own 70 or 80 or even 51% of something than 100% of nothing.

I hope you’ve found this post helpful! Comments are, as always, welcome.

How not to write a job advert

Sat, 30 Aug 2008 01:00:00 +0000

Recently, I found a Craigslist job advert that made me chuckle. It seems to manage to do almost everything wrong, from the point of view of recruiting the kind of person it appears to be targeting.

So, in the spirit of improving the web, here’s my blow-by-blow description of all (or most of) what’s wrong with this job ad.

Here’s the advert, first, in case it’s taken down:

Senior Rails Developer (Toronto)

Reply to: jobs@redwirenation.com [?]
Date: 2008-08-26, 9:12PM EDT


Working Role Title: Senior Rails Developer 

Why People Want To Work for Us: RedWire Employees Are Rockstars 


Enabling Entrepreneurs To Connect on a Global Scale 
As far as missions go, ours is pretty cool. How many people get to say their job is to help others be successful? 

Innovating at Warp 9 
We are a small company, but we are driven to change the world. Our reason for being is to help entrepreneurs realize their ambitions. We are innovative, relevant and user-friendly, and we use these qualities to equip business owners with the tools they need for success. 

Fun-zilla 
Working for RedWire means being passionate and creative. We want awesome people to work with who will be contributing members of our team of rockstars. 

The top three reasons why working at RedWire rocks: 

1) You get to do good. People helping people—it’s a beautiful thing. 
2) Brainastics, whiteboards, candy and lots of coffee. Sometimes we have to remind our employees to go home. 
3) Flexible work hours. We don’t do “9 to 5”. 
Nuff said. 

We realize that a start-up environment doesn’t appeal to everybody, but if it works for you, then, please, read on. 


Current Needs: 

¼ Network Engineer 
+ ¼ Electrical Engineer 
+ 3⁄8 Senior Open Source Software Developer 
+ 1⁄8Mathematician 
= 1 RedWire Senior Developer 

We are looking for an in-house doer-thinker-fixer-betterer whose superpower is to fulfill all the functions of an IT Department. We need an autonomous and resourceful guru to join us in our quest and manage all things IT. You must be ridiculously passionate about the web, love the idea of working in a start-up, enjoy variety in your day-to-day and be able to handle the stress of being the go-to resource. 

Role Overview: 

This is a pivotal role for an ambitious, highly enthusiastic developer who’s excited at the thought of working in a fast-paced, high-growth web start-up. 

In this position, you will demonstrate your mental prowess as you coordinate a diverse flow of projects and initiatives. 

You will be responsible for: 

- Web application development 
- Network administration 
- Information storage 
- Network functionality 

In addition, you will also be responsible for helping set up email distribution, as well as any other relevant technically related projects as they arise. 

We are looking for a goal-oriented, naturally eager person who can work effectively and efficiently under tight deadlines and who is able to manage multiple projects at once. 

Qualifications:
• Provable guru status and devoteeism of Ruby on Rails with experience actually deploying applications 
• Strong experience with MySQL, version 5+ and beyond 
• Background in developing and optimizing GNU/Linux, *nix, and *BSD platforms for mission critical production environments 
• Familiar with network infrastructure and design concepts for small networks (<25 machines). 
• Proven experience in designing security-hardened web applications, using open cryptographic standards 
• Familiarity with hardware prognostics and normal accident theory 
• Expertise in open-source programs and development 
• Familiarity with content versioning systems (e.g., Hg, SVN, CVS) 
• Experience breaking stuff 
• Experience fixing what you’ve broken 

If you are the personification of our long-winded wish list, then we’d celebrate your email’s alerting us to your existence. Interested potential rockstars should send their résumé to jobs@redwirenation.com.

Right. *cracks knuckles* Let’s get started, shall we?

Rockstars helping people for brainastical whiteboard candies

The first problem: Why people want to work for us: Redwire employees are rockstars.

Really? Ok, I’ll sign up, but I want to get some free tickets to their concerts. Many employers still feel like calling future employees rock stars or ninjas is going to attract better developers. Here’s some news for you: most of the great developers you’re interested in can’t stand the term “rockstar programmer” (or ninja, or whatever alternative you may care to come up with).

Next: How many people get to say their job is to help others be successful?

Well, let’s see… off the top of my head, every single employee in the world? By definition, employees help others be successful. That’s what “having a job” means. Most people who join start-ups do it because they’d also like to help themselves be successful somewhere along the way, or because the work is more interesting. In any case, if you want to excite start-up developers, you’re gonna need a better “mission statement” than that (ideally, just scrap the mission statement altogether).

Fun-zilla

Well, nothing says fun like Fun-zilla, right? Who are you trying to hire? 10 year olds?

“We want awesome people to work with who will be contributing members of our team of rockstars.”

*puke*

Top three reasons:

1) You get to do good. People helping people—it’s a beautiful thing.

Oh puh-lease, I’m getting all teary-eyed already. Of course. How could I not see it? Tell you what, it’s such a beautiful thing, I’ll work for free too. Every start-up believes their goal is the best, the most worthwhile of them all, but your job in a recruitment ad is to convince other people who haven’t drunk the kool-aid that that’s so. This kind of vague nonsense isn’t going to help.

2) Brainastics, whiteboards, candy and lots of coffee. Sometimes we have to remind our employees to go home.

Translation: long hours, no concept of work/life balance. That’s acceptable for a start-up (though perhaps it shouldn’t be), it’s understood that you may work long hours on a start-up. But you shouldn’t brandish that about as a key selling point for your company, much in the same way that someone who’s changing jobs might be doing so because their current job sucks, but they probably shouldn’t say it outright in the interview. And since when are whiteboards a perk?? What’s next? “Our state-of-the-art office premises include a quality toilet seat”?

3) Flexible work hours. We don’t do “9 to 5
Nuff said.”

Normally, that would be fine, but in conjunction with the previous statement, it’s highly suspicious. “We don’t do 9 to 5” could just as easily mean “We do 10 to 10”, in this context. Nope, not “enough said” - more detail would have been preferable.

One cup of flour, two cups of milk, two eggs

1/4 Network Engineer
+ 1/4 Electrical Engineer
+ 3/8 Senior Open Source Software Developer
+ 1/8 Mathematician
= 1 RedWire Senior Developer

Oh boy. Maybe add another 1/32 janitor while they’re at it? What the heck is up with the /8 fractions anyway?

We are looking for an in-house doer-thinker-fixer-betterer whose superpower is to fulfill all the functions of an IT Department. We need an autonomous and resourceful guru to join us in our quest and manage all things IT.

Ok… so, what emerges here, is they’re looking for a CTO. That’s what a CTO is - a one-man IT department. But either they can’t afford one, or they haven’t figured out that’s what they’re looking for, or they don’t know that hiring a CTO in a company like that is the most important hiring decision in the whole history of their company (and should be achieved through intense networking, not through free job ads). Or perhaps, more likely, they just don’t really have a clue what they want, beyond the fact that it’s someone who knows stuff about IT.

In this position, you will demonstrate your mental prowess as you coordinate a diverse flow of projects and initiatives.

You will be everyone’s IT bitch.

…ambitious, highly enthusiastic…

And you will enjoy it!

Responsibilabilities and Qualifimications

You will be responsible for:
- Web application development
- Network administration
- Information storage
- Network functionality

Wow is that it. Oh wait, you’re not finished. Please continue.

In addition, you will also be responsible for helping set up email distribution, as well as any other relevant technically related projects as they arise.

Didn’t we cover this already? If you want someone with that breadth of skills, you’re hiring your CTO cofounder. And you better give them equity - lots of it. And you will never find them via a craigslist job ad. Also, what the heck is “Information storage”? Does this “Senior Rails Developer” also have to manage the shared drive, perhaps?

Provable guru status and devoteeism of Ruby on Rails with experience actually deploying applications

Devoteeism? Guru status? Come on, I need some lines that I can make fun of. This is so self-contained, I can’t possibly make it any more ridiculous than it already is.

Proven experience in designing security-hardened web applications, using open cryptographic standards

What does that even mean? My guess is, it translates to “is capable of setting up an SSL certificate on apache”.

Familiarity with content versioning systems (e.g., Hg, SVN, CVS)

Is it even possible to be a “Ruby guru” and not be “familiar” with source control? Another hint that the person who wrote this job ad doesn’t know what they’re talking about.

Experience breaking stuff
Experience fixing what you’ve broken

It’s always a good thing to let your company’s personality show through your ad. Well, not always, I guess. Not in this case, for example. After this litany of unintentionally awful propositions, this “joke” doesn’t really go down well.

In conclusion

Now, it’s possible that actually, Red Wire is a perfectly fine company, and they just happened to get someone’s friends sister to write and post up the job ad because they were too busy and, heck, craigslist is free anyway. But this is a terrible impression to make to prospective start-up employees and, if they indeed lack a CTO, it’s no way to hire one.

If you’re in a position to hire technical people for a start-up, try not to make quite so many mistakes.

Making money off facebook

Wed, 27 Aug 2008 12:00:00 +0000

Here’s an article from VentureBeat waving about some figures about how much money can be made with Facebook apps. Although the figures are a bit anecdotal, and I hope for their sake that no VC’s ever invest based on such hand-waving mathematics, the real gem is at the end:

Either way, the many naysayers suggesting that it’s impossible to make money on Facebook might want to think again.

I don’t know if anyone’s ever suggested it’s _impossible_ to make money from Facebook. The main backlash against Facebook applications as a business model has really been against the gold rush mentality of the early Facebook app “golden age”. In those days, the mental processes went a little bit like this:

Facebook has lots of users
Facebook is inherently viral
If I make a Facebook application, it will be easy to reach millions of people
An application that can reach millions of people is bound to make money.

That’s a nice story, and it explains why some many people (myself included) rushed into Facebook application development last summer. Since then, most of them have pulled out, and for very good reasons.

Facebook became much more protective of its users (and quite sensibly). A large part of the changes to Facebook in the last year have been to protect its users from over-greedy and spammy applications
Many changes entirely nerfed the virality, making it much, much harder for an application to magically spread from 10 users to a million within a few weeks
Therefore, it’s become very hard to reach any large number of people on Facebook
Even applications that did benefit from the early “golden age” conditions didn’t manage to make that much money. Their business models are still being proven. Slide and RockYou may have a few very successful apps, but they also have many developers, and it’s unlikely that their Facebook revenues cover their costs yet (though I’d love to hear some hard numbers on that).

The truth is, yes, it’s possible to make money with a Facebook app. But, and this is the key, it’s no easier than making money with a non-Facebook app. In many ways, it’s harder. Working with the Facebook platform and its many limitations is a challenge in and of itself. Even if you’re a consummate start-upper outside of the Facebook bubble-world, you’ll have to learn application development all over again in this new, different environment. That’s not a huge deal, but it should give pause to people who think they can just “make a Facebook version” of their otherwise successful application.

More importantly, building a Facebook application puts you in the thrall of Facebook. That is a huge deal, because Facebook is their own business, and they will always do things to their own advantage, even if that involves doing something that will completely destroy your business. The internet is fickle enough as it is. Do you need the extra risk?

Perfection does not exist

Mon, 19 May 2008 12:44:00 +0000

1. The idealistic path to ‘perfection’

You’re sitting at your desk, alone with your idea. Or perhaps you’re with some friends or colleagues or both. This is a great idea. You’re excited! Now all you need is to implement that perfect vision, and you will become rich and famous.

You’ve heard that ideas are nothing without implementation. You’ve heard that ideas are a dime a dozen, you know that what will make or break your idea (and your business along with it) is how well this idea is implemented. The devil is in the detail, and you’re going to make damn sure that every detail is right. All you need is to make something people want, to make it the best damn implementation out there, and you’ll be laughing all the way to the bank!

Unfortunately, there’s a fatal flaw in your plan: you and your brilliant idea. You, I’m sorry to say, don’t have the first clue what your users really want. Oh, you have some vague idea — and at this stage, a vague idea is a pretty good start — you know roughly where you want to go, but the truth of the matter is, if you took your vague idea, concretised it, and implemented it perfectly as it is currently in your head, it would be a very, very bad product, a monumental flop. This is true whether you have detailed knowledge of the business domain, are a technical expert, or both.

The real “perfect” implementation is somewhere else. This is easily illustrated by the following diagram:

Even if you can go from A to B directly and perfectly, that won’t do it, because, in fact, you want to be at C, but it is impossible for you to have any idea where C is.

2. The practical path to ‘perfection’

I’m sorry to say, but there’s another flaw with your plan: you again! You’re not alone in this one, though: your whole team is guilty! Real projects are fickle, difficult things. It takes all the willpower and social skills of a competent project manager to keep them aiming roughly in the right direction. Even then — especially if you’re lucky enough to be working with very smart people — there will be many side-steps, jumps and skips along the road. These are all perfectly natural and to be expected.

You will discover new things along the way, and that’s a good thing! Those will shift your end goal, and they will shift your direction too. By the end, your history of targets will be spread over a large area.

Your path to your end point(s) is likely to look something like the following picture.

On the good side, this means that your product will be more practically consistent. On the bad side, there’s no telling whether those changes will actually bring you nearer to perfection. Consistency doesn’t make or break a product. Users do.

3. The use(r)ful path to ‘perfection’

What a disaster. Not only you don’t know where you’re going on a high level, but you also don’t really have a clue from week to week. Surely there must be a solution to this quandary. Someone in the world can tell you what the perfect product is. Just hire them and you’ll be sorted.

Problem is, you can’t hire them. The only people in the whole world who can tell you where your product is going wrong are your users. The minute users get into the equation, you suddenly have some way, as uncertain, fickle, and vague as it might be, to tell whether you’re going in the right direction. You need them to provide you with timely, accurate, effortless feedback throughout your development process.

If you followed my tips and released a beta, or even alpha, and listened to your users, your path might look a little bit more like this:

And if you do this, chances are, you will probably turn out a pretty damn good product.

4. But… perfection does not exist?

Now, you might point out that I’ve made a pretty good case for why perfection is very hard to achieve. However, what I haven’t yet done is to explain why perfection doesn’t exist.

There are two good reasons why a perfect product doesn’t exist.

The first one is that there is an enormous variety of users out there. What’s perfect to one will be unbearable to another. You can, with some uncommon concentration of talent, build something that’s almost perfect for a lot of people. Apple have done it. Google have done it. And there are many other unsung heroes (though none seems to be quite as consistent as Apple), delivering fantastic products that are almost perfect for almost everyone. But every single one of these products is flawed in some ways for some people. In this sense, “perfection” is meaningless, a red herring. There is no perfection, only a good fit for a common denominator.

The second one, much more vicious, is that all those diagrams tell a pernicious lie. They completely hide the vicious, dynamic, crowded, unpredictable nature of the marketplace of desires, of what people want and how they want it. People’s needs change. Trends change. Impressions, desires and public perceptions shift each and every day.

Even if you could build a product that would hit the sweet spot in everyone’s heart and feel just perfect to your entire target market, that sweet spot will shift, implacably relegating your ‘perfect’ product to the dustbins of time. In short, even if perfection was theoretically possible, if you built a product that was perfect today it would be imperfect tomorrow.

5. What to do about it?

The main point of this article is to convince you to stop chasing perfection as a concrete goal. Striving towards building the best possible product is a good goal. Striving towards building a perfect product is an illusion, and a dangerous one at that. Striving to achieve perfection (or its sneaky twins, excellence and near-perfection) every step of the way is a deadly mistake.

Once you make it your aim to “build the perfect product”, you find yourself paralised by lengthy design work, longer iterations, and significant periods of “making the features perfect” without releasing anything to the users. This can and probably will kill your startup. Don’t make that mistake.

A much better modus operandi is to aim to move forward a little bit at a time, to build small increments of functionality that you can show to users as soon as possible. This, incidentally, is also the way agile projects are supposed to work (but often don’t). Aim small, shoot often, re-adjust each time. You need to influence the culture of your project so that it’s ok to make mistakes, and to make them often. A development model that allows lots and lots of cheap mistakes is far superior to one that tries to achieve perfection at every step, and thus makes each mistake very costly.

My own projects have fallen into this trap regularly, so I think it’s not an easy one to avoid. In the contagious enthusiasm of having built something that users love it’s easy to fall into the perfectionist pattern and decide that because the users like the system now, we need to ensure that they like every single release of the system. This even applies to other things than products. It takes a lot of discipline to fight that behaviour and say something that may well resonate, to your coworkers, as “let’s build crap”, but in fact means “let’s just release something quickly, no matter how bad it may seem, and see what the users think”.

But if you want your product to succeed, it must be done.

13 Tips for creating a successful new online product

Wed, 07 May 2008 14:27:00 +0000

There is much talk these days about building a product for a niche and making a lifestyle business out of it. Much of the online literature about starting up is focused on how to create some fantastic product which will gather millions of visitors and make you a billionaire, and the “new wave”, so to speak, proposes that rather than taking a 1 in 10’000 bet that you can make billions, it is better to take a 1 in 10 bet that you can make millions.

Since I have started two such businesses already, here are thirteen tips from my own experience.

What to build

1. Build for someone specific

It’s very tempting to create a product for the widest audience. “Everyone can use our product, therefore if even a tiny proportion use it, we’ll be rich!” Beware the generalised product. If your product is not built for anyone in particular, it will not be good for anyone in particular. The worst possible market for a product is “small businesses on the web”.

On the other hand, if you build something that is directly useful for even just one real human being, chances are there will be others like that user and your product will have some success.

2. Don’t be afraid of targeting a narrow niche

Niches have numerous advantages. There’s less competition in niches, which means that your marketing dollars will go further to get you new customers. It’ll be easier to target likely buyers since there are probably already channels (blogs, magazines, trade shows) targeting that niche, that you can make use of.

Niches also tend to be very badly served in today’s world. If you look into almost any niche you will find a plethora of awful products that are just begging to be replaced by something better suited. Being able to build great products cheaply is a fairly recent development, and most pre-existing businesses have had to make do with duct-taped, poorly conceived solutions that are begging to be replaced. The smaller the niche, the lower the bar to success.

3. Solve a real problem that costs money

As DHH pointed out, the way to realistic profitability is not through gathering an outrageous number of eyeballs, but through creating a product that people are willing to pay for. The easiest way to get someone to loosen their purse strings is to convince them that using your product will pay for itself.

This can be either by enabling them to do something new to earn money or by saving them time and effort (and hence money).

How to build it

4. Test the market with a working prototype as soon as possible

To win in this game, you need to build a great product. The problem is, no one on your team can tell you what the best product is — only your users can do that. You need a vision to get started on a product, but that vision is critically flawed in ways that you can’t see. User feedback is the most powerful force to point out those flaws, and until you have users (whether free or paying), you cannot use that force.

For this reason, it is important that you release something, anything, as embryonic as it might be, to people who can start to use it and let you know what you’re doing wrong. Listen to your users — and, to do this, give them a chance to tell you.

5. Develop iteratively

Your product is ambitious. It will solve many great problems for your users. However, if your product never gets finished, it will solve nothing. Be ambitious in your dreams, but conservative if your immediate goals. Aim for the result of each iteration to be useful in and of itself, but keep each iteration as tiny as possible.

Developing something small does not mean giving up your dreams, only delaying them. Cut every feature and every part of a feature that you can cut, but keep it on a list to work on later. If there is any way you can do it later, do so. Often, features that you thought were essential turn out to be unimportant when you have more user feedback.

6. Get things right, and be decisive in correcting the wrongs

As your product takes off (if it does), you will have less and less time to make up for earlier mistakes. As users pile on, it will become more and more difficult to make big, drastic changes. However you make your bed, that’s how you’ll sleep. As much as possible, take hard decisions early rather than letting problems fester. Don’t delay necessary change just because you’re already committed into a different direction.

7. Don’t spend the time correcting until you know what you’re aiming for

At the same time, it’s easy to end up spending all your time refactoring the codebase every time a new feature is brought in. Refactorings must be done to maintain development speed and build a scalable, clean product. However, a refactoring effort should consist of two parts: 1) figuring out what to refactor to, 2) doing it. The first part can take weeks, the second part is often a mere few days long. The first part should never be an excuse to stop work completely.

This applies to design changes too. If you realise that you need to change the direction of the product significantly, figure out your new goals for before implementing the change.

8. Don’t let your programmers design the user interface

I’m a programmer, among other things. Like many in this profession. I suck at designing UIs (though sometimes I believe I don’t). When you let programming-focused people like me build your user interface, you will get things like this.

Some people are naturally gifted at user interface design. They feel physically sick about adding a button that clutters the interface or messes up the user’s workflow. Make sure you have a gifted UI designer on your team (whether or not he or she doubles up as a different role — including programmer). It will make a world of difference when you get your first users — the difference between a lukewarm response and “Wow, it’s great! I love it!”

Who to build it with

9. Make sure every member of the development team is passionate about the product

Your development team is to your product like parents are to a child. If they do not care about your product, it might turn out well anyway — but the overwhelming likelihood is it won’t. Anyone who’s not passionate about building your product should not be involved in building your product.

For this reason, it is very unlikely that outsourcing your product development will be successful. Build your product in-house, and make sure the team is fully bought into the concept and committed to make it a success. It is better to give up 50% of your equity for a great product team than to give up 5% for a poor product team. 95% of nothing is still nothing.

In yesterday’s world, this was very hard to achieve, since even a relatively simple web application required a fairly large team to implement, and the larger the team, the harder it is to remain passionate. With today’s web development technologies, it is possible for a team of 2 or 3 to build an entire business within 3-6 months, but those 2 to 3 must be passionate and dedicated.

It is very hard to make up for your team’s lack of passion through your own passion.

10. Be sickeningly elitist about your development team and sickeningly inclusive about your users

No one should be considered too stupid to use your product. For each person who you know had trouble using your product, there will be many more who had the same trouble but never told you. It’s never the user’s fault, it’s always your product’s fault for not being clear and intuitive enough.

At the same time, your development team needs to be the best. You cannot create greatness out of mediocrity. These days, elitism is regarded almost as a flaw. Actually, it is the only way to greatness. If you want to create the best product, you need the best people.

11. The best hiring strategy is to hire no one

Hiring employees is a nightmare. There are a lot of legalities to be considered, and it is a lengthy, time-consuming, and expensive process. Fortunately, you don’t need to hire employees. You need to recruit a development team to work with you, not for you.

Your development team is like the heart and lungs and brain of your business. They should be as committed and passionate as you are. For this to happen, you need to treat them as equals, not as subordinates.

You don’t need job adverts, you don’t need resumes, and you don’t need contract negotiations. What you need is to network in the right communities, whether online or offline, to recognise the people you need, and to bring them in not as employees but as partners in your vision.

12. Include at least one target user on the development team

By development team, I mean the team involved in the day-to-day or week-to-week iteration meetings. If you fail to do this, it will cost you a lot to readjust when a real user finally approaches your application and, inevitably, finds it lacking. If you’re a small startup on a tight budget, this extra cost can kill you. Survival is worth giving up equity to get a target user on your development team.

13. Ensure everyone on your development team understands the problem they’re solving

Immerse your development team in the users’ environment for a short period of time and let them see for themselves just how bad the current systems and processes are. Presumably, you have some contacts who work in the niche that you are targeting (if you don’t, then it’s probably not the right niche for you). Convince them to let one or more of your development team sit in their office and experience the pain points for themselves.

This is the opposite of embedding an end-user in the development team. Embed your development team into the end-users’ environment — at least for a time.

Conclusion and Bonus Tip: Break any and all of these rules rather than do something stupid

Creating a new, successful product is like writing a book, creating a movie, or raising a child. It’s a fiendishly complicated task that requires great adaptability and creativity. Rules can only get you so far. No amount of advice can guarantee you success. Sometimes, the rules fail, and you need to adapt to those situations and do what needs to be done, even if it flies in the face of accepted wisdom. For every rule of product development, there is a dozen examples of teams which did it differently and still succeeded.

Good luck!

As ever, please do share your thoughts and additional tips in the comments below, or on your own blog (I have trackbacks enabled).

False Endpoints and the Pareto Principle

Fri, 21 Mar 2008 09:54:00 +0000

In this article, Adrian Hon, picks up on the idea (originally from Gregory Bateson, I believe) that time pressure creates what Bateson calls false endpoints, that reduce the quality of the final solution. He also proposes that the development process in creative fields should be altered to encourage “play” as a way of generating solutions, even as part of a business.

I believe this is misleading, because it’s partially correct. Time pressure does cause us to make compromises, but those are not necessarily to the detriment of the overall solution, particularly if one takes a long-term view, or if one considers just how unknowable a concept the “best” solution is.

Diminishing Returns

So let’s examine this step by step. First, let’s look at the idea that the compromise solution of a “false endpoint” won’t be as good as the perfect solution of a “play” result. In pragmatic terms, what this means is that by spending more time on the solution (an unknown amount of time), some improvement on the solution will be obtained. So basically, you spend more and you get more. Then the question is, are you getting your money’s worth with the extra time you spend on a solution?

The pareto principle hints that 80% of the results will likely come out of 20% of the work. If the 20% was done first, and generated the 80% of results, then it is likely that spending another 4 times the initial time is not worth doing for a 20% improvement on the results (no matter what perfectionists may say), unless you have unlimited resources (but most of us don’t). Since we all prefer to deliver better results, I’d propose that time pressure forces us to become better, over time, at recognising what the useful 20% are and at discarding the rest. In a pressure-free environment, however, there is no incentive to focus on what really counts.

In the long term, what you might look at is the “value” that’s been added by all this work. Again, here, the pareto principle holds, and if you constantly, efficiently do 20% of the work in exchange for a “good enough” 80% result, once again, you win, since you’ll be able to produce 5 times as many products as you would otherwise. So adding time pressure for each task results in an increased number of “shots” at the solution - you could design 5 products targeting the same market, for instance, or 5 products targetting different markets (which would then perhaps have a better chance of being lucky and hitting a sweet spot).

The Unknowable Marketplace

Why would you want to do that, though? Surely, you know what the best market is, and what the best solution is going to look like, and how successful it will be… don’t you? Well, no. Business is not only a world of limited resources, it is also one of great uncertainties. Before you put a product in front of users, you don’t know what they need, and so you can’t even begin to aim for perfection (via play or otherwise). Instead, the best result is derived by getting the “simplest thing that works” out there and seeing how it fails, and then improving on it incrementally. Chances are, until you’ve got your product out there, you won’t be able to even recognise the best solution if it bashes down your door and yells at you.

There’s one last counter-argument here. What about creative activities? What about advertising? Writing? Won’t they benefit from a “play” approach and the removal of deadlines to allow doodling away until the best solution is reached?

For this, I turn to reality. My father used to be a journalist, and once of the things he told me is that as a journalist, you are required to produce creative output to an extremely tight deadline. I have friends in advertising who tell me the same. Many writers work by setting themselves a daily target. It’s perhaps not very surprising, but what works in a more engineering type of business (e.g. software development) also applies to softer, more traditionally creative activities.

Conclusion

In conclusion, what I believe it comes down to is this: deadlines focus the mind, enforce prioritisation, and ensure that some form of value is delivered. A pressure-free environment may or may not produce a great result by the end. A pressurised environment will produce a good enough result, and leave you with spare time to improve on it.

If you have any thoughts or comments, please feel free to post them up below or on your blog (I have trackbacks enabled).

How tough is your project?

Mon, 11 Feb 2008 12:14:00 +0000

You’re a business guy, a manager, or you’re a developer. You work on a startup, or within a large corporation. You’re about to start on your company’s flagship product, or you’ve been asked to take project X forward. Or you could be anywhere in between those extremes. One question should be worrying you as you take on the noble task of delivering something viable: how tough is your project, and why?

This matters a lot, because if your project is tough, you’re going to need to figure that out quickly and address the things that can go wrong with it. And if your project is really tough, you’ll need to find great developers to work on it.

So how do you figure out how tough your project is? There’s a number of ways. You can ask people, for a start. In aggregate, qualified people who understand the project will have a pretty decent idea of how tough it is. But sometimes you can’t ask, either because there’s no one to ask, or because the politics of the place dictate the wrong answer. What you can use in those cases is a list of criteria, of checkboxes that mean your project is tougher if you tick more of them.

Before we start with this list, a quick summary of where they come from. Projects are tough when they have a high risk of screwing up. Risk comes in two major flavours: technical risk and market risk. Technical risk is linked to whether you’re capable of building what you’re building. Market risk is linked to whether you are actually building the right thing. It’s a useful dichotomy in IT and in many other places - to succeed, you’ve got to do it right, and you’ve also got to do the right thing. Now, you can break these two risks down in all sorts of interesting ways, but what I’ve tried to do here is to produce a list that will be useful to you no matter where you sit on the scale from hardcore bit-pusher to networker extraordinaire - whether you’re a techie or a business guy, basically. Here goes.

1. Technical Risk: number of features

Can you summarise what your application will do in a single sentence? Most likely you can (if you really can’t, you might want to rethink your application - it sounds like it’s really two or more applications). That sentence gives you your core application feature. But it doesn’t give a complete rendering of your vision. In order to build something real, you’re going to have to break it down into smaller, more concrete steps. You can drill down into these (your application requirements) as deeply as you want, but some sort of middle ground is where you should be aiming. You want that specification to take about half a page to a page, no more and no less.

At this level of detail, you’ll have a decent feature list, that you can put in bullet points. Here’s the clincher: every time you add one of these bullet points, you greatly increase the difficulty of the project. That’s because no feature stands alone. They all interact with each other, and those interactions increase the complexity, and with it the risk that something will go very wrong. At the extreme, if you add a feature that interacts with all the existing features, you’ve just doubled your technical risk. On the good side, this works both ways. The more features you can cut, the easier your project will be to deliver. One of the beauties of software (particularly online applications) is you can add features later, after version 1.0 has shipped and started either making some money or at least getting solid user feedback. Do so wherever you can. If your software is still worth shipping without feature X, be merciless and cut it out.

If after doing this exercise you feel that your project still has a lot of features, your project may be tough. If it meets some of the other points too, it probably is.

2. Market risk: user picky-ness

The more picky your users are, the higher the chance they’ll slaughter you when you take your product live. This picky-ness depends both on the type of users and on the number of users. If you’re aiming for millions of users, they qualify as picky, always. If you’re aiming for a dozen hedge fund managers, they are picky. If you’re aiming for a few thousand middle office users in a bank, they’re probably not that picky (though you may be led to think otherwise after yet another interminable requirements gathering meeting).

You can’t do much to cut this risk down on the outset, but it’s good to be aware of it, particularly since it’s often overlooked. Technical people, particularly, tend to focus on technical risk, and assume that if the functionality is easy to implement, the product’s a piece of cake. It’s not. Creating something millions of people will be willing to use takes a touch of genius, just like creating a brilliant piece of code.

What you can do once the project is rolling is put it in front of users as soon as you possibly can. If this is a major risk for your project, you absolutely have to use an iterative (probably agile) development process and get some users involved. If you can get them involved before it even starts, great. If you’re going for something very specialised, you might even consider giving some equity in exchange for a few of your target users on your board of directors.

3. Technical risk: complexity of features

Number of features is a big factor, but that doesn’t cover how complex they are. You might build a GTD todo list that has a zillion features, but none of them are really complex. Build a “straightforward” search engine with only a handful of features, though, and complexity goes sky-high.

If you’re a business guy, you’ll need a trusted techie for this. Don’t take it badly - it’s one of your qualities, to see things that are really hard or even impossible and try your best to shove them into existence (and then sell them!). But you need someone who knows what’s possible, and who can tell it to you straight.

If you have a really complex feature in your shopping basket, what you should do to reduce risk is build it first. Build it before you build anything else at all, because this feature is where a lot of the technical risk sits, and the sooner you’ve resolved it, the sooner you can move on and relax. Of course, if you have one (or more) of these features in your project, you earn yourself a tick on this criteria on the “tough project” checklist.

4. Market risk: strength of the competition

This is not about whether there are competitors at all. Having no competitors doesn’t make things easier - in fact, it makes things much harder for the marketing team, because they have to create a market by convincing people that they need this new thing, and making them understand how it fits into their existing needs. If you’ve got no competitors, your project is probably tough. Tick this box.

There are many existing markets that could use some improvement, though. The number of competitors doesn’t matter so much here, it’s the quality. Going head-to-head with Google or Apple in any of their core market, for instance, instantly earns you a tick in this box. Evaluate the competition (you did do a competitor analysis before getting started, right?). Chances are, most of them are just also-rans. Those shouldn’t bother you too much. What you’re looking for is, would any of them deserve to be called a Tiger, or a Shark, or some other kind of vicious animal. If yes, and if your stated goal is to fight these guys, your project deserves a tick in this box.

You can’t do much (.. legally) to reduce this risk. What you should do is be very aware of it and make sure your product does something radically better than the top competition. And keep monitoring them while your project is evolving, just in case they do something that changes the game. If they do, you need to act quickly to ensure that you don’t come out with an also-ran.

5. Technical risk: integration risk

A lot of the largest IT projects have been failures. The stage where they most commonly failed was integration. After building a bunch of components separately, people found, at the last, under-estimated minute, that they didn’t fit together. You should be prepared for that both within your project and outside of it.

Within your project, unless you’re building the next air traffic control system, that’s probably not a major issue, and you should deal with it very simply by forcing the project to deliver an integrated product throughout the development (using agile processes once again helps here). If it really is an issue (according to yourself or your technical guys), perhaps your feature list could use a bit of initial trimming (see point 1).

Outside of it, though, this is still important. The more external systems your software needs to integrate with, the greater the risk. By external systems I don’t mean TCP/IP or “the internet”. I mean things like: email processing, linking up to an existing legacy system, SMS integration, phone line integration, streaming technology. Each of these chunks of existing technology will cause you massive headaches, and you should consider every one of them to be as dangerous as a “complex” piece of functionality (as discussed in 3). The solution there is the same: cut them out if you can, and if you can’t, build them first.

Conclusion

These five points should help you gain a better idea of how tough your project is. If you’re building a sprawling application which does ten thousand things, is aimed at almost everyone, retrieves and reprocesses data from thirty external systems and has strong, well established competitors (the My Google homepage would qualify), your project is tough.

On the other hand, if you’re building an application which has just one feature (e.g. generate random passwords), will be imposed on your five thousand internal corporate users and will require use of cut and paste to work with existing apps, your project is not tough.

In short:

Toughness = Risk = Technical Risk + Market Risk
        = (Number of Features x Complexity of Features x Integration Risk) +
           (User Picky-ness x Strength of Competition)

In a later article, I’ll examine, in a bit more detail, the link between project toughness and the kind of developers you want to hire. In the meantime, thanks for reading. If you have any comments, examples, or suggestions for other criteria, please post them below!

Fundamental mistakes

Tue, 22 Jan 2008 11:59:00 +0000

When building something new, mistakes are unavoidable. To paraphrase the common saying, “if you’re not making any mistakes, you’re not trying hard enough”. There’s another saying which says that the difference between a good carpenter and a bad carpenter is not that the good carpenter doesn’t make any mistakes, but that he’s better at turning them into masterstrokes. You can, and should, try to prevent mistakes from happening, but it’s a fact of project life that things go wrong.

Many books can be filled on the subject of how to deal with the huge variety of project mishaps. In this article, I’ll focus on one specific type of mistake: the big, fundamental mistake.

There are some mistakes which scare the living hell out of you when you find out about them. They’re basic, they’re fundamental. They’ve got “killer” written all over them. Here are some examples:

choosing the wrong platform or framework to develop your product
building on critically flawed code in the hope that it will improve over time (it won’t)
missing or misunderstanding a major, crucial requirement

When you come face to face with one of these, the natural tendency is denial. You might first try to ignore it or downplay it. “It’s not that big a deal”, “we’ll deal with it on the side”, “the world/plan still goes on”, “we can change it later”.

It takes a great deal of courage to say “we’ve made a fundamental mistake and we need to fix it right now” when one of those issues crop up, particularly in blame-driven environments where the primary reaction to mistakes is to look for someone to blame.

The reason why it needs to be fixed right now is that the really big damage from these issues continues to come after they’ve been raised. This is why you need to assess the damage and make the decision to fix it as soon as possible. Critical issues that are swept under the carpet grow bigger every day.

Here are two examples to illustrate both possible outcomes.

The applet story

I once worked on a Struts application, in a bank. A major component of it was an applet. It was badly designed to begin with, being the product of a summer intern’s prototyping efforts, yet it was considered to be “80% finished”. Since a whole summer of cheap labour had already gone into it, the consensus was that it just needed to be finished with a couple of week’s work from a qualified senior engineer. So a senior software engineer was set to the task. Then a junior software engineer was thrown in. The applet grew, like a cancer. By the time the senior engineer “fell ill” and then quit, the applet had several hundred classes. By the time, a year later, the senior architect on the project finally found it politically acceptable to propose a complete rewrite of the applet, it had grown to over a thousand classes, and had swallowed over a man year of pure development effort (with even more QA and overhead time).

What happened then? The whole thing was rewritten in under a month, and went from over a thousand classes to about twenty. It ran faster, was less buggy, and was clean and easy to maintain.

Now, to be fair, the project manager didn’t know that the applet was quite so bad when he took on the project. He also joined the project a couple of months after it started, so he was not in an ideal position to kill the rotten half the project immediately, particularly since he was an external consultant. Truth is, the entire project (and I was a part of it) was responsible. Yet even though everyone knew the applet was a black hole for time and resources, the solution to this critical problem was always pushed back to “after the go-live”, because it was not politically acceptable to admit we made that big a mistake.

This is the kind of mistake a huge international banking corporation can absorb and not even notice it. What’s a few hundred thousand pounds wasted here or there when your quarterly profits are about 9 billion dollars? If this happens to your startup, though, you’re toast.

The Flex story

As a contrasting example, on another project (this one in a startup environment), we initially put in two solid weeks of very productive work building the application using Flex and the popular Cairngorm framework. In that time we followed the Agile mantras and delivered some great user-visible functionality. Everyone was quite excited about the pace of development. There were good feelings all around.

Then, our Flex developer told me that he didn’t feel Cairngorm was well suited for the kind of complex RIA we were building, and that he was going to work, “on the side”, on porting the functionality over to PureMVC.

When he casually pointed that out one day during an informal chat, alarm bells went off in my head. It would have been very easy to accept the proposal that we’d be working on this on the side and continue onwards, building the application with Cairngorm until the PureMVC port gave its fruits. But it would have been the wrong choice.

Instead, after discussing in earnest whether the limitations of Cairngorm really warranted such a major change of framework (they did), we put all the “new functionality” work on hold and did all the porting work right away. Result? It took us two weeks to finish the port (predictably, it took just as long as we’d spent building the functionality the first time around). If we had waited any longer, it would have taken more time. If we had waited long enough, the switch would have become too costly and we would have had to stick it out with an inappropriate framework. This would have increased out long-term costs by making it significantly more difficult to make changes.

This was a hard choice. It killed our momentum for two weeks, and in a different environment this may have been politically unacceptable, even so close to the beginning of the project. But it was the right choice, and making it quickly saved us time and money.

Conclusion

When you’re faced with a big project mistake, deal with it now, even if it’s going to cost you. Spending more time and effort going in the wrong direction is like throwing good money after bad. Don’t freak out, stay calm and make rational, measured decisions - but don’t assume that the mistake can be fixed more easily later. Instead, always assume that every day that you wait before acting to fix it will add another day to the cost of the fix itself.

If, during the discussions, you find that the mistake is not really critical and that it can be fixed later, go for it - but always ascertain that for yourself rather than assuming it.

Thank you for reading. As always, any comments and contributions are most welcome.

Rails sucks?

Thu, 10 Jan 2008 10:33:00 +0000

With astonishing regularity, articles or posts come out claiming that Rails sucks in some way or another. People complain that Rails isn’t as easy to deploy as PHP, that Rails just didn’t do it for project XYZ. They range from the articulate and well thought out to the frankly inane and stupid (and wrong). Recently, there’s also of course been the spectacular nuclear rant by Zed Shaw, which was more a rant against random elements of the community than against Rails, but was still presented as a rant against Rails.

These anti-rails rants come in so regularly, and have been doing so for so long, that some people even bothered to write pre-emptive rant responses, like the Six ground rules for rails sucks articles, written all the way back in 2006. RubyInside even has a Troll of the month category that will provide some fun reading.

Perhaps this means that this article is redundant. Oh well. It does get tedious after a while, to read all these rants, and I felt like writing my response to them too.

Why people say Rails sucks

There’s a large number of reasons why people come to the conclusion that Rails sucks. Here’s a by-no-means-exhaustive list:

It’s too slow
It’s not easy to deploy
It uses up a lot of RAM
It’s not as easy as PHP
It’s got weird syntax
The manual is too long
The manual is too short
The creator of Rails is arrogant and eccentric
It doesn’t work with my specific project
It doesn’t scale
It’s got this obscure problem that no one can be bothered to fix
It’s not thread-safe
etc…

What they all boil down to, in effect, is that some people get immensely irritated because Rails does not conform to their idea of perfection. They have some specific requirement that Rails doesn’t support, and they post rants about how “they” (the rails core team) owes them to adapt Rails to their requirements, or how “rails sucks” because it doesn’t do exactly what they need out of the box.

I’m sure you can see the obvious shortcoming of this approach, but let’s break it down, because there’s several aspects to this complaint which make it very, very wrong.

1. Rails owes you nothing

Rails is entirely free. You can run it on any OS you like. You can run it with a free DB or a paying one. You can rip out the bits you like and discard the rest. You can even make changes to it if you want (and with a plugin like Piston, you can keep your changes tracked even as Rails evolves and you update it to the latest edge revision).

No one in the Rails world owes you a thing. In fact, if you’re using Rails, you have a big debt to the Rails world. Most importantly, all of us using (or trying to use) Rails owe DHH a big one for being so kind as to share his framework with the rest of the world. Even if you decide that Rails is not for you, you still have to recognise the influence that Rails has had on web frameworks everywhere - and it’s a very positive influence.

The Rails core team also doesn’t owe you anything. They are all volunteers who work on it for free. You owe them.

So stop thinking that Rails owes you something. Rails owes you nothing. You owe Rails.

2. Rails isn’t perfect

There’s no such thing as a perfect web development framework. All of them (including Rails) suck in one way or another, once you use them for real stuff. There’s no such thing as a perfect language, either. All of them (including Ruby, Lisp, Python, haXe, Erlang, Lua, etc.) suck in some way. In fact, there’s no such thing as a perfect anything - whether in the world of computers or outside of it. Everything is imperfect. If you want perfect, then die. If the Christians are right, you might go to heaven and witness perfection. I wouldn’t bet my life on it though.

There’s a certain maturity in realising this, and it seems that most of the anti-Rails ranters lack that maturity. There’s a point in life where it suddenly dawns on you that no choice is ever perfect, no matter how much you may try or how perfect it may look before you put it in practice, and that you have to satisfy yourself with the best choice, rather than with illusory perfection. For those on whom this never dawns, everything is perpetually dissatisfying.

I’m not saying you should settle for crap. No, strive for the best that you can. Create something even better if you can and have the inclination. But accept that everything has limitations and shortcomings, and that a good choice is one which balances the trade-offs between the available choices to maximise whatever it is you wish to maximise. In some cases, that might mean accepting slower out-of-the-box performance in exchange for quicker development and better maintainability.

Back to the Rails argument, this becomes especially clear once you’re put in the position to decide which language and framework to use for your project - for instance when you are starting a business around that application and it really matters. With that experience, there is a very clear learning point: each framework is imperfect, but your responsibility is to choose the one that makes most sense for your specific project. Once you’ve made your choice, you can even change it, sometimes - but do so with the knowledge that every framework you try will have its own shortcomings.

But, at the end of the day, there’s no point in complaining that Rails isn’t perfect. Yes, it’s not. If that’s news to you, you’ve got a bit of growing up to do.

3. Rails isn’t suited for all applications

There are many situations where Rails isn’t the right choice. If you’re writing a high volume transaction processing system for a bank, don’t write it in Rails. If you’re writing a 3-page web presence for a hairdresser, don’t write it in Rails. Rails is extremely good for a certain class of applications (medium to large web applications), in a certain set of circumstances (particularly well suited when getting something out soon is of paramount importance).

If Rails isn’t right for your project, that doesn’t mean that Rails sucks. It just means that your project isn’t right for Rails.

4. Rails isn’t suited for all people

Rails is a smart and opinionated framework. It’s built to allow smart people to leverage their skills to be many times more productive than many other web development frameworks. And it does so - for me, and for many people I know. It allows these smart people to be very productive, create clear, maintainable code, and have fun while doing it.

This doesn’t mean that you can do it too. And you know what, those people don’t care whether you can do it too. They’ll help you if you ask for help (I know several Rails core developers and they are without exception friendly, polite, helpful people - and that’s not even counting the rest of the Rails community, who are also very helpful). But if you decide Rails is not for you, no one will shed a tear.

This, to me, is actually a positive feature of Rails. Because you have to be smart to write good Rails code, it’s easy to tell smart developers from not-so-smart ones, because the latter just won’t be able to cope with Rails, whereas the former will often take to it like a fish to water. (see comments) - It’s much harder to fake being a good Rails developer than it is to fake being a good PHP developer.

Not “getting” Rails doesn’t mean you’re stupid, mind you. Some people don’t get Rails simply because they think differently. Others say that Rails is cool, but they prefer something else (e.g. Django or some Lisp or other). That’s fine. If you don’t like to think in the Rails way, no one’s forcing you to use Rails.

Rails may not be for you, for any number of reasons. That doesn’t mean Rails sucks.

5. Rails is extremely flexible

The thing that really gets me about people who rant about how Rails doesn’t do what they need is that Rails is by far the most versatile framework I’ve worked with. When Jakarta Struts didn’t do what I wanted in the Java world, I had to make wild and ugly contortions to get it to work - or even turn around and tell my boss “Sorry, we can’t do this because xyz”.

Every time I have a “different” requirement, I am astonished to find that either there’s already a way designed into Rails that allows me to do it easily, or it’s a neat, well contained three-line hack to get it working. I’ve never seen this in any other framework (including the ones I wrote myself). Everywhere else, there always comes a point where you have to turn around to the client and say “it can’t be done”. That just never seems to happen when developing web applications with Rails.

This applies to all enhancements, from performance improvements to functional extensions. If your ActiveRecord query is too slow and causing a bottleneck, you can bypass it with some inline SQL or even memcache it. If you need to get Rails to produce a custom binary output, you can. If you need custom table names that don’t fit the convention, you can. If you need to override the dynamic finders to do things slightly differently, you can. In most other frameworks, you can’t do anything unless it’s been thought of. Rails is the most open and versatile web development framework I’ve ever worked with.

That’s what really gets me when people say things like “Rails doesn’t scale”. First of all, that statement is based on outdated information, and secondly, Rails code, when written properly, is so clean and easy to work with that locating and optimising bottlenecks is a breeze - much more so than in many other frameworks.

So if Rails doesn’t yet do what you need, don’t complain that it sucks. Do write a bit of code to make it do what you need.

In conclusion

There are many valid reasons to use something other than Rails, but do yourself a favour. If you decide Rails isn’t for you, don’t post a rant about how “it sucks”. You’re only making yourself look dumb by doing so, and while it may be amusing for the rest of us, it’s really not doing yourself any favours.

Feel free to post comments below to tell me that actually, Rails sucks for such and such reason.

Feedback

Wed, 02 Jan 2008 14:35:00 +0000

When designing a feedback system to influence change (for instance, a status report to influence the project progress, or an attempt to lose weight or save money) it’s easy to fall into the trap of going for accuracy first. Countless hours can be wasted designing the perfect measure of progress, making sure it’s accurate as can be, ensuring everyone fills in the data as accurately as possible, etc. Most of that work is, however, pointless, because accuracy is not the name of the game here. Sure, feedback needs to be vaguely accurate, but it doesn’t need to be very accurate to work.

So what is good feedback then? In this post, I’ll look at what constitutes a good feedback system and what doesn’t. Finally I’ll propose a simple framework for figuring out what feedback system to use.

Feedback should be consistent

Inconsistent feedback drives irrational behaviour. In fact, giving random feedback is a proven, effective method of driving people to misbehaviour (or even to insanity). If your feedback can’t be consistent in its frequency (how regularly and often it is given) and its direction (ie positive feedback should always be positive), don’t bother with it at all - it will only make things worse.

Consistency of feedback is like consistency of logic - it’s a sine qua non, without which everything else becomes meaningless.

Feedback should be timely

I believe the next most important quality of any feedback is timeliness. Here’s an example: my previous phone company used to send feedback 2 months after the fact. It was very accurate (itemised billing usually is), but since the call went into the next month’s bill, and that bill came at the end of the following month, there was a very long lag time between abuse of the phone and feedback about it. As a result my phone bill was often over £100 per month (yes, that’s huge). This didn’t allow me to correct my behaviour - all it did was make me feel bad that I overspent on my phone again.

I switched to T-mobile UK, which provides a weekly text message reminding me of how much of my “Flext” allowance I have left for this month. Since then, my phone bill has not gone above £46, on a £42.50 tariff.

Similarly, every project has some form of feedback (at the end of the project). Either the project team gets congratulated, or they get told they screwed up and caused all sorts of issues within the organisation and to clients and the world. Unfortunately, by then, it’s far too late to take corrective action. All you can do is make everyone unhappy that they were part of a failed project.

What is timely? Well, in some cases, it’s instant feedback - but not always. You don’t want to be snowed under a mountain of white noise about the progress of everything you’re involved in. “Timely”, in the context of feedback, is related to the pace of change. For expenses, for instance, I define “timely” as instant. For a project, weekly feedback usually does the trick. For weight loss, try the daily feedback of a scale.

Feedback should be effortless

I used to try to save money by keeping a log of all my expenses. I carried a little notebook, or a PDA, with me at all times, and recorded all expenses. These were subtracted from my weekly budget, so I knew how well I was doing at any point. This system worked relatively well, but it had one fatal flaw: it required constant effort. I never managed to sustain it more than a few months at a time, after which I would stop tracking things, because it was too much hassle, and relapse into over-spending.

If your feedback system requires constant effort to maintain (particularly if the effort has to come from the person receiving the feedback), it is flawed in the long term and will eventually fail.

What did I do about the spending? Well, I came up with a new feedback system. Instead of counting expenses, I switched to paying for everything in cash. On Thursday of each week, I take out my weekly allowance from the cashpoint, and I spend from that. The instant feedback from seeing my little cash pile diminish works as well as counting expenses, but takes no extra effort on my part. The only effort was in thinking of the system in the first place (thanks Bob!). If your expenses are out of control, I highly recommend it!

In conclusion, the holy grail of any feedback system should be for it to be completely effortless, to continue working even when the attention of the receiver is somewhere else.

Feedback should be vaguely accurate

Of course, feedback needs to be somewhat accurate. But here, there is an expression that gets across the idea quite well: “it is better to be vaguely accurate than precisely wrong”. I’d add to this: “especially if the extra accuracy comes at the cost of timeliness or effortlessness”.

The feedback from T-mobile’s Flext is not accurate. It only tells me about my aggregate phone usage. But it’s timely, and so it works. Similarly, project feedback does not need to be very accurate to work. This is the approach that the typical agile burn-down chart takes. Ultimately, “story points” are fairly loose stuff. But what’s always true is that as long as you’re not making up silly User Stories with random estimates, it’ll always be the case that: “every point you deliver is a good thing”. So you get a vaguely accurate pat on the back at the end of each iteration telling you you delivered something useful. Or, if you delivered nothing, you get nothing - and that’s feedback too!

In contrast, I once had a long discussion with a project manager as to the most accurate way to measure completion of tasks (I supported partial completion percentages, whereas he thought that only a finished task earned any percentage). In hindsight, the discussion was futile, not only because we were both right (both approaches have benefits), but because the accuracy difference between the two was irrelevant. What was relevant was implementing weekly status reporting where there was nothing - Whether it was 10% too high or too low was irrelevant, so long as the error was consistent.

A typical example of accuracy that can be improved is the weight scale that I mentioned earlier. Weight scales are accurate at measuring weight, but the reason most of us want to lose weight is because we want to lose fat. Plain weight scales don’t give you that information. Without a Body Fat Percentage scale, you might measure things with the right frequency and with only a little effort, but since you’re not measuring the right thing (unless you weigh hundreds of kilograms, in which case most of it is certainly fat), it won’t help you achieve your goal of eliminating fat.

Summary

So, we have a few key elements of what constitutes good feedback. Good feedback should be:

Consistent
Timely
Effortless
Vaguely accurate

This provides a simple framework for improving a feedback system, by providing you with four questions to ask about your current system, and an order of priority between them.

Is the feedback system inconsistent? If so, can I make it more consistent, even at the expense of timeliness, effortlessness and accuracy?
Is the feedback system timely? If not, can I make it more timely, even at the expense of effortlessness and accuracy?
Is the feedback system effortless? If not, can I automate any part of it so it happens even if I don’t do anything, even at the expense of some accuracy?
Is the feedback system accurate enough? Can I make it more accurate without hurting one of the other key qualities?

I hope you found this article useful. Thank you for reading. Any feedback (timely or otherwise) in the comments below would be most welcome!