In startups it’s so important to make an impact (Go to Market) early and as efficiently as possible, with the resources at hand, and while following proper software engineering methods. Many companies fail because they never deliver, or simply deliver too late. Timing is everything. It doesn’t have to be perfect. Below are some recommended strategies to follow:

Rule #1: Get to market, now — Per Guy Kawasaki, “Don’t worry be Crappy“:

“Don’t worry, be crappy. An innovator doesn’t worry about shipping an innovative product with elements of crappiness if it’s truly innovative. The first permutation of a innovation is seldom perfect–Macintosh, for example, didn’t have software (thanks to me), a hard disk (it wouldn’t matter with no software anyway), slots, and color. If a company waits–for example, the engineers convince management to add more features–until everything is perfect, it will never ship, and the market will pass it by.”

Well, in reality, you can’t afford to be crappy, but the point is to get to market fast, as early as you can — there is always time to go back and address things.

Delivering early means running pilots or Betas, to learn about the customer, learn about what you produce, and about related business models.

Rule #2: Set proper expectations. Following #1 above (deliver early to market) set the expectations that “this is an early version, work in progress”. Be explicit that the early version is a pilot, or a Beta version. This is very important, especially if you want to convert current Beta customers.

Rule #3: Reflection period. Once you have delivered/hit the market, it is time to look back, reflect. Reflect about the product, the methods or processes used; were these too loose or stringent? Separate enough time for this. Do the design and code reviews you couldn’t do earlier due to go-to-market pressures. It is OK. Developers and QA engineers, talk about what and how to improve the product; this is the time to refactor, refactor, and refactor:

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a ‘refactoring’) does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.

See the refactoring catalog, maintained by Martin Fowler.

Also, use this time to document (see Wiki below).

Rule #4: Keep track of issues and new feature requests. No need to go over board and spend thousands on issue tracking products. Use a simple issue tracking system, there are many. Trac is a simple but effective one.

Rule #5: Implement an internal Wiki. Trac also has an integrated Wiki. Use the Wiki for your documentation. Document, document, document. Use the reflection time to document. Documentation is that task all developers hate (rather postpone), but a very important s/w engineering life-cycle step it is. Organize the Wiki as you like, perhaps per Tier. When hiring new folks, point them to the Wiki to learn the system.

Rule #6: Use Version Control. Use Subversion, or CVS; use whatever you want, but keep it simple. Tag/branch at major releases. Use version control for your documentation as well. Integrate your Wiki with version control.

Rule #7: Establish a build process. Start simple, but eventually do automated daily builds; use Continuous Integration.

Rule #8: Test, test, test… Start simple, but eventually move to automated testing. Performance, stress, concurrent testing are of great importance.

Rule #9: Use popular open source projects and frameworks. Nothing beats the already adopted and fully tested projects. In addition, as my good friend Edmund says, “what good does it bring the customers to re-invent already proven frameworks?

Rule #10: Start simple, grow as needed, try to anticipate: people, processes, functionality, complexity.

ceo