Rules are made to be broken, this is a quote I live by and use extensively for software design. The quote came to my mind reading the post by Jeff Atwood on Programming rules and the following post. The idea of programming rules, the vast majority of programmers that are clueless of programming ideas and more even of systems, makes me understand the difficult position of a system engineer.
Most programmers see programming as a work, something for making money, so one can so something else with the money. Only 20 percent are move involved, see themselves as craftsmen, wanting to improve. Of those 20 percent, only a few read book, look for information and methods for growing. These programmers will read about programming rules, about guidelines and methodologies and will try to embrace them.
This is the place where the system engineer can make a difference. The guidelines and rules provide a path for generalizing the problems or solutions and put them in a reference frame. The reference frame of software design can be suitable, but it can also guide the poor programmer into really bad concepts that are taken from a completely different world. Hence the system engineer should be the one providing the guidance, understanding the frameset of the guidelines, helping implementing and helping in the selection process. There are so many rules and guidelines, so the selection process is critical.
Back, to the quote; its “Rules are mostly made to be broken and are too often for the lazy to hide behind” by Douglas MacArthur. It explicitly says what’s required:
- Understanding the rules
- Understanding why they should be broken
- Don’t use the rules as excuses
As a system engineer, design of software is not done with a simple cookbook of rules, but with deep understanding and breaking the rules.
If you read this far, you should follow me on twitter here.