Outsourcing removed the interview process from setting up your team.  For many start-ups, that change normalized the resource pool as many outsource providers simply assign a team to the project.  In reality, there is a big difference between a developer who knows how to build an online Web store versus someone who can make Twitter scale or conceive of Ruby on Rails.

Let us help explain the difference between these types of resources.  First, we need a pyramid!

Companies have different levels or terms for engineers.  Here’s how I define them:

Web developer — A Web developer is good at creating sophisticated Web sites that have limited back end functionality.  His tools of choice are HTML/CSS/Javascript or Flash.  He loves walks in the park and open source CMS’s.

Software engineer — Software engineers are comfortable building more complex functionality that includes objects and business logic.  Ruby on Rails is the language Du jour for the hip and trendy alternative scene.  PHP is the blue collar worker’s hammer.  Java is the choice of old school guys who think the country has gone to the dogs.

Software developer — We don’t use objects, we are objects.  Pearl Jam is the new Grateful Dead.  If you haven’t modified a Unix kernal or developed in native C, then you are a poser!

Software architect — The architect is smarter than most of us, and you should avoid the ones who know it.  He spends his weekends looking for quasars or trying to eliminate a contradictory systemic anomaly from what is otherwise a harmony of mathematical precision.

For most of your projects, your team will likely be a collection of software engineers and web developers.  The more complex the project, the more you will need developers or possibly a seasoned architect.  The pay scale rises with qualifications obviously so we tend to look for one or two smart senior guys and then back fill with a cost effective pool of highly motivated individuals.

We took a look at our some of our projects from last year and charted them against the pyramid.

Understanding the type of project you have will help when selecting your team*:

Website or application – A Web site project in this case is a project that is mostly user interface with either little or standard back end functionality.  The site might have e-commerce, user sign-ups and dynamic content.  Back end functionality is supported by existing open source tools or by integration with other sites.

Product – Product development generally includes sophisticated back end functionality along with more complex interfaces.  The project often is based on some “secret sauce” that is protected IP, under a patent or otherwise considered a market differentiator.

Framework or foundation – Framework or foundation projects are projects that create technology upon which other solutions are created.

We’re product developers and like to produce complete solutions for our clients.  Framework projects are fun and challenging though there are simply less of them.  Of course, we love a good Web site project as well.  It’s just that they tend to be shorter and require more customization work than software engineering.

Next time you start up your a new project, it might help to classify the effort within this pyramid.  You can use the classification to define what type of engineers you should be asking for.

* A complete discussion of resources should include specialists and other disciplines including designer, tester, project manager and so forth.  I am working on a follow up post to help that aspect of your resource planning.

“Why can’t this be done 2 months? How hard can this be? Can’t you just use some open source products and customize them? We don’t need to start from scratch here. My expert says…”

Customers bring up many salient points during these discussions. Can the team work longer hours or can they work smarter? If a set of features requires 6 months to reasonably develop, can it also be done in 2 months with about the same size team? In this previous post, we point out that coding is physics and that we can’t simply reduce the schedule to meet a deadline.

Have you seen those home improvement shows where the contractor blows the schedule and the budget because of some unforeseen factor or change in the plan by the home owner? The home owner looks at a set of materials, imagines in his head the work to put them together, but never quite understands that it is never that simple. With software development, it’s the same principle. People look at a set of features and think in their heads, sure, this is doable in 2 months. They rarely consider that the implementation may not be as simple as they think, or that they might see the product and decide what they wanted is not what they thought.

Let’s look at a simple feature example of implementing sign-up and login. You can’t do much in a product if a user can’t create an account. An experienced developer using PHP or Java could do these features in a few hours by creating an HTML form and writing some SQL to add or look up a record. If features are that easy, why do we even need 2 months?

A good team thinks about the best way to implement a feature above and beyond the mechanics needed to create a form or put a record in a database. The developer must define a user object that has properties like email and password and functions like saveUser and validatePassword. The team must define objects smartly, otherwise you may have longer term problems maintaining your code base.

The page must be properly formated to match the mock-ups and overall aesthetic of the site. Color and font attributes are centralized in CSS files. If these are the first two features of the site, then the login and sign-up pages created will be the ones that define the styles for the rest of the site. Usually, the team needs a graphic or two from the designer as well.

The developer must also understand the client’s login and sign-up business rules. Do users login with email, login name or both? Must users validate their email before accessing the site? Should the developer check to make sure the email address is valid on input? We had 3 customers launch or hit beta in fall 2008 and each one had subtle differences in their business logic for sign-up and login.

You can now see how something as simple as sign-up and login might take a day to implement and another to test and validate.

With a new code base, the team must define the infrastructure of the code. Developers consider scalability, security, exception handling and a host of other services to make your product secure, robust and scalable. The best teams use existing technologies or frameworks to solve the infrastructure problems, but they still need to customize the code to meet specific needs. We no longer have to cut down trees or mill wood when adding on to your house, but we still need to cut the wood to size.

The good news about objects and infrastructure is that they both solidify over time and the effort to implement new features reduces. Economies of scale start to kick in once you have your solid foundation. You can hook into existing pipes when adding a bathroom on the second floor so to speak.

When you consider how much design work, object definition, and infrastructure is needed to create a scalable product, you just may find that 2 months is only enough time to get a small collection of features working. I told one client recently that after 2 months, the product will look like an unfinished house. Showing the product to their customers would be like walking on to a job site and imagining where the living room will be. After 3 months, you’ll see walls and after 4 months you’re painting them.

We suggest avoiding the 2 month launch for the simple fact that the best product comes from gathering feedback and re-thinking core problems, which is hard to do when the people providing feedback have to imagine where the walls of your hypothetical house will be. A development cycle of 6 months provides enough time to implement a robust feature set for launch, and to make improvements based on real feedback. This seems like a good idea to us. You’ll see this theme along with our predictions for trends in 2009.

My final point is this. If you launch with something that took you only 2 months to build, how defensible can that be if you happen to uncover the next new market like blogging, social networking, software-as-a-service or some new island in the Pacific? In 6 months, you can have something better, with more ingenuity and functionality, that has validation from your target market, and is not something a competitor could replicate in time to rain on your parade.

So back to the original question. Is 2 months doable? Maybe it is. Maybe, if we all stay focused and implement a minimal feature set, and if we don’t seek any feedback on what we created, it’s doable. But is it a good idea?

I was impressed by the sessions at this conference. The technical speakers were informed and clear. They were primarily experienced based speakers which means their knowledge was born from hands on work. I find people working in the field are more interesting, relevant and accurate when compared to those talking theory. Really, if you are considering developing in Ruby on Rails, I highly recommend you attend next year.

Joel Spolksy was a great keynote speaker at the conference. I remember laughing a lot and feeling like he had an interesting point of view for his talk. He really had a laugh at the expense of Windows. Funny that Bill Gates, in an email to his people, did not find the Windows usability thing all that funny. He should have heard Joel go through it as he struggled through patches, reboots and warnings just to upload some photos from his camera.

Overall, Joel made salient points about providing good feedback to users, keeping them in control of their experience and obsessing over all aspects of the experience. To me, this was a great statement about the whole “put it out there” movement in startups driven mainly by facebook applications. Yes, it is good to get user feedback sooner rather than later, especially before embarking on a mammoth development effort. But don’t sell yourself short by releasing a product that could be better with a little more effort and time.

I had mixed thoughts about the keynote speech from David Heinemeier Hansson. Ruby on Rails is truly an innovative combination. Before I give you my opinion of the talk, let me give you some analogies for what I think is innovative.

Developing in RoR is like building a house for the first time using a nail gun instead of a hammer. It’s like the first time you drove a car with power steering and power windows. It’s like the first time you created a server side product using Web technologies where as before you had to write code to handle requests, package data, manage connections and all that ugliness. It’s like the first time you took a flight from SF to LA when you used to drive because you were in college trying to save money. It’s like…(had enough???).

David is the founder of the RoR movement. He talked about the surplus created by having a superior tool as something developers should take advantage of for personal improvement. On the whole, this is not a bad concept. David felt that developers should use the time savings to sleep more, learn to whittle or even to fly a plane. Yes, it was mostly a humorous point. Our engineers should use the fact that they have a “better, faster tool” to take time to smell the roses.

However, in my opinion, this works against why Ruby on Rails is one of the fastest growing technology movements around. People are switching to RoR because it is faster. There really isn’t enough evidence yet to say it is better than other choices like Java with Hibernate and Spring or PHP with CakePHP. The surplus time should be used to extend this advantage and get more people and companies on board. After all, who would you hire to build your house? The guy swinging an old hammer or the guy with the nail gun and power drill? And what would you think if the guy with the power tools took a nap every day on site because he knew his tools were faster than the way they used to build houses? See my point?

The reason this language is selling today is exactly because of the faster angle. If you take that away, then you don’t quite have the history and track record yet to stand up against more established technologies. You have to get over the tipping point a little and then you can take a snooze.

Before I forget to mention it, Portland, Oregon is one rocking town. If you believe the whole “smell the roses thing” that David was emphasizing, I recommend you do it there at around 11 PM on a Saturday night. I know this has very little to do with the conference. Still, I have to give credit to the conference organizers for picking a cool location.

One goal for myself at the conference was to gather information about RoR scalability issues. I can now say that I am not worried at all after listening to a panel discussion from a group of guys responsible for about 4 billion Ruby requests a month. Representatives from EngineYard, Rails Machine, LinkedIn and AOL talked through their experiences taking RoR to the max. The big take away is that people need to think of scalability in terms of the entire system. The best coders in the world can’t make poorly designed data objects or under-powered hardware go any faster, for example.

We heard a keynote talk from Kent Beck later in the week. Kent is the visionary behind many innovative ideas including Test Driven Development and Extreme Programming. I recommend you Google Kent Back then read a lot about him and his ideas. And buy his books too! But make sure you form your own opinions which I think is his real goal for everything he creates. What is super impressive is how Kent sees the big picture, long term stuff. He talked about how real change, or rather the true fruition of his creative ideas, takes on the order of 20 years to go from concept to accepted practice. Talk about a visionary! Good call on Test Driven Development Kent.

In the end, I walked away from the conference convinced more than ever that Ruby on Rails represents a next generation approach to scalable Web development. I am a true believer after listening to a dozen sessions on various topics including scalability, project management, lessons learned from Web application development, complex searching and others. But the strength of any tool is in the people who use it. After all, a good carpenter is just as effective with a hammer as a nail gun.