Artistic Reality

Sometimes when you are dealing with the high politics of a system that might have major impact on an industry, you may run into a wall of confusing interests. How did the status quo come about, what are all the vested interests, if you change a practice what else might be affected? I find that when I have allowed my hips to be buried in the muck, first I doodle for about fifteen minutes, and then I set myself down and draw a Reality diagram. This is a concise way to describe, on a single sheet of paper, all the psychics impinging on a project. It is comprised of five quick sketches, each a slightly different flavor, describing various elements and relationships surrounding the projects "reality."


The first diagram of Physical space, shows a hypothetical activity that encapsulates a typical event ranging across a variety of actors. Man A stabs man B, who seeks help from doctor C. Okay relax it was an accident. B works at factory D.


The second diagram shows Ethical Space, basically who has spiritual "claims" on others for their actions (or omissions).


The third diagram shows Contractual Space: the understandings, paper, and legal relationships between the parties.


This fourth diagram is more of a list, a high level classification of the types of information each party keeps that are relevant to your system.


The last chart shows Financial space: simply how the money flows between the parties. So now you've got a piece of paper in front of you that succinctly summarizes the entire Reality surrounding your project. Does this solve anything? No. Does this tell you what to do next or make your life any easier? Probably not.

Yet I have found that this diagramming is an invaluable tool, because it shows you why things are the way that they are, the nature of their balance, and the interplay of the forces between them. It frees you from the muck because it shows you the difference between the hard and the soft limits. So unstick yourself: get real!

Artistic Meta

With marching orders and a vague foggy vision of where you are headed, you are ready to create the Meta-Project. Not the project itself, the Meta-Project enwraps the actual project creating an environment for it to succeed. The Meta-Project is more of a thought process, something you keep to yourself, in your heart, to guide you to a successful completion. In an earlier post I described how to resolve the utility-cost-speed triad; this is the other half of the mental preparations required to launch a project.

To start you need to create the tone, the environment under which your project will proceed. Sometimes you will need to be methodical and professional, moving slowly with each step well-documented. You may need to get management reaffirmation and written approval all along the way. At other times you may need to create a blender, a whir of activity that juggles six balls at once. You may need to generate enough excitement that your coworkers get overwhelmed with enthusiasm and complete the project for you. I can not give you guidance as to the appropriate tone for you to succeed in your project -- you need to use your intuition, foresight, and knowledge of the culture at your company to determine what will work in your environment.

I usually find it helpful at this point to sketch out figures of my thoughts. One such drawing is a graph of "risk space" -- along one axis I label Risk, and along the other I label Volatility. I then draw circular regions that indicate representations of where each design option would land. Some projects are risky because they have a high probability of technical failure: this may be due to an increased complexity brought about by the interaction of multiple layers of software, or perhaps because the development language itself presents certain challenges of learning and implementation.

Some projects are risky for political reasons: they might for example shed light on why certain business units of a company are performing poorly, or the software may replace the functions of another system that already keeps several staff members gainfully employed. Some projects may be risky because the goals are ill-defined, or no single person has enough authority to assure completion, or the people in authority are themselves insecure and may not be around at the end of the project for support when you need them.

Volatility is intended as an estimation hedge. The risk for any one implementation may run from low to high: if all the factors are well known then the volatility should be low. On some projects you will get the gut feeling that you are in for a barrel of surprises however, where most of the problems will surface during development or after implementation. In this case the volatility is high. "Type 3" projects tend to be volatile, because you can expect to incorporate new technologies and deal with new staff as the project develops. Some small projects can be surprisingly volatile, not for anything inherent in the design process itself, but because of business uncertainty. If the corporation is undergoing severe changes, then smaller projects tend to get swept under the rugs and scrapped easily.

By preparing yourself thoroughly mentally before a project gets under way you will glide through all of the challenges that it presents.

Artistic Optimization

I suppose that from a certain perspective an analyst can argue that success really depends on the optimization of the person. In other words if you focus on optimizing your self, then everything else will follow naturally. Here is a cogitation I had a couple decades ago where I explored this in greater detail. Basically, you spend your time....

Learning
Teaching
Organizing
Reviewing
Creating
Re-creating
Investigating
Playing
Resting

Everybody has their own individual needs for time allocated to each of these items in order to feel comfortable. If you have too little of an item to do you will either search for something to allocate more time to it, or you will feel uncomfortable. If you have too much of an item to do you will either find a more efficient way of doing it, or you will feel uncomfortable. You can not become more efficient with an item until you are willing to find more of the item to fill the time you need allocated to it.

Some general excuses that folks use to rationalize their inefficiency are:
+ I already have enough work to do and would not be comfortable with more.
+ I do not want to be more efficient because then I would not have enough to do.
+ I am already satisfied with the time I ave allocated to these items.
+ I feel uncomfortable allocating more learning, creating, or playing time to become more efficient.

Here are hints on how to become efficient across the dimensions of your activities.

Learning
Learn Learning: do you keep your eyes open for more efficient ways to gain information?
Teach Learning: do you share your good sources of information with others?
Organize Learning: do you track where to go to find things out?
Review Learning: how long until you realize that an old source of information is obsolete?
Create Learning: do you imagine a better way to learn something and then seek for that method?

Teaching
Learn Teaching: What inhibits your sharing your sources of information?
Review Teaching: is the information you share still accurate and do you teach it well?
Create Teaching: imagine -- who might benefit from your knowledge?
Play Teaching: do you share what you know anyway?

Organizing
Review Organizing: are your current methods of organizing still efficient?
Create Organizing: what could be the ideal way for you to organize? Can you find help?
Play Organizing: do you experiment with your current methods?

Reviewing
Review Reviewing: can the information pass though fewer hands? Can it be created more accurately to start with?

Creating
Create Creating: do you think of /how/ you want to create? Might there be better ways?
Review Creating: why are you locked into your current methods of creating things?
Play Creating: do you experiment with the means by which you create?

Re-creating
Review re-creating: do you organize your creating in the first place?

Investigating
Teach Investigating: do you share your investigating techniques?
Organize Investigating: do you keep track of your methods?
Review Investigating: are there more efficient ways for you to investigate?
Create Investigating: might there be better ways to investigate? Who provides them?
Play Investigating: do you experiment with new ways to analyze your information?

Playing
Teach Playing: do you share the things that provide you with new thoughts?
Review Playing: do you realize your old habits are no longer fun?
Create Playing: do you imagine techniques that might develop new ideas?

Resting
You rest most efficiently when you have nothing to do.

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.

The Art in a Game

Most of the software developers I know enjoy playing some kind of computer or card game, and they all gain some insight into good creative practices as a result. My muse is FreeCell and here are the lessons it has taught me:

Be aware of long-term problems
Sometimes a key color-number combination, such as both black 10's, can be near the bottom of separate piles. This inhibits your ability to complete long strings of builds in any column. Avoid making the problem worse by burying the color-number combination deeper. You can also end up with two of the same color card in the same pile. Don't just focus on one of the long-term problems: be aware of both of the long-term problems.

Take advantage of short-term opportunities
It is probably a good idea to face an ace (or one of the next cards for the home pile) by just moving one card up to a FreeCell, as long as you have other moves afterward.

Use mid-term strategies
Don't focus on the long-term problems (although be aware of them) and don't focus on recklessly moving cards up to the home pile. Rather, take the mid-term strategy and capitalize on long builds and emptying columns. Keep variety in your hold cards.

Maximize flexibility
Given the choice between moving cards home and gaining the flexibility of an empty column, choose greater flexibility. Think twice before leaving yourself only one open FreeCell. Patience is a virtue.

Think ahead
Plan ahead for what a move might enable -- does it allow you to open up another FreeCell or mitigate your long-term problems?

Use the hidden force
Sometimes the answer lies with forcing cards home biasing a single suit. This might be alright if it increases your flexibility elsewhere.

Be persistent
When you are stuck, take a break and do something else so that you can return later with a fresh outlook.

Know when to bail out
Sometimes a deal is just too difficult. Know when you are "in over your head" and bail out so that you don't waste your time.

I'm sure that these are all metaphors for certain things you encounter during the development cycle, but find your own metaphors in your own games. You don't have to be good at any game in order to learn its lessons, but you do have to play at it occasionally.

Artful Giving

Many useful things in our modern world are “free”: in software development you especially rely on a panoply of information (particularly when grappling your way out of a bind) pulled straight from the Internet. For “free”.

When you are a growing child your parents sacrifice their time for your benefit, to increase your skills. Society expects the same from you when you age: folks wish that you contribute as much as you have received.

Code snippets, online help, device drivers, shareware. In the end you only gain the equivalent amount of value from the public commons as you yourself have contributed. This manifests itself through subtle activities that reveal their knowledge to you by their methodology and yet that methodology won’t instantiate until you create your awareness upon it through researching your own contributions.

Help your future self therefore by paying it forward: give back to the professional world the same as you would your own children.

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 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.