Preface: this is the third of three articles on the subject of “Principles - in Software Development” and Agile Software Development specifically. The previous pieces are: Software Principles 1 of 3 and (Agile) Software Principles 2 of 3
Many years ago, so many I’ve actually lost track, but I think I can trace some of these back to ACCU Overload in 2002, I penned my own rules and law of software development. In writing the principles blog entries I though it would be worth revisiting them and seeing if they still held.
(Given that it is so long since I coined these laws it is also a question of whether the next generation of programmers agree with them.)
Kelly's law of advanced code complexity:
- Any code that is sufficiently advanced will appear as unmaintainable to a novice (Adapted from Arthur C. Clarke)
I still think this law holds. I still hear from developers who have taken over a code base and find that the original developers used some whacky coding techniques. In some cases the code was simply bad but in a fair few cases it is really advanced stuff. C++ is still the worth offender but Java generics and Aspect Oriented programming also feature.
Kelly's First Law of project complexity:
- Project scope will always increase in proportion to resources
You could argue that this law is an application of Parkinson’s Law (“Work expands so as to fill the time available for its completion.”) and I’d be prepared to concede.
Funnily enough, there is another Kelly’s Law, coined by another Kelly, a Mike Kelly (Kelly is a very common name). Mike Kelly’s Law is: “Junk will accumulate in the space available.” Substitute jump with scope, and space for resources and you have the same thing - QED :)
Kelly's Second Law of project complexity:
- Inside every large project there is a small one struggling to get out
Kelly's Law of Software Subtlety:
- Subtlety is bad - if it is different make it obvious - Write it BIG!
This is also thinking behind The Documentation Myth in 2006. These days I tend to state this as:
- The bigger a document is the less likely it is to be read
- The bigger a document is, if it is read, the less that will be remembered
There you go, over three entries I’ve documented some general principles, some Agile principles and some Laws. Let me know what you think.