Artistic Analysis

Every once in a while you get a lifetime project: the development (or more typically the redevelopment) of the central system that pumps the heart of a business. The toughest part of this challenge is nailing the initial analysis. On such a large, mission-critical system, getting the analysis correct is both an immense responsibility and terribly vital. So to aid your developers your first set of deliverables should be:

1) A sociological analysis. This should include a full detailing of which employees are best at performing what functions, and how that will mesh with the new system. It should consider how the project will survive the politics of the employer and its staff, and supply contingencies in the case that certain key people fail to demonstrate any new skills you may require from them.

2) An object-oriented analysis. At an early stage of a project the best you may be able to provide is a UML of the abstract objects, but you should at least gain an understanding of how all the business objects and methods fit together, as well as a sense of data flow and any timing dependencies.

3) A strategic analysis. You should understand the strategic plan of the company and of the I.T. department, and should detail how this development effort will support these plans on all time scales. You should also accommodate the Gestalt of the SDLC to your company's ever-changing environment.

Before coding can begin you will need to understand many other components (screen wireframes, project timelines, implementation strategies, physical architecture, state diagrams, and coding and security standards), but these are fairly typical of all projects. Take extra care however in your Project from Jupiter to be attentive to generating the analytical viewpoints from all three dimensions.

The Art of the Stretch

Many things that contribute toward a successful software-development career have nothing to do with people skills or even with technical knowledge. A larger part of accomplishment than you imagine simply has to do with being comfortable with the physiology of an “office job.”

Essentially you sit in a chair a couple feet away from a screen with your hands on the mouse and keyboard all day. Folks euphemistically call this a “sedentary” job. Don’t think for a moment this implies that you lie in a hammock twirling a double mocha cappuccino.

Due to constantly changing tools and requirements the job is full of stress. Other stressful factors include too much work, frequent interruption, unclear or late information, career and job politics, and the pressure to outperform associates. Programming can feel as if you have five pots on the stove, the microwave whirring, and both ovens going, all while you are mincing onions.

So although the job is sedentary in the strictly physical sense it is far from stress-free. To really succeed you need to develop a strategy that fully mitigates this stress; here are some techniques I have used to good effect. First, why do you need to pile additional stress onto your work from commuting? When you drive your car to your job listen to something enjoyable or motivating. Or better yet ride public transportation to work and multitask your relaxed commute with some reading. When you do drive experiment a bit to discover which routes are the most scenic and least crowded.

Learn how to organize and plan at work. This mostly relieves stress by a process of self-education: once you get a good concept of how long things take you can also plan for your own personal slack time. Heck even back in school they allowed for “recess.” Pace yourself: avoid back-to-back scheduling and trying to fit too much into one single day.

List the things that you have to complete by priority; by accomplishing what is most important you will feel more serene. Don’t fret over finishing every last thing: modern lean-running offices always have more to do than the time available. Rest assured that most certainly your boss feels the same overwhelming inflow.

Laugh! Don’t overdo the clowning around, but when you find something appropriately humorous share it with your friends at work. Try to leave earlier in the morning. Even 10-15 minutes can make the difference between a frantic rush to your desk and having time to ease into your day. Stop adding to your stress levels by running late.

Finally, exercise. Every couple of hours take a brief break from your work to walk around outside, thus allowing your eyes a varying distance of focus. Do some carpal tunnel stretching at your desk and during your breaks. Pay attention to your sitting posture and consider the ergonomics of your work environment. Every so often sit quietly, turn on relaxing music, breath slowly and deeply, and stretch.

The Art of Debt

I am often surprised how frequently developers fail to make database modifications simply out of laziness. Say you have a customer identifier for favorite color, and the values tend to be either blue, yellow, or red. Now say you add a new attribute to a customer and this attribute only applies to one existing subset that already exists.

Say only customers who put red as their favorite color also like beets. Should you add a new field (named beets) or should you split the "red" values in the existing field to "red likes beets" and "red dislikes beets." All too often I see folks go down the path of trying to squeeze additional information into the existing fields, "red likes beets."

Sure this requires changing less programming logic immediately but it also builds up "technical debt" by increasing the analytical complexity in the future. In short it trades elegance for immediately impressing the boss.

And this really gets to the crux of the matter in the Art in software development: do you shoot for pleasing the boss, or do you aim for a pleasing future?