Our run-down of why we should design our applications brings us now to: what does it mean to design our applications? Many things to many different people of course, but here are my quick lists - first of what it does not mean, and then what it does mean.

What does designing NOT mean?

• Making everything a class.
• Using UML.
• Having a complete API before starting to code.
• Using classes at all.

You might expect a talk with this title to preach that using a procedural API would be bad, but it isn't necessarily - I prefer object-based, but a well-organized procedural interface can be just as clean a design. Objects are a little bit stricter in enforcing consistency, and they do give you more tools, such as data hiding. But you don't always need them.

As for the other points, UML can be useful, but it can also be a huge time sink, a bore, and pretty useless. Classes can be overused; an API in which everything you deal with is an object can be overwhelming and tedious to work with. And expecting to have a complete, final plan before writing a single line of code is unrealistic; you'll just waste time only to end up changing some things as you go anyway.

What DOES it mean?

• Having a plan for an API, and considering everything that it affects, before starting to code each component of an application.
• Writing organized, consistent code.
• Being aware of code duplication, and being willing to refactor as you go.
• Being wary of the easy path.

Planning an application component by component is a much less daunting way to go. By exploring all of the parts of an application that a component affects or interfacts with, you are much less likely to find holes or API flaws that require extensive recoding later, but you also give yourself manageable chunks of work to start on - some design, some coding, more design, more coding, etc. A tangible sense of progress is essential to the health of any developer.

Consistency and organization IS code documentation. By that I don't mean that it is a replacement for documentation, but it is an essential part of it. One of the frequent debates on the PEAR dev mailing list is "Why do we have to follow coding standards? I like to do this instead, can we change the coding standard to my way?" And there are the individuals who feel like having a coding standard is an attempt by some PEAR elite to force their preferences on everyone else.

They're all missing the point. The coding standard is relatively arbitrary; those who proposed it didn't agree on all of it, and there are things in it that all of us prefer to do differently. But the gain of having a consistent codebase far outweighs a little personal inconvenience. Not having to adjust to different coding standards between files or classes means less of a learning curve for every new class you read through. Having consistent APIs, function naming, and variable naming means that you can expect certain things to always work a certain way, and be confident that they will. This is a hugely underestimated reduction in the learning curve of using a new API. And asking for all code to be cleanly organized isn't a way of keeping others out; it's a way of ensuring that new developers will be able to maintain the code and that it won't languish because no one else can puzzle out what it does.

Finally, refactoring. Refactoring is the single most important thing you can do as part of your development process to ensure that your code stays well organized, well designed, and maintainable. Whenever you have to revisit a piece of code that you've written before, try to take a few minutes to go through it fixing documentation, comments, code style - anything that might have slipped the last time it was changed. Look for code blocks that are similar to code blocks in other components; if a pattern occurs enough times, consider making it into a new component or utility class so that you only have it implemented once. In this way you'll continue to keep the size of individual components down, and also keep adding usefulness to your overall API.