Artistic Principles

Above all else a commercial software development environment (like almost all of life's endeavors) is about relationships with other people. You have a relationship with the folks who will use your software. You have a relationship with your bosses. You have a relationship with your employer and its investors. You have relationships with your coworkers.

How does a person stay balanced and serene amongst all of these competing interests? I like to follow these three principles.

The Zero Point Protocol
Relationships can end unexpectedly at any time, no fault of yours or even of your own doing. Hence in order to prevent usury one must always maintain a fair and equitable social balance in all relationships.

Sure progress is made by give and take: you give your work in return for a salary, or you give your mentoring in return for, say, an inside position or a future referral. The Zero Point Protocol assumes the stance that all of your work relationships may suddenly end: how would you feel? If you would feel angry and cheated then this indicates you were probably giving too much to begin with. Always keep your relationships balanced and grounded at zero.

The Principle of Equivalent Commitment
Many times relationships feel out of balance since you are investing more of your future into a process or products than the recipient is investing back toward your future. Keep commitments honest and balanced by gently suggesting ways that relationships might be strengthened. Avoid sacrificing your future for the sole benefit of others; make sure they promote your future as much as you promote theirs.

The Principle of Perceived Value
Always assess your fellow employees to gauge how much potential they have for appreciating you and what you have to offer. If you sense that a person legitimately lacks the capacity to even perceive what you can offer, then you shouldn't waste your time with them.

These are intended only as principles for your use during employment; family and friends behave quite differently and ascribe to different values. Keeping these three Principles in mind at work however will keep you both productive and safely balanced.

Artistic Planning

After you capture all of the functional business requirements, nail down (with both the management and the technical leads) what architecture you will build upon, and identify the key resources who can create your system, it's time to settle in to some serious project planning.

The general approach to follow for successful planning is:

Gather all the tasks that you can foresee the developers will need to accomplish
Get rough estimates for the time for each task
Become familiar with and enter the tasks into some project management software
Include holidays, vacation, jury duty, and slack time
Tentatively assign employees to accomplish tasks
Add task dependencies
Add task priorities
Level the resources
Reassign resources and tasks until the project plan "feels right."

When possible I like to add a couple days of "slack time" every month. Slack time is not allocated to any particular tasks, but allows a window where the developers can add overlooked items, or where the staff can catch up on tasks that you underbudgeted. Planning to recover from mistakes also make sense if you care about quality. Don't be afraid to allot extra time to tasks where you have the most uncertainty about your estimate of the required effort.

Integrating project planning into the workload of existing employees is quite a bit trickier than having staff dedicated to your own standalone project. You may need to get a percentage commitment from the manager of your shared staff that allows them to still dedicate time to other projects and their ongoing tasks.

Don't be surprised if your first several plans miss their mark: it is quite easy to underestimate the quantity of tasks involved to develop and implement software, as well as the programming time required. It is always best to consider your project plan more as a telescope to organize thoughts and tasks, rather than as a fence that commits and pressures the staff.

Artful Heroics

Management tends to overlook the quiet heroes; this is especially true in Information Technology. When the hardware fails -- the server crashes hard -- the folks who patch everything up and get it working again get a slap or the back, accolades, and a nice mention in their performance review. But the guy that quietly monitors performance every day, cleans up the old files, optimizes indexes, and releases old record locks, goes completely unnoticed, even though his work keeps things running smoothly.

Naturally since I.T. folks are smart and recognize this, you tend to find that they decamp into two philosophical groups. The first group maximizes their perceived value by purposefully being lackadaisical in maintenance, all the while squirreling away the tricks they know for recovery. Then they can spring out of the phone booth in their Superman suit when the time is right to be the eventual heroes.

The second group though, the Artful Heroes, quietly and unselfishly keep plugging away, patching and making small unnoticed incremental improvements to keep things running smoothly. For they recognize their reward when they look into their manager's eyes and see the acknowledgment that their manager indeed knows their value overall.