While all of these design principles and practices will certainly help you to write better software there are lots of them to learn, and lots to remember. When you actually sit down to write some code and you’re under pressure to get it finished as soon as possible some of the best practices can go by the way side.

Here are three acronyms that are simple to remember and will almost certainly help you to write better software. So whether you’re writing a small function, a class or a large module spare a few minutes to think about these acronyms and hopefully your software should end up being easier to use, test, maintain and understand as a result:

DRY

Don’t Repeat Yourself – The DRY principle is about not repeating any logic or knowledge throughout your software, it’s about removing duplication. At the very least this means that repeated code should be moved into a function or class – no copy and paste! Taken to an extreme it means even things like a database schema and database interaction code should be generated from a single source. In their book The Pragmatic ProgrammerAndy Hunt and Dave Thomas recommend the use of code generators to help remove all duplication from a project.

With no duplication software becomes much easier to maintain. If something needs to be changed you know you’ll only need to change it in once place. It should also be easier to understand and test as a result.

KISS

Keep It Simple and Stupid – The KISS principle is about avoiding needless complexity, and keeping things as simple as possible. This doesn’t apply just to code, it can also apply to features. As 37Signals say in their free book Getting Real, which contains lots of suggestions for maximizing simplicity:

“The key is to restate any hard problem that requires a lot of software into a simple problem that requires much less. You may not be solving exactly the same problem but that’s alright. Solving 80% of the original problem for 20% of the effort is a major win. The original problem is almost never so bad that it’s worth five times the effort to solve it.”

Almost by definition simpler software should be easier to use, test, maintain and understand – so don’t forget KISS!

YAGNI

You Ain’t Gonna Need It – YAGNI is about not writing code now for things that you think you might need in the future, because the chances are that you won’t, and even if you do the software you write now will likely be less than ideal for what you actually need in the future.

As a Software Engineer it’s easy to get carried away and think about generalized solutions to the problem you’re working on, or other ways in which your code can be used. This isn’t necessarily bad, and thinking about these issues can certainly aid maintainability and software reuse. The point of YAGNI though is that we shouldn’t actually write the code until we need it. Otherwise we have to maintain code that may never be used, and the time could better spent on other things.

The “Do you Scale” presentation I saw at PHP London a couple of months ago gave a good high level overview of scalability issues, and included some useful techniques to help you scale.

I think I’ve found the ultimate scalability presentation though: “Real World Web: Performance & Scalability”. The 189 slides contained within this presentation cover almost everything I’ve read elsewhere, and it’s packed full of practice advice!

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

Design patterns were made famous by the book Design patterns: elements of reusable object-oriented software, written by the Gang of Four, or GoF. Although I’ve never got round to reading it, it is fairly high on my to-read list!

Despite not having read the GoF book I’m still aware of some of the more common design patterns, such as the singleton, factory, and iterator patterns. Such is the nature of patterns that I’ve probably used some without even being aware,after all they are just common reusable software designs.

I recently came across an excellent website that gives details on all of the GoF design patterns, including descriptions, UML diagrams, and sample code in Java, C++ and PHP! The site isn’t good enough to displace the GoF book from my to-read list, but I’m sure I’ll find it useful for the mean time.