For what it's worth

A little while ago for a proposal we did, I wrote up some ideas (not original to me) about doing application development. Thought it might be worth posting though, again, there is no implication these ideas are original:

a) Elegance is always worth the effort.

Elegance is about doing things right, doing them efficiently and doing them in a way that allows for expansion and easy maintenance.

b) Solve the general problem first; then use that solution to solve the problem to hand.

In other words, don't hack together one-time solutions; instead when confronted with a single problem or requirement, figure out what the general problem is and build a generalized solution to that problem. Make sure that general solution fits with the rest of the architecture and, in fact, expands or improves the architecture. Then, use that high-level solution to take care of the specific problem (if the specific issues even still exists).

c) A well-designed architecture anticipates and accommodates future problems including currently unknown problems.

If every time something new surfaces, you find yourself struggling over architecture or fighting with your infrastructure, you have bigger problems than you think. Step back and revisit the overall architecture to improve it ? doing new things shouldn't be that hard!

d) Technology is there to serve business strategies and needs.

Technology for technology?s sake may be fun, but it isn't the way to get work done.

It is okay to use cutting edge technology when it fits the business need at hand, but don't use it just because it is "cool."

e) End-users are important; technology is not.

The importance of the end-user doesn't only surface when it's time to deliver or support an application. The end-user should be involved from the beginning, helping to shape the application's features, interface and outputs. It is, after all, the end-user who has to live with the end product every day. They should have some say from the beginning.

f) Technical implementation is at its best when it doesn't bring attention to itself.

Getting the job done in such a way that the user doesn't notice or have attention on the technology is a key element of success. Unless the application is intended for developers or other technologists, end-users shouldn't have to know or care about anything technical.

g) Don't assume current limitations will last forever.

Quite the opposite, question every limit and constraint, assume they will be exceeded or surpassed and see if your design still works. Too often, either one day before or one day after the application has been put into production, someone will want to exceed a limitation they earlier swore would "never" be reached.