The design of many software applications begins as a vital image in the minds of its designers. At this stage it is clean, elegant, and compelling. It has a simple beauty that makes the designers and implementers itch to see it working. But then something begins to happen. The software starts to rot, over time, the program worsens in quality, the rotting effect increases, with a little bug here, a little hack there, and the program becomes a festering mass of code that the developers find increasingly hard to maintain.
The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.
The ideal numbers of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification ‐ and then shouldn't be used anyway.
"The Three Laws of TDD: 1) You may not write production code until you have written a failing unit test. 2) You may not write more of a unit test than is sufficient to fail, and not compiling is failing. 3) You may not write more production code than is sufficient to pass the currently failing test."
[Most managers] may defend the schedule and requirements with passion; but that’s their job. It’s your job to defend the code with equal passion.