Tuesday, July 19, 2011

What a web start-up engineering team should set-up pre-launch.

When asked this question a flurry of thoughts came to me and I stuttered to get them out. Here is my list and the reasons why. Note the basics of my reasoning comes from the desire not to wake up at night to fix a bug.

Agree to a base language:

Syntactic sugar should be agreed upon. Building things in different languages at the start without the teams acknowledgement is just building a walled garden.

Agree to use the same code format:
The team needs to agree to make the code look the same. Make a decision on tabs over spaces, DOS or UNIX format, class / directory layout, MVC or procedural etc.

Agree to a source code repo:
Revisions are good, use source control

Agree to a bug tracking system:
Don't just use email or spreadsheets use a free open source bug database and make an interface for users to add bugs. If a user is frustrated enough to write a bug, the least an engineer can do is take the time to read their problems.

Agree on what to launch with as your base architecture. (Doesn't mean it can't change)
How is the data stored? How is it accessed? What is the payload size? Where is the data coming from? What is the latency? How can I monitor it? When does it break?
These are some sample questions that each team member can answer (at least a majority of them).

Build tools to push code via one or two clicks.

Build general tools about your users, your data, management for uploading to CDN, packing JS etc.

Build a stat system to record exceptions, page load times, stats from apache, stats from the database or system in general and if you are uber make it the same stat system used for Business Intelligence.

The same system that tells me how many unique returning users also reports what the mysql system resources are.

Stats are crucial for any organization, know when and why (realtime) when a user experiences a problem as well as when a new user joins.

Have fun, learn and be productive for your users sake :)

What else would you add?

1 comment:

Ejsmont said...

All very good and valid points.

I would also recommend drafting a rough structure of internal wiki for the project documentation. Noting down guide for new developers and establishing agreement with the business about development process.

I personally love SCRUM but no matter what methodology you are going to use you should make sure that all involved are on the same page and know the rules of the game.