Software development principles for an engineering manager,architect and developers

1. YAGNI - You Aren’t Gonna Need It :
   The YAGNI principle says that do not build something just because it might be needed later. Basically it says that do not build any code/features in the product that are not currently needed. This prevents the team from spending a lot of time planning for some grand, imaginary and unknown future scenarios. This will save time as most likely you do not need it or what you actually need is quite different from what we foresaw. This prevents teams from over engineering something based on what we think we might need later on. It is based on the idea that things will change with time. The principle saves you time twice. First, you don’t spend it now on something that you might don’t need. Second, when you reach the time when you need it, you don’t spend time in rewriting and refactoring but write once and well.By no means YAGNI is against planning and thinking in advance, it only encourages taking stuff into consideration NOW but postponing the implementation to later on
   Ask the YAGNI question

   "What are the chances that You Aren't Gonna Need It?"
   
   

2. KISS - Keep It Simple, Stupid:
   KISS is a principle that states that everything should be done as simple as possible. Applying KISS principle helps teams from over complicating problems. In my experience in the world of software development, developers tend to relieve the boredom of routine jobs by implementing an over complicating solution even when there exists a simple working solution. It feels great and exhilarating to do that until someone else needs to fix, maintain or modify the implementation. I must confess that I myself have done that many a time. One of my mentors once gave me a good analogy that I will not forget...an expert is some one who makes the job at hand look how simple it is and not vice versa. When ever we get back to our own code and start scratching our heads that sure sign that something got complicated than it had to be. Do not use all the fancy OOP, threading, frameworks just because you can.
   It is very simple to Implement the KISS principle. Whenever we come across a solution to a problem ask yourself " is it really the simplest way to do it? "
   Just remember
   
   "Some of the world's greatest algorithms are always the ones with the fewest lines of code. And when we go through the lines of code, we can easily understand them. The innovator of that algorithm broke down the problem until it was so easy to understand that he/she could implement it.Many great problem solvers were not great coders, but yet they produced great code! "
   
   For further reading on KISS
   http://people.apache.org/~fhanik/kiss.html
   
   

3. DRY - Don't Repeat Yourself:
   DRY is a principle that encourages to automate/extract tasks/code that we seem to be repeating again and again. DRY is aimed at reducing duplication and having a single point of maintenance. This principle can be applied in also not generalizing an implementation as a framework before we come across the need to repeat it again and again.
   
   
4. Premature optimization:
   Premature optimization is a term coined for the practice of trying to optimize the code to run faster when the code/functionality to be implemented is in a fluid state. Do not forget the well know statement " get it right then make it faster”. Do not get hung up on writing a fast-optimized code before getting the functionality right. The rationale is that it is most likely that the optimization that might be done prematurely might account to less than 3% of the actual bottleneck.The following quote from Donald Knuth in "Structure programming with go to statements" summarizes the problem perfectly
   " Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all-evil. Yet we should not pass up our opportunities in that critical 3%."
   
   
5. Principle of Least effort :
   The principle says that people and even well designed machines stop looking for better solutions once a solution that minimally matches the acceptance criteria is met. Applying the principle helps us to find the most effortless paths to solve problems. It promotes a quick and simple design over elaborate systems designed by committees.
   
   
6. The partew law of 80/20:
   The law in the field of software states that 80% of the user will use only 20% of your features. By understanding the rule and identifying the 20% of the features that 80% of the users use we can concentrate the resources and time on those 20% of the features to produce a better product.

Many senior developers and architects even though well versed with these principles tend to be applying them only when they feel like it and miss the spirit of these principles. As one of my mentor used to say the word is "Resume Driven development" , teams tend to over complicate , try new api's , frameworks and do a lot of wastage disregarding the business goals and objectives. This is the very reason and importance for the management team to be well versed in the field of the development to be able avoid this kind of wastage.