Kelly's Law - concluding principles (3 of 3)

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)

This came from looking at C++ meta-programming and some of my own experiences handing over C++ projects - see High Church C++ and The Developers New Work.

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

I am even more convinced of this law than I was 10 years ago. The more people, time and money put into a work effort the higher the expectations. Plus, add in dis-economies of scale and big efforts are doomed.

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

This law is really consequence of Kelly’s First Law. If you have a project with lots of resources the original project will get lost inside of it. All too often the real mission in turning around a failing development effort is liberating the small inner project.

Kelly's Law of Software Subtlety:

• Subtlety is bad - if it is different make it obvious - Write it BIG!

This law is really about communication. Its saying “If something is worth saying then say it properly”. I think the law still stands. In many ways the visual tracking, Kanban boards, cards and what not in Agile is an example of this law.

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

While this has obvious applicability to requirements documents it is generally applicable to just about all the documentation we write.

Epilogue

There you go, over three entries I’ve documented some general principles, some Agile principles and some Laws. Let me know what you think.