Lazy Initialization

Don’t Repeat Yourself.  It’s a powerful principle for eliminating duplication in code to facilitate easier change.  It should not stop there though.  If fully embraced, DRY can help you improve your system, your team, and even your organization.  Automating testing, deployment, and other processes can free up more time to make other improvements.  Uniting your team under a common set of values, principles, and practices can help team members more efficiently communicate and work together to make progress.  Establishing a consistent vision and message for your organization to rally under can help your teams to understand the work that needs to be done.  Failing to do any of these things means you are at risk of repeating yourself either on performing tasks that you shouldn’t need to or rehashing the same discussions to get the team working together and understanding each other.

If we stop repeating ourselves, we can use the extra time to make real progress, otherwise, we are often working hard to stand still.

• dancingmango - Where’s the vision
• Ayende @ Rahien - Requirements 101: Have an automated deployment
• Meme Agora - Thanks for flushing…er, Building
• High Scalability - Robert Scoble’s Rules for Successfully Scaling Startups

When creating new software it is important to give simple meaningful names to the features and concepts that we create.  This allows us to communicate effectively with other team members and, more importantly, the users.  It can sometimes be difficult to give names to all of our concepts.  I believe that this is because modern software combines both established concepts that are familiar to the users as well as evolutionary ideas that were often not possible without computers.

It is important that we take care not to introduce more new concepts than are actually necessary to the user.  In the past I have seen features that have concepts with names like “base configurations”, “templates”, and “flavors” while the user only cares about the simple overall feature.  I have also seen vague lower level ideas like “pipelines”, “modules”, and “reflection” exposed to the customers.  Introducing ideas like these will usually just confuse the user (and often other engineers) while providing no actual value.

If you are considering adding something to your system and are having difficulty giving it a name, you probably don’t need it.  If your features do not mirror existing concepts in the user’s domain or established software patterns you are either adding unneeded complexity or developing revolutionary new designs.  I would not bet on the latter very often.