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.