Artistic Intent

Are you curious about what all these "ethos" posts are about, and what they have to do with designing a software system? Well like most of life's endeavors, the world is interrelated: how you comport your personal life greatly influences the results you may achieve professionally. Since people "see through" the fascia you construct, they are more concerned with the actual results of your efforts.

Work is the movement of stuff with intent and purpose; the more you ground yourself in higher principles, the better your guiderails constrain your movement. Resolving the ethos of software design usually distills to this: who do you ultimately answer to? Your supervisors may impose deadlines, restrictions, or duties that compromise your prime directives or disturb the balance between businesses interest groups. Do you follow their guidance or instead march to your own drummer?

Viewed from this level the project you are working on becomes an artifact of how you manage the relationships between all of the interested business parties. You don't constrain these relations by confining them to little boxes that you drive around the tabletop. Rather you retain these concepts in your head in the midst of your meetings and decisions: the impact of your ethos is more effective if you allow the parties to divine your intent, rather than explaining it directly.

Isn't there a lot more to analysis, like gathering and negotiating requirements, maybe a bit of competitive analysis, wireframe prototypes, and perhaps some development platform and tool reviews? Yeah sure you get to do that too, but those tasks happen within the mundane auspices of your day to day work. They occur more on the "material" plane and less on the "mental" plane. Managing your ethos however is the full metal jacket.

Artistic Bonsai

A software developer faces dozens of constraints, from tools he may use, languages his employer supports, hardware and network availability, et cetera. But the largest constraint of software design is what lies between everybody's two ears: the capacity of their brains.

When you are initially designing a system and have finished your requirements solicitations and focus sessions, the first challenge that pops up is how to structure the functionality of the system into something that overlaps adequately to the mental capacities of those who will use it. They possess a certain capability to remember paths of navigation and where to set various field values to achieve specific business objectives.

Brain capacity also tends to limit the creative canvas of developers: you need to know enough of a subset of current technologies to be useful, yet you have to leave adequate "internal storage" to accommodate the intricacies of the domain knowledge for your employer and their industry.

Hence brain capacity planning is similar to bonsai gardening: the constraints force you to be artistic within the limits of your containers.

Artistic Simplicity

In an earlier post I pointed to some general principles you should abide by when developing software. Two of these, parsimony and perspicuity, could use a bit of further elaboration. Together they delineate the promotion of a simpler approach to design. Why is simpler better?

As the saying goes, "there's more than one way to skin a cat." Relax it's just a saying, I have nothing against cats. The point however is that given any coding challenge there's usually an algorithmic technical nifty way to get it done, and a more lengthy but more easily understood mechanical way around the problem. The technically elegant way will execute faster and may allow for some future bells and whistles that can be accomplished with just a couple of extensions. The more transparent, simpler to understand, lengthy code will take longer to execute and will require more lines of code when it eventually becomes time for a new feature.

But frankly the longer code is easier for a novice to understand. And in the modern corporate world of high employee turnover, constant technological change, and shifting management fads, the longer code -- because it can be maintained by newcomers -- realistically has a greater probability of staying in use.

Simplicity begets Longevity.