An Artful Environs

In an earlier post I discussed the vagaries of herding the cats of developers. Here I want to chat a bit about motivation of creative developers in a more diffuse sense -- about how to create the environment that allows for quality and valuable software to "materialize."

This is nearly a diametrically opposite approach to the conservative management of a formally enforced SDLC. And it only tangentially has to do with software. First, consider in general what motivates an artist: a desire to be creative, a desire for recognition, a desire to be challenged, and a desire to stand out amongst their peers. Maybe they seek glamour, or grunge, or just to make an aesthetic statement. Maybe they want to promote a socially redeeming view.

Considering the amount of demanding self-discipline, focus, sensitivity, and work that this requires, how do you create a comfortable supportive space in a world of abrupt changes, insecurities, hidden stakeholders, control freaks, and conflicting priorities?

Mostly it helps to be honest and open in your approach. You don't have to necessarily build a consensus, but it does help to lay all of your cards on the table: acknowledge both the staff needs and the strategic challenges as well as how you plan to enable the former through the onslaught of the latter.

Yeah that by itself seems like a considerable undertaking, but the mere process of discussing it with your staff and your superiors will get you on the same page. At least it will settle the expectations toward how much of the developers art you can bear under the freedom of the muses versus how much of their work must yield to the dogma of the Methodology.

The Art in Pseudo

Most new development work starts with ideas or directives or change orders or functional specifications. From this comes diagrams and wireframes and state diagrams and use cases and UML. From all of this documentary scaffolding one would think a person could just sit down and start coding. But for design work that is more involved than just the standard form-based update to a database, one more step will be helpful: the pseudocode.

In carpentry there's an old maxim "measure twice, cut once." Pseudocode does this same pre-measurement for you when you are programming.

Consider for example this recent change order I received: "Send the file Monday through Friday night at the time specified in the parameter unless the Stop flag is set in the database. Allow an override flag in the database to send the file immediately without otherwise affecting the schedule."

It looks simple enough to describe, but once you start programming you will trip yourself up without some pseudocode that considers the last time the file was sent and the actual time of day. Don't be shy to create the pseudocode if you have any doubts about any boundary conditions. And review the pseudocode with the user to help prevent any unintended misunderstandings.

Artful Estimation

In the corporate world it's hard to get any significant work assigned to you unless you can arrive at the correct mix of accurate and acceptable estimations.

The method that works best for estimating depends to a great extent on the size and scope of what you are developing. Not that surprisingly the magnitude of error in your estimation also increases in parallel to the size of the project. Small projects such as one shot utility programs are best estimated by your gut feeling from experience. Such tasks rarely last more than a couple of man days.

Adding a bit of functionality to an existing system can be adequately estimated by breaking the project into component estimates. Say one day for database design, a day for user interface, a day for testing, tweaking, and modifications. More or less depending on your development environment.

If you are fortunate enough to be developing a middle sized complete system from scratch, then you can use a standard project management tool, fill out tasks and estimates, then resource leveling, addition of slack, and then add an additional 15% for each resource assigned to the project.

Somewhat counter intuitively estimation for exceedingly large projects works better if you don't go through the effort of summing up the cost of individual component tasks. Very large projects are dominated by the costs associated with inter personal and inter system communication, plus the overhead of change control. For that reason a tool based on the well researched interplay of these factors, such as Cocomo, gives the best results.

Estimation is an art that you develop mostly from experience. Remember to use the method that is appropriate for the overall size of your project.