An Artful Measuring

I see a fair amount of debate on public fora about how and when to manage the "commitment" by the various interested parties to a system design. Somewhat oddly and even counter-intuitively, you run as much risk nailing down the balance too early as you risk by delaying until it's too late.

It helps to identify the champions and get them on board early; if you don't you risk the backlash that folks will feel slighted by being omitted from the initial design decisions. If you get everybody who's invited immediately hyped-up however, you will find that some of the champions burn out before you are ready to release them: you will need their cheerleading later for positioning and they will show up in body only, not in spirit.

A sublime key to the success of a project therefore is to involve all the interested parties early, yet manage the commitment level of user and department champions so as to be able to rely upon them when you will most require their decisionmaking abilities. You need to quietly "measure" your progress and then anticipate when you will be needing their support. If you lose a key champion early, your project may be unrecoverable.

An Artful Outside

It is rather unusual to be directly involved in a design where the interests of your customers are opposed to those of the larger public, primarily because they are a subset of that public. Some system designs however get targeted to a small and distinct enough set of customers that conflicts can arise; the subset may have interests that are notably at odds with regulations.

Who do you design for? How do you balance staying employed with doing the right thing? In this case the owners of your company prefer that you bend toward customer ends, yet provide enough plausible deniability to keep them out of hot water. I like to distance myself further; take a step back from your knowledge and provide a method that feigns ignorance. Essentially you allow the customers to bend the regulations without encouraging it. You allow the customers the freedom to determine their own karma.

The takeback, the saving grace to your own soul from adopting this approach however, is that you must use your private non-work time promoting awareness and supporting the very regulations you fear your customers may violate.

Artistic Balance

When you walk into a place and grab its culture by its cajones you affect a wide range of lives, yet you ultimately live alone with the mental and emotional consequences of your actions. No matter what you change, some folks face the risk of falling out from the short side of the equation. They may have to learn to accept new job responsibilities, or they may even be made redundant by your changes.

Clearly however /somebody/ has a chance to reap benefits from your efforts (besides yourself). The changes that you can actually successfully materialize therefore depend upon how you manage the delicate balance between interest groups. I'll examine how to achieve this in later posts, but first let's look deeper at the power dynamics of employment across all of the interested parties.

Every business exists to serve four groups of people: the owners of the place, the employees, the customers, and society-at-large. Without the support of even one of these components a business gradually disintegrates. Depending on the nature of the business these broad categories may sometimes be further refined to include subsets or agents, such as unions, neighborhoods, tax authorities, shareholders, et cetera.

For the purposes of general interest groups though these independent categories suffice. As an analyst and change promoter you need to consider how the group balance and its dynamics may be affected by your activities.

In the next couple posts I'll examine the interplay between these categories by pair groupings. Before we pair off though let's spin briefly about the seriousness, feigned flexibility, polarization, and positioning of these sides. Although I will discuss them in general as if they are two competing teams on a football gridiron of the corporate battle, in reality they are composed of groups of individuals who are, after all, just people.

They eat breakfast, they have families, they have health and financial issues. They have tastes in food and music, and their lives have had their own joys, curiosities, and sorrows.

When you are negotiating a position between two groups, always remember first and foremost that you are dealing with a collection of individuals. Strive for a general utility for the entire group, but also recognize that even within a single category, say the managers, you will find differences of opinions toward your actions.

Artistic Diplomacy

In a larger project your success will depend upon your concordance to the appropriate strategic plan for your company. This is a fairly sensitive and deep subject: nothing seems to be as politicized in a company as much as the knowledge and implementation of its strategic plan. Many of the decisions and tradeoffs that you make very early in the architectural design will depend however upon a firm understanding of how your company will spend money, invest, and hire people across a range of various timeframes.

To further complicate matters once you have this wisdom, even though you may use it to guide system design decisions, it may still be in your best interest to safeguard your insight as private. High diplomacy may be in order.

To reach this firm foundation you need to understand your company, its finances, the industry in which it competes, and your direct competitors. You can research some of this through public sources, but you will still need to rely on the experience of the smarter and more senior employees for their knowledge.

Most people will be happy to give their counsel and experience if you establish a non-confrontational and supportive friendship with them. You also need to understand and appreciate the nature of their advice, and be thankful and willing to give them public credit for their ideas and contributions.

Most companies (and industries) follow a natural cycle of growth and decline. Even companies approaching the end of their utility however can still keep folks gainfully employed for a short while; under such circumstances you will certainly focus your approach more on quick results than long term maintainability, yet you still need to proceed in a courteous and professional manner.

Finally, remember to always balance your decisions with your innate sense for what is the right thing to do.

Artistic Growth

More than most professionals (perhaps with the exception of doctors) software developers contend with change and growth.

Outsiders identify the instigators as advances in hardware and new deployment platforms, but when you're deep inside the works -- a fish in the fishtank -- the view of change and growth are quite different.

From inside you see your assignments and what the nearby developers are creating, along with occasional somersaults from the development environment. Food drifts down in fits and starts. Occasionally you get a new bubbly castle.

In the workplace you tend to get caught up in the office rivalry to impress your boss with your capabilities; you want to eventually move up the ladder from programmer1 to the lead software architect. In this industry staying static -- just creating with the same level of technological adeptness -- is a certain downward spiral. It's like being a plastic plant: you may look really good all the time at just one thing, but nobody is going to get terribly excited over what you have to offer. After awhile you will disappear amongst the accumulated algae.

People acquire skills on the job in various fashions, with as many styles of growth as fish have personalities. One key element to success however is to challenge yourself by volunteering when you smell opportunities. The way you move beyond what you currently know is to step outside of your comfort zone and offer to assume responsibility for something that is slightly beyond, slightly harder than what you think matches your present capabilities. Then the only way out of this predicament is to learn new things and to ask for help.

You need to make an occasional leap out of the fishtank into a new body of water, spawn and reseed yourself once in a while. Growth is all about the research, the struggle, and the experimentation. And more than anything growth is about the stretch.

Artful Observation

Now that you've slept with that little software baby of yours for the past three months (or past year) you may feel confident that you actually know how it works. Do us all a favor though friend and patiently watch it run. And no I don't mean by peering over the shoulder of the user or by firing up a remote server-session to view the batch-log scroll by.

No, really watch it. Turn on the full eight-hundred-million candlepower searchlight and glare that baby down to its bones. Numerous tools enable visibility to the hardware utilization; you can even configure the lowly task-manager to show such useful metrics as GDI objects, memory use, CPU, page faults, threads, and network activity (the big six resources).

Is your process pegging a CPU? Do you have a memory leak? Did you fail to deallocate objects? Are you performing way more disk IO than you need to? Are you losing control of the quantity of threads that you are spawning? Are you hosing the network? Well maybe you should fix it!

During the heat of design and development it's certainly less demanding to code things for quick creativity that end up just wasting resources. Code that runs efficiently, however, is also code that allows for scalability. Raise the bar on the quality of your work: refactor those resource-hogs and take the time to seriously watch your application run.

Artistic Targets

Unfortunately it's exceedingly difficult to be both a great painter of landscapes and a great portrait artist. Or to be an exceptional travel writer and an author of thrillers. For similar reasons, developers end up specialized toward specific targets, across the dimensions of both deployable device(s) and targeted subject matter.

Sure some of this happens because we get typecast, but mostly this is due to time limitations: to excel at user interface design or a particular IT subject matter you must invest the effort to become totally immersed and familiar with it.

Yet as an artist, it also benefits a developer to expand his repertoire to adjacent presentation formats and related business fields. This is easiest to accomplish at the fuzzy borders of both. When you are designing a web page, see if you can also do a "light" or a mobile version. If you are working on CRM development see if you can stretch into analytics.

The main benefit of this -- aside from the obvious increased skill set to offer employers -- is that (like an artist) your new experiences will cross pollinate with the old, making both stronger. This is only beneficial to a certain depth however: if you attempt to be a jack of all trades you will find that you are a master of none.

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.

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.

The Art in Conception

Once you have sold a vision and made the commitment on behalf of yourself (or your staff) to actually create a product, the magic of conception unfolds. Somewhere deep in your conscience you have the basic concepts of how the final product will look and behave -- in other words you've got the general parameters of a target -- but how will you get there?

Rather amazingly in our modern gadget-driven world, the best approach is still to sit quietly in a nice sunny room with a window, a pencil, and a pad of paper, and begin sketching. Draw out your concept, write down your concerns, and show all of the pieces and how they relate to one another. Make lists of the things that you need to store.

Then you're ready for some more presentable modeling. I usually like to start with three diagrams: a state model, a sequence diagram, and either an entity-relationship diagram (if you're focusing more on the data structure) or a UML diagram (if you're focusing more on the objects). The purpose of all this however isn't actually to convince anybody of anything, but rather to help clarify your own thinking and to pique new insights.

Now put the diagrams down and go out for a walk. Or better yet do the diagrams on a Friday and spend the weekend exploring around town.

On Monday look at your drawings with fresh eyes. What did you overlook? Things always turn out to be more complicated than you initially anticipated. Who do you need to talk to in order to clarify matters? Are there more robust ways to create your solution? Something that might be more flexible?

This first couple weeks of a project are magical but they are also a bit frightening. We make architectural decisions that fairly rapidly get set in concrete. So don't rush yourself through this aspect of design -- consider all of the possibilities. Then after you've nailed your design parameters comes the real stickler, user interface design.