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.

Artistic Coupling

Creating software is similar to making a building but it is also somewhat different. You do need to start with a strong foundation of understanding the business rules and users of the system you are creating. This is usually captured in some graphical modeling. But once you start putting the pieces together the process should feel more like you are doing the interior design of a modular office.

Especially if more than a single developer is doing the programming, you want to leverage the concept of "loose coupling". This is a series of techniques, cautions, and an awareness that enables components to gradually change without breaking the interconnections between them.

One way to do this is to persist intermediate results to a database or file. A great advantage to this approach is that it's easy to mock up test data while you're still developing so that your work doesn't hold up anybody else. This does cause quite a bit of overhead however for high-activity classes or processes.

You can also provide loose coupling by adhering to strict standards in your object-design methodology. The types used on return values for methods and property set and gets should be strictly defined and maintained. If you need to provide more information back from a method than a simple system-type then define your own structure, but avoid using weak data types.

To maintain loose coupling you also need to avoid changing types after you have "published" them, as I described in this earlier post about maintaining modular compatibility.