Member requirements

1. Work towards the goal!

• No matter what this document defines, or how specifically your task is defined, there is no way to define exactly what should be considered good for reaching our goal, and what should be considered bad.
• You have to work towards the goal.
• When you work on something, you have to understand why and how it is related to our goal.
• You have to try to drive the whole team towards the goal (no one alone is capable of reaching it).

2. Be honest!

• You have to present the situation to the leader as is.
• Do this, even if it does not look good.
• For example, if you have no idea how to make something, don't say "almost done" to the leader.

3. Take initiative!

• If you find a way that you can make something better for the team, don't wait but propose that it to be done.

4. Look around!

• If you see problems in the code, in the product, in the organization, or whatever, announce them.
• Try to keep an eye on what other people do (either for things you can learn from, or for things they are doing poorly).
• Try to get a global vision of what is happening in our team.

5. Seek improvements (for yourself and for the team)

• No matter how good you are, there are always more things you can learn, or skills you can acquire (note that knowledge and skills are different things).
• Improving and learning is your responsibility.
• Not trying to understand how things work, but learning that this does this, and that does that will lead you nowhere! Really! Even if you've programmed for 20 years it's possible to make this mistake.

6. Seek the most appropriate solution!

• There is no perfect code. There is no perfect solution (or even if there is it is not reachable).
• There are no general good design rules - a design is good if it works well, if it is easy to use (for example, if it is a library, the clients don't need to write much), if it is simple, has good performance, is modifiable/extensible, testable, etc. Neither the number of design patterns used solves this, nor a code convention... nothing. You have to find a design that is good.
• Hacking around just to make things work is usually a time bomb. It is not acceptable to do this, because saving 1 day this month usually costs 7 days the next month.
• What we should do is to seek something between just making it work and making it perfect, but closer to perfection than just working.
• That is, seek a good solution.

7. Quality is not negotiable! Scope and resources are

• If something cannot be done with acceptable quality, given the resources (time) and scope (functionality) that it has, then we will either reduce the scope or increase the resources.
• We are not allowed to reduce quality!

8. Accept the challenge!

• We are not doing the next Store Information System, the next Lawyer's web site, nor the next database module for big company X
• What we are doing is something that only few companies in the world can do, and even many of them are not good enough.
• There are no instructions on "how to make the next generation desktop publishing software"!