Software development empirical rules

Random thoughts

All your codebase will totally rewritten from the ground-up several times during the project lifecycle. You can write good code, several times faster than the best of your code. Write good code, not the best.

Each codebase rewrite will eventually contain more bugs than the previous one.

Sometimes the only way of moving forward is to throw everything out, and start from scratch.

When talking about performance or improvements, everything not based on metrics can be considered just an opinion.

Designing software is an iterative process. The number of iterations is always one more than the number of iterations performed at any given time.

There is never a single right solution. On the contrary, there are always many wrong solutions. A dev should know where he/she lies in.

Software is built from requirements. It is worthless to develop something not asked for. Corollary: it will be worthless as well to try to developing to outsmart the requirements.

From the required use cases, only a small percentage will be used. Go figure the usage of not requested use cases.

100% secure software will take an infinite amount of time and effort. Make your development ready for failure.

Time is the only shrinking resource.

There are no important stakeholders watching during the moment when the project works like a charm.

Blaming does not make your software better.

Being right is worthless. You can in fact take my gist, and suddenly be twice as right as before !