I've been thinking a lot lately about all the small utility apps I've programmed over the years and how I could have designed them better.

I loosely define a utility as any project designed to solve a singular and specific problem for a certain situation or business process.

For example, I built a small PHP application that accepts an export from an ecommerce store and parses the data into another format needed for a specific business process.

How could I design these better?

I normally build a utility by having an idea of a problem to solve, and I jump right in to an editor and start typing.

Some time later, I find myself wanting to steal functionality from old utilities, but when I go to reuse some code, I find out how badly I programmed the thing! Generally I don't spend a lot of time on small utilities, so they are programmed without classes, namespaces, or even OOP. Procedural FTW!

It's made me think that I should be more organized, even in tiny projects.

Here are some issues I now consider before starting any new project.

1) The basics are required!

Regardless of how tiny the utility is, practice good programming! Use proper source formatting, naming conventions and commenting. Another developer should be able to see what's going on in the code with little effort.

Avoid procedural coding where possible.

I no longer allow myself to write sloppy code, even if the project is tiny or of limited use.

2) Define the project

It doesn't matter if the utility has a single function to perform: it should be well defined before coding begins. The definition of the app will include basic declarations, like who will use it, what data it will expect, and what output it's supposed to give.

Define data sources, security concerns, and whether the app will grow with more functions over time.

Where will the utility be hosted?

The more detailed the definition, the easier it is to pick tools and stay in scope while programming it. This is especially true if you're programming for someone else!

3) Will others work on it?

If other programmers will be involved, increase your documentation and commenting. Use source control, and focus on separation of concerns in your classes and methods.

If no programmer will ever need to read your code or work on it except you, keep to the basics and don't overwhelm yourself. Just make sure you can still make sense of it!

4) Source control?

Depending on the context of the utility—such as if it is an internal project for an organization that will own the work—the code may be hosted in a public repository. If so, increase documentation; add a readme.md file; add DocBlocks to define ownership of the code, and use Semantic Versioning.

If there are concerns about intellectual rights and who owns the code, this would require you to throw a license in there.

5) Do I have to maintain it for the long haul?

If you foresee future development, assume that others will work on the app, and that it therefore needs source control, improved documentation, and a license attached.

You may not be the person to maintain future versions if the app is internal to an organization. It's better to spend the extra time on these chores than for future programmers to dismiss you as a poor programmer.

If you write well-documented code, you may be able to come back later for a letter of recommendation. (You can't take company-owned code with you, but at least you'll have a letter confirming all your work was good!)

Continue reading %13 Tips on Designing and Building Apps More Efficiently%

Source: SitePoint