Principles

On requirements

1. You ain`t gonna need it - Always implement things when you actually need them, never when you just foresee that you need them.

2. MoSCoW method (Must Should Could Won`t)All requirements are important, but they are prioritized to deliver the greatest and most immediate business benefits early. Developers will initially try to deliver all the M, S and C requirements but the S and C requirements will be the first to go if the delivery timescale looks threatened.

On project scheduling

1. Brooks`s law - adding manpower to a late software project makes it later. "Nine women can't make a baby in one month"

2. Parkinson`s Law - always time each task. Work expands so as to fill the time available for its completion

On Design

1. Analysis paralysis - over-analyzing (or over-thinking) a situation, so that a decision or action is never taken, in effect paralyzing the outcome. A decision can be treated as over-complicated, with too many detailed options, so that a choice is never made, rather than try something and change if a major problem arises.

2. KISS principle - Keep it simple stupid. The principle is best exemplified by the story of Johnson handing a team of design engineers a handful of tools, with the challenge that the jet aircraft they were designing must be repairable by an average mechanic in the field under combat conditions with only these tools. Hence, the 'stupid' refers to the relationship between the way things break and the sophistication available to fix them.

.... It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away

3. Rule of three ( not two as many think , three!) - Rule of three is a code refactoring rule of thumb to decide when a replicated piece of code should be replaced by a new procedure. It states that you are allowed to copy and paste the code once, but that when the same code is replicated three times, it should be extracted into a new procedure.