Artful Choice

While sipping my morning coffee in a Starbucks I overheard a building contractor say, “Good fast or cheap… choose any two.” I recognize this aphorism as a common quandary that binds all designers together whether we work on architecting buildings, developing software, or drawing illustrations.

So how do you approach an intelligent method for making that choice? It seems to be a decision that definitely happens early in the software development cycle, usually during the initial architectural and interface planning.

In a earlier post I discussed the other half of the meta-surrounds of a project; here we look at how to go about approaching choices that affects the first half. I will begin with quite a concrete explanation — a description that makes the process sound precise and analytical. Implementing it is more an art than a craft, and hence it is easier to begin by explaining its craft-like aspects.

Imagine if you will a triangle with each corner labeled: one is quality, one is speed, and one is thriftiness. Your project will end up as a dot somewhere within this triangle, but for now you just want to be able to draw a circle identifying the target area for where you wish to land.

To draw this circle however you need a side step to another chart: the one that maps your company’s strategic plan based upon its competitive position and the growth stage of its industry. The proximity to the thrifty vertex depends on whether your company is “harvesting” and winding down or if it is growing explosively in a new industry.

The proximity to the quality vertex depends upon how you are positioning yourselves in relation to your competitors, the talent pool that you can draw upon, and if such quality provides a material advantage at this stage of industry development.

Finally the proximity to the speed vertex depends upon the urgency of implementing your strategic plan, typically higher at the industry start and end-points than in the middle.

So now that you’ve got your general target the art kicks in: typically none of this is something that you can explicitly relate to your staff. Instead you guide the developers toward the circle within your triangle by your plans, attitudes, and actions: you try to instill the habits in them that will land the project at its goal. Good, fast, or cheap? Choose the appropriate mix.

Artistic Frustration

Sometimes you can spend hours working on a piece of code as you refactor it toward a more logical organization (and persistence is certainly one of the key traits to being a successful software developer). If you find that you are getting increasingly frustrated however as you unearth the ever expanding treasure of technical debt, then step away from the keyboard and go out for a walk.

Frustration is the development environment's way to tell you that you need to approach this differently. Maybe start off with a clean slate, a new class, maybe even a standalone project, and then add the functionality you were tying to cull from elsewhere. Be persistent, but avoid swimming up to your neck in the marsh trying to fight the alligators. Start a new marsh instead.

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.