Good Enough?

I recently saw a nice chart on Kathy Sierra's blog depicting the user's hierarchy of needs. What immediately struck me was the different aim points that different types of organisations shoot for, and the level of satisfaction that team members get from being exposed to projects which exhibit these various aim points.

Before we go much further lets take a look at the diagram.

Along the left hand side are my annotations to the original diagram which indicate some "aim points" relative the to needs scale given in the centre column that I've observed amongst various organisations I've worked for over the years. Now, sure, there are going to be some gross generalisations here but bear with me and you'll see the big picture I'm getting to.

Starting at the very bottom, consultancy type organisations, or businesses building internal line-of-business applications are not trying to create show-stopper software. They are trying to meet a need at minimal cost. That need is usually manifest in a specification or briefing document and the main emphasis of the team is to give the client this functionality - no more and no less - whilst trying to keep budget under control. Programmers who DON'T want to become rock stars by going above-and-beyond enjoy this kind of work, and project managers should staff their teams with such programmers. Technical geniuses are wasting their times on such projects and will be out of there faster than you can say "internet job board". Good things for management to focus on during interviews are adherence to deadlines since the scope has already been mandated more or less.

A little further up the scale we have organisations selling the software / service they create, labelled here as "shrink wrapped" despite the fact that most software is downloaded these days. Such organisations are more focused on the quality of their offerings as it has a direct impact on their business profitabilty. Often these organisations have multiple product offerings and can take a broadshot or portfolio-based approach to product management where the more successful products subsidise the not-so-successful products in the portfolio.

In order to differentiate their products from those of their competitors and attract a user-base, the software produced needs to be considerably better than average. That entails more emphasis on usability and internal product efficiency. You'll find all manner of programmers in these projects as they require a mix of people who really care and those that prefer to get the job done with minimial fuss. Regrettably, what most of these organisations fail to recognize is the economic benefits achievable by realising the negligible marginal costs associated with quality improvements. That is, the additional cost by doing extra work to improve the quality of the product can be apportioned over the entire user-base since the cost of duplicating software is effectively zero, hence the marginal cost of that quality improvements is negligible.

At the furtherest extreme of the chart we have the must-win software projects. In these cases the organisation is usually solely devoted to, and completely dependent on a sole product offering. Internet startups are the classic case of this hence I've labelled this aim point as such. Since the survival, not just the success, of the firm is entirely dependent on the product/service being developed it has no choice but to be best-of-breed, or pitched at a price point compelling enough to move customers from incumbent products to your own. This is not an easy thing to do and the failure rates of such companies are usually very high because of this. If you are heading in this direction you need rock-star programmers. A group of mediocre programmers will, more than likely, not care enough to pursue the levels of technical excellence and user harmony you need to shoot for, and most definitely will lack the ability to, as Joel Spolsky elegantly put it, "hit the high notes" ! Technical teams working on these projects will often be doing very innovative things technically and will be paying particular attention to what it's early adopters and existing users are telling it about the product.

So at the end of the day what does all this mean? Well, technical managers need to be realistic about what their aim points is - some simple economics helps - and staff their projects accordingly. On the flip side, developers should, based on their own personal ambitions, seek out the types of projects that have aims aligned with their personal goals. If there is a mismatch then job satisfaction is guaranteed to be unacceptably low. Some folks refer to this as "cultural fit" but I'd just say it's good management and common sense.


Smart and Gets Things Done

Smart and Gets Things DoneI've long been a fan of the succinct and insightful thoughts of Joel Spolsky (http://www.joelonsoftware.com/). Joel is a Yale-educated ex-Microsoft employee running his own software development company, Fog Creek, in New York.

I recently came across a book he wrote, Smart and Gets things Done, and decided to invest time in reading it. It's only 150-odd pages so you can easily get through it in less than a week - Bill Clinton biography-sized bricks don't endear themselves to me that much.

According to the blurb on the back of the book it is "a guide to attracting, recruiting, interviewing, and hiring the best technical talent."He covers this topic skilfully with useful insights, though I must say that I don't agree with all his observations. As with most of Joel's writing, and as can be seen from the long list below, there are numerous gems to be found in this book. For the record, here are the more critical issues Joel identifies that I feel strongly about (both positively and negatively).

Things that Joel mentions that I think are important and strongly agree with him on:

  • Good design adds value faster than it adds cost. Joel bases this observation on the fact that software duplication is essentially free thus development costs can be apportioned over the units sold resulting in negligible per unit incremental cost.

  • There no place in the software industry for low-cost providers, for the reasons given above. And industries that need to develop good software should not be trying to reduce the cost of programmers.

  • The difference between good and average programmers is significant. Great programmers are 3 to 10 times more productive whilst only costs 20-30% more. (And kudos to Joel for providing empirical productivity data from a reasonably well controlled experiment to backup this notion). On that topic- I'm a firm believer that data should drive the decision making process! If you don't have the necessary data, think about how you can get it. Hint: hallway usability tests, split A-B testing, customer involvement, web server log files, etc.

  • There are benefits to using the smallest possible team, since co-ordination and communication is overhead for the team.

  • For companies whose success is dependent solely on the quality of the products/service they develop, you'll need rock-star programmers who can "hit the high notes". If you work for an Internet startup this applies to you! If you're an executive at an Internet startup tattoo "quality is critical, ergo great people are critical" to your left fore-arm but you needn't go for David Beckham's kanji script.

  • The software marketplace these days is somewhat of a winner-takes-all system. That is, it's a hits-driven business rather than a long tail play.

  • If great programmers don't want to work for you they won't. So learn what they want and go about trying to give them it. The book details these issues fairly well.

  • You're not going to get great programmers if you don't respect them.

  • Programmers pay close attention to the intellect of the interviewer. Dead right. Talent attracts talent! Great programmers have a yearning for learning and being surrounded by smart, successful people as this helps them believe they will learn new tricks, which of course they will.

  • Programmers who can communicate their ideas clearly are going to be far, far more effective than programmers who can't.

  • Some technologies are just harder than others. If a developer can write assembly code, or is a whiz at pointer arithmetic in C++ they are going to be able to pick up <insert-desired-high-level-technology-here>.

  • Requiring programming and/or logic assignments on application are an unnecessary obstacle.

  • Aptitude is more important than experience, since the software industry moves relentlessly fast. I'd add that the only allowable exception to this is when you are hiring short-term contractors that need to be up-to-speed in the technology being used for the project.

  • Look for programmers who are smart AND who get things done. Both attributes are important here! I know it sounds elitist, but this expression, which is also the title of the book, essentially sums up the whole recruitment process nicely!

  • Being a blow hard or quiz-master interviewer is highly ineffective. These days we all have a Google search engine at our fingertips, so knowing the process is more important that the detail. If the applicant knows the Karatsuba algorithm is a slightly more efficient way to do multiplication of large numbers don't penalize them for not being able to recite the precise approach! The key point is knowing what the algorithm does on a general level and when to use it. 

  • Smart people are passionate about the projects they work on.If they aren't they would have quickly left the project and subsequent discussions about it become critiques of their former boss's lack of management / technical skills and why they couldn't wait to get out of the project.

  • Most of the time at an interview should be left for the candidate to prove they can write code (on a white board or paper). Speaking from experience :-)great programmers like to show off their skills and will relish the opportunity to write code for you.

  • If the basic concepts aren't so easy that you fly through them, you're not going to get the big concepts. The corollary to this is that a candidate that can confidently talk to you about more advanced topics, say for instance... why lexically-scoped closure makes anonymous delegates in C# way cool, is more than likely going to be able to understand simpler concepts.

  • The best programmers have an aptitude for dealing with multiple levels of abstraction simultaneously. I agree, and it's for this reason I am biased towards programmers who come from a mathematics or physics background because in the course of their undergraduate study they've already had to deal with copious amounts of abstract concepts.

  • Most recruiting is structured as if the company has something precious (a job) that the individual wants. When hiring great developers the situation is completely reversed. That's simple economics. The demand for great programmers outweighs the supply of them. Remember that!

Things I can't say I agree with Joel on:

  1. Joel is still adamant that a software company needs to be adept at "converting capital into software that works", rather than pursuing an idea that solves some problem which hasn't been solved before. I don't completely agree with this and here's why....Without a good idea, great execution is all you have. In some cases that, and first-mover advantage is good enough to succeed. i.e. Amazon selling books online. In other cases it's not. But a company with BOTH a great idea and superior execution is far more likely to succeed than a company without both components, so why wouldn't you pursue both? "converting capital into software that works" sounds very much like Joel suggests focusing on user-driven execution which is a great thing to do but if it's based on a lousy idea you'll end up with a product/service no-one wants or needs.

  2. Great software developers are rarely on the market. Don't agree. Many great programmers are attracted to the life of an independent contractor, for financial reasons, for the benefit of selecting what work they undertake and for the ability to jump from industry-to-industry and organization-to-organization sucking up as much new knowledge as they go. Due to the short-term, project-specific nature of this work, these folks are on the market a great deal more often than "rarely".

  3. Private offices make software developers more productive. Although Joel cites several respected publications, I can't say I agree with these findings from the viewpoint of optimizing the team throughput rather than the individual productivity. Because most software is developed by teams with no one individual having complete knowledge of the system in his or her head, team members need to communicate to share the collective knowledge of the system. Putting developers in private offices, whilst giving them a bit more quiet time for uninterrupted development work, actually inhibits the free transfer of information and ideas between the team. Developers packed into relatively close confinement will mix more freely. Yes that does bring in the opportunity for more distractions but that's better than having each developer being an island unto themselves.

For the mathematically astute you'll notice that I'm agreeing with Joel far more than I'm not - well OK you don't need to be George Danzig to figure that out. So in summary I can confidently recommend this book to anyone who is engaged in the practice of hiring programmers for a company that need to produce great products. It's not a difficult read and is choc-full of gems you want flowing through your hippo-campus.

Great job Joel ! Hits the mark nicely.

PS. Here's a link to it on Amazon


Selective Offshoring is the Answer

There has been much written about the merits and social responsibility of off-shoring programming tasks to India, China and various Eastern block countries. Websites like oDesk and eLance seems to get considerable coverage in the blogosphere since managers in charge of technical teams drool when they see hourly rates for seemingly well-skilled programmers at around 15 USD/hour - if you go with a provider that does hourly billing. As we all know this is considerably lower then the hourly rates you'd need to pony up to attract better-than-average programmers in San Francisco, New York, Sydney, Singapore or London, regardless of the current market conditions for local programming talent, so on the surface of things it may seem like a simple decision: retain a core architecture team of highly-competent engineers and architects in your Development HQ who do the high-level design, and outsource the lesser work to offshore freelancers or labor hire firms. Then sit back and watch your monthly cash burn rates tail off, your delivery schedules and engineering budgets gravitating back towards those quarterly projections you presented at the last board meeting, thus stretching your seed capital as far as possible.

But is it that simple? To quote a well-known technical response... "it depends"!

Yes the hourly labor rates will be cheaper but you are trying to minimize the total cost of the project. Thus cost savings will only materialize if:

  1. the time required to do the assigned tasks to the required level of quality is close to the estimates given plus an overrun buffer (assuming a fixed-fee, fixed-deadline arrangement wasn't used); and
  2. the individuals engaged to do the work are suitably skilled, motivated and communicative that there is a reasonable chance that (1) happens [good luck trying to negotiate penalty rates with Vladimir in the Ukraine in case he misses your deadline because his priorities suddenly switch to his impending doctoral thesis review at the 12th hour!]; and, most importantly,
  3. a clear, unambiguous specification and/or regular guidance is available to the individuals engaged.

Some may scoff at this last point. "Of course we know clearly what we want to do!" I can hear you saying. Well consider that many development teams these days prefer Agile development methodologies where, unlike "waterfall" methodologies, the focus is more towards short-term objectives and proceeding in such a way that enables product changes throughout the development process to be more easily accommodated. That methodology didn't become popular because we all know exactly what we want and therefore never have to rework part of the specification document! Scope creep does happen, and in the world of Internet development even the best planned projects might need to be reviewed when a competing product or service appears unexpectedly on the market. 

That issue aside, these may not seem like large hurdles to overcome and if you have a very clear idea about the requirements for the particular task you are considering outsourcing then you can seriously contemplate if, at a strategic level, you should be outsourcing this piece of work or not. It would be prudent to consider the following issues:

  1. Is this a critical piece of your system? And are you planning on supporting it in-house or will you rely on the original provider? Losing control of your "system smarts" is not a well proven strategy.
  2. Is the project an add-on to your system that can be done without intimate knowledge of the system internals?
  3. Will the external developers need access to all of your existing source code, and knowledge base, to be able to complete the assigned project? If so, are you willing to give access to this to 3rd parties before a certain level of trust is developed?

As you can see there are many factors to consider, and for some types of projects off-shoring can be a highly effective practice. But, as you probably already know, selective off-shoring is the answer. It's all about knowing which projects are good candidates for outsourcing !