These vary from year to year as well as the type of software you are writing, but this day in age the following principles are directly related to large scale software development I have seen a lot of large systems, a lot of over design, as well as some designs that were right on point. Our engineering field is always about a balance. This balance is between timeline, functionality, and design. There is no golden rule, its about knowing what to implement, how to design, and when to stop polishing. The two most common mistakes are over design and too much furniture polish.
If I could only teach 3 principles to a new hire they would be
I read this once, and it pains me I can’t remember where, but they related Kaizen to bug fixing. Any time you find your self fixing a bug, it talked about fixing the other code around it. A lot of times bugs are a direct result of bad code. When it comes time to stop the bleeding, people just stick on a band aid.. they don’t think about disinfecting the areas around it.
- Good Enough
I once worked at a client that had multiple projects all lead by different consulting companies.
Our company produce a “good enough” designed product that balanced: leveraging bleeding edge technologies, functionality, and most importantly the project plan. We delivered a functional product, on time. It did everything that was asked, in a basic way. We then worked on beautification.
Another company, full of Microsoft MVPs, developed a product that was bleeding edge, completely beautiful,and months behind schedule. On top of being late, the use of too new technology and attention to too much UI detailed left a product that was over designed and buggy.
The concept is to know when to cut corners, and when to get something working correctly, and then going back and polishing it up… if needed of course.
- YAGNI – (You aren’t going to need it)
This one relates to keeping systems simple. Countless times I have seen clients implement things for future use, and by the time the future gets there it is completely wrong, un-maintained, or poorly documented. Sometimes its better to keep things simple and only implement what is required now.
Further reading? Enter the web of links starting with Common Software Development Philosophies.
I have also posted a similar question to a group of software developers http://stackoverflow.com/questions/3514844/top-3-software-engineering-principles and am awaiting their thoughts.