Wednesday, December 11, 2013

Artistic Specialty


To some extent folks adopt their software development specialization depending upon their own skills and tastes: do they feel more comfortable with a broader and lighter background or do they prefer to be deeper and more focused? Managers may also have a strong influence over how employees develop their skills simply by the tone and expectations that they set.

Obviously software development requires some specialization, since the technological complexity and the rate of change in our profession precludes a sole person from spending the time required to be a technical expert at all the myriad skills that span the available range of tools. If you wish to employ an expert a direct corollary will be that you therefore choose a specialist. If you plant a honeysuckle tree, you are going to get hummingbirds: that's the sort of specialist this tree desires.

Selecting specialists for software development presents some challenging issues. Unlike hiring engineers to design cars -- where once the model rolls off the production line the engineers move along to their next project -- hiring engineers for a software project is likely hiring them for the entire life of the system.

In this instance the problem that a manager faces is that quality, job security, and concurrency are in opposition. Asking your staff to specialize may give them greater job security and improve the quality of your operations, but they will lose their awareness of how to incorporate and apply new tools and hence lose their personal marketability.

If you hire a specialist to do the job then the result is going to be somewhat unmaintainable by anyone but that specialist. If you hire a generalist it will be far easier to maintain the resultant system, although the final product may well appear less slick and polished.

Ultimately then who you hire depends upon the "positioning" your company is trying to achieve. Are they looking for a short-lasting expensive best of breed solution? Or something long term, stable, and adequate? What sort of tree exactly are you planting?


Wednesday, November 13, 2013

Artistic Goals


Developing software is both about balancing competing forces and optimizing numerous goals. Down in the trenches all of this happens within the craft of describing to the computer what to do by using a programming language or development tools, but it is still beneficial to keep in mind at a much higher level what should be the general objectives of /any/ large software system:

+ Validity
Your software must meet its functional requirements

+ Parsimony
Keep it simple, avoid bloatware, use a declarative approach that saves intermediate values

+ Incrementality
Plan from the start to make your software readily extensible by incorporating real-world modeling

+ Perspicuity
Strive for clarity and aesthetics; make both the use and the maintainability of your software intuitive

+ Modularity
Remember the advantage of being maintainable and reusable, stay functionally focused, but loosely coupled

+ Resiliency
You need to be tolerant of system faults and provide excellent error recovery

+ Adaptable
Hardware can change -- be flexible for changing environments

+ Performance
Strive to be both efficient and fast

... and yes, these are in precise order of importance.


Monday, October 28, 2013

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.


Wednesday, October 2, 2013

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.


Tuesday, September 17, 2013

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.


Wednesday, August 7, 2013

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.


Wednesday, July 17, 2013

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.


Wednesday, June 5, 2013

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?


Wednesday, May 15, 2013

Artistic Ownership


The managers at many places I have worked confuse the fruits of our work (lines and lines of programming code) with “intellectual property” and with knowledge. It is a convenient deception, but it ultimately causes more problems than it solves. Let’s take a look at precisely what these concepts are, why code and knowledge get conflated, and the problems that ensue.

This is somewhat akin to confusing traintracks with a railroad. A manager walks in and says “oh, that guy is a direct path to Denver, that guy goes to our hub in Chicago.” But a railroad is a whole lot more than traintracks. It is also the locomotives, semaphore crossings, stations, leased rights of way, you get the idea.

“Lines of code” is a semi-fluid corpus of rules and instructions that implement business logic. These change as customer or management needs allow and they also get modified in reaction to bug fixes and refinements in technology. They are like traintracks. In nearly all cases the software code is the property of the owners of the company. So sure the railroad owns the traintracks. Yet there is so much more.

In the context of software development “Intellectual Property” is actually a narrowly defined term. Occasionally it may be a patent, but for commercially marketed software it is more likely a copyright. Most internal-use software (the bulk of what we create) is Intellectual Property by means of “trade secret” and employment work-for-hire agreements. So these are like the leases held on the rights of way.

The code isn’t an “asset” in the sense that a physical piece of property is an asset; it lacks a particularly liquid “market” and the rules and peculiarities it encodes keep little value when transferred to a non-related owner. Selling your traintracks to Australia doesn’t do them much good.

“Knowledge” in this context encompasses three overlapping concepts. First it is a domain-specific understanding of how things are supposed to work conceptually or legally. Second it is the cultural understanding of who is proficient at maintaining what. And third it is the historical insight into how things evolved to reach their current state. Software developers employ this knowledge (which resides primarily in their heads) to produce lines of code from the influx of rules, regulations, requirements, and bug reports. So the knowledge is the locomotives, semaphore crossings, and stations.

It is convenient for a manager to jump from the work-for-hire agreement to the (mistaken) impression that he “owns” the knowledge in developers’ heads. In this way he conflates the human “resources” through the midpoint of Intellectual Property to the endpoint of an “asset” that he owns and manages. He confuses the traintracks with the railroad. Although convenient, it is wrong in that it loses pieces in the translation, creating dangerous side effects. It is like thinking you can pick up the traintracks, move them to India, and suddenly have the Southern Indian & Pacific railway.

Knowledge isn’t transferable nor is it intellectual property. And if you move people from their areas of expertise the company effectively loses their knowledge. Sure it still owns their code, but after the company saddles somebody new with maintaining the code they have to reacquire the knowledge of how to do so. They have to relearn how to run the railroad.


Thursday, April 11, 2013

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.


Thursday, March 7, 2013

Artistic Standards


SOPs (or as we often call them nowadays “best practices”) get the usual bum rap but I like them as an educational tool. Standards and best practices are fine to the extent that they promote a safe and productive workplace without adversely affecting a sense of job security. For example “Always use camel case” is a good standard to improve productivity. “Keep your source code in three places” is a best practice that enhances safety.

Wielding standards like an axe over your employees’ heads will only create defensive animosity. I prefer to use them as search terms when I want to find a template or an example to share with somebody. For instance I might Google “best practices SQL maintenance” and see what it returns.

If your employees feel however that the purpose of your standards is to turn them into interchangeable cogs then at best they will only implement them halfheartedly and at worst they will spoof compliance. Make positive, non-corrosive best practices your standard operating procedure.


Friday, February 8, 2013

The Art of Compatibility


What does it take to be compatible with a long term software development career? Quite a bit, actually.

At inception projects may call for numerous meetings so you need to develop courtesy and show some ability to conduct the initial interviews with a bit of panache. If you naturally have the skills of an insightful listener then you may tend towards gathering requirements and performing analyses.

If you’re leaning heavily toward analysis then you will need to develop an understanding of strategic planning and what goes on behind the scenes in your company and in your industry. For management-facing positions writing and salesmanship talents are also essential.

If you’re more inclined toward the technical aspects of the profession then you need a strong grounding in logic and the aptitude for being well organized. Patience, research agility, and persistence will carry you far when you are coding.

A fair portion of your work will be teaching people how to learn to be competent in technically challenging tasks or instructing people on the intricacies of how your software operates. You must develop a patient and understanding attitude with those you teach: what may be obvious to you might be opaque to others.

Although creative work is satisfying since it entails “discovery,” you must be comfortable with continually learning and furthermore you need to be a self-motivated learner.

So to summarize, if you are thinking of pursuing software development ask yourself:

- can you write?
- can you sell?
- are you logical and organized?
- are you patient? persistent?
- are you competent at research?
- can you teach others?
- do you love to learn?

No two artists have the exact set of matching talents; the same is true for software developers. Maybe you’re more of a jazzy musician, fast to learn and improvise. Or maybe you are a patient oil landscape painter with a keen sense of planning. Although a handful of personality traits favor the profession, few need all of these talents: software development has enough sub-disciplines that you will easily find a niche dependent on your matching strengths.


Wednesday, January 9, 2013

The Art of the Form


Let's face it: programs run on data. Your software will either receive a direct supply of this data from another machine or it will be interacting with human beings. Most business programs must ultimately, however, gather input from folks who enter vast quantities of customer-related data by typing on a keyboard into an on-screen form. Hence one key to successful software design is mastering how to develop effective data entry forms.

Since humans are highly evolved toward visual processing and semiotic signaling, designing a quality form is as challenging as a fashion model who tries to impress a critic: you must attend to placing every detail as the smallest lapses from perfection stand out starkly. We notice if your borders are too wide or your color choices are too pale.

Organize your forms into logical pieces so that they present related fields to the relevant subgroup of employees with the authority to update them. Required fields should have default values; group commonly-entered fields together near the high-touch areas of the form. Think of organizing your form like you would organize a restaurant menu: appetizers, desserts, drinks.

Users prefer consistent hand actions that keep the fingers fixed over the home keys. Too much clicking about with a mouse for reading and selecting of pulldown menus is an annoyance for high volume data entry.

Either the tab or the enter key should advance between fields in a consistent and logical manner. Indicate errors as close as possible to the source field (physically and temporally) with both a visual cue and a subtle audible signal.

Quality forms take a fair amount of effort to develop; failure to pay attention to all of the small details shows considerable discourtesy to your users. By paying attention to this handful of guidelines you may create forms that are intuitive, promote quality data, are easy to learn, are simple to use, and are haute couture.