We see a very interesting pattern for launch dates in requests for proposals (RFP) that we receive. Nearly everyone who starts development from April to August wants to launch in October. The trends makes sense when you consider seasonality. The difference between April and August is obviously significant. Yet, companies seem to want the same amount of functionality regardless if development starts in April or August:
“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?
Posted by bbenedict 