A collection of musings on software design and development:
Testing without requirements is just a pointless activity of exercising the compiler and demonstrating the programming language.
Software that lacks documentation also lacks a clear reason for its existence–it is easier to throw away undocumented software than it is to discard something that someone took the time and effort to document.
A badly written requirement is worse than having no requirement at all. Without a requirement there’s at least a 50-50 chance of getting it right.
Programmers are not software engineers.
A debugger can be a useful tool or a crippling crutch–it’s up to the user to decide which it will be.
Programming on-the-fly with a debugger is just hacking.
Large amounts of buggy data and/or control coupling in a program usually indicates that it was created with little or no up-front design.
It is an undisputed fact that fixing a design defect after software is released will cost vastly more than fixing the defect at the requirements or design stage.
Unit testing is not the last word for software verification, it is only one small part of the whole testing scheme.
Functional testing demonstrates the acceptability of a software product, but without functional requirements there is no way to design effective tests.
There is no “best” language, and there is no “best” editor. It’s all a matter of using the most appropriate tools for the job, and then mastering the tools to be used.
Creating unreadable software is about the same as spitting in the face of the next person who has to try and decipher it.
Just as good art demonstrates skill and thoughtfulness on the part of the artist, so too does well written and readable code demonstrate the skill and professionalism of its author.