Sunday, December 5, 2010

Artistic Tools


How much of the nature of our software, its look and feel, the aesthetics, presentation, and capabilities, are determined by the nature of the tools that we use to create it? As developers, as artists creating works of interaction, data storage, and algorithms, isn't the result of our work as tied to our tools as a potter's works are tied to her clay and glazes? And hence we share pretty much the same neuroses with respect to our tools as any artist.

With a few clicks of a mouse and by dragging some widgets here or there, we can create full application frameworks. Then once inside the code we press "dot" and select from a list of actions. So we love our tools because they allow us to do in one hour what used to take us a full day.

At the same time however, if you want a highly animated presentation, then your tool might be Flash. And if your application requires extensive analysis, dicing and slicing of multidimensional data, then your tools may include SQL and Cognos. And once you've chosen your tool and made your investment to learn its bells and whistles, woe be the time you need to develop something that your tool doesn't support.

The tools that you use define you nearly as much as your accomplishments. True artists define a unique style by developing their own set of tools. A structure, a methodology, a bunch of accouterments seem to create themselves a priori out of thin air and then this drives the subsequent creating. When you are developing you should always strive to increase the variety of tools at your disposal, and leverage them by finding ways to blend them and make them work together.


Saturday, November 20, 2010

The Art in a Demur


It doesn't happen too frequently, but every once in a long while you will get partway into the design stage of a project and run into political interference under the dreaded guise of "company policy." It goes against company policy to purchase abc. It's against the policy to outsource this. Et cetera. And in your heart and in your experience you know that the manner you had planned is the correct method, regardless. For times like this keep this little story in your back pocket; it's a handy urban legend I use to employ just for the purpose.

-----


Back in the 80's a gentleman gained control of an airline in an effort to turn them around from bankruptcy. On one of his earliest flights on his new airline, he flew into Washington D.C. during the middle of winter to meet with federal regulators at the FAA. After his meeting, he boarded a passenger flight on his airline again to head back home. It had sleeted earlier and was now quite cold; the plane sat grounded on the runway. After half an hour, feeling frustrated, the new owner motioned to the stewardess and asked her what the problem was. She explained that, due to the inclement weather, the wings were covered with ice, so they couldn't take off. The gentleman identified himself as the new company president, and asked to leave the plane.

They reconnected a portable stairway exit ramp, and the owner grabbed his carry-on luggage and walked down the stairway and onto the tarmac. He approached the crew chief, identified himself as the new company president, and asked what the problem was. The crew chief explained the icing problem. "Well," the new president answered, "that's easy to fix." He opened up his carry-on bag and took out a portable cordless hair dryer. "Here", he motioned with the hairdryer on, back and forth over the wings. "Just use this." He handed the mechanic the hair dryer and reboarded the plane. After a half hour of de-icing, the plane was able to take off and the new president flew back home. The chief mechanic spread word of how he had been approached by the new president and given instructions.

Sometime later in the year, in the middle of the summer, the new president had occasion to once again visit Washington D.C. After his meeting, he boarded his airline on a passenger flight to head back home. He sat on the plane, waiting for it to leave the terminal, growing more and more impatient. When he glanced out the window, he saw a mechanic, standing on the top of a four-step rollable staircase, gliding a hair dryer back and forth over the wing. He motioned for the stewardess, identified himself, and asked to leave the plane. Once on the tarmac, he walked over to the mechanic, and being angry and in a rush, without even a hello, he tapped the mechanic on the shoulder and asked "what in the hell are you doing?". The mechanic turned to him and said "sorry for the delay sir, but it's company policy".

-----


The moral of the story of course is that just because an important person does something, it doesn't make it a policy. And an action that might make sense to perform some times is not universally correct. So listen to the wisdom in a company policy, but use your noggin and demur when appropriate. (ed. note: I checked with the owner mentioned in the story and he assured me it was entirely fiction).


Thursday, October 7, 2010

The Art in Change


In a later post I'll mention how a Business Analyst hooks up the creative talents with the business managers. Here we take a deeper look at the subtleties of this dynamic and reflect on the sociological influences that can determine its success.

Discovery (or requirements solicitation) is the stage where this dynamic plays out. Partly it's a shuffling of who knows what, as well as all of the political dynamics of control, job security, opinion, and hidden agendas. All of these make cameo appearances during the process.

Your role and title may indicate that you are simply writing a functional specification, but in actuality you are the director of a sublime process to keep the love and power flowing. To be able to effectively accomplish this you need both a mandate from a powerful source, as well as a higher set of guiding principles.

When you run into resistance from people who already have a vested interest in the status quo, sometimes you will have to appeal your principles to them, and sometimes you will need to invoke the big stick of your higher power. Nevertheless, always keep firmly in your mind the old saying that fools take to themselves the respect given to their office. Serve humbly and walk away leaving the place a better place than how it was when you started.


Saturday, September 18, 2010

Artistic Herding


At some point in your career you may be presented with the choice, opportunity or responsibility of joining the technical management team. Most folks who have an ambition toward this (and who are competent people with good technical skills) may find themselves hitting their early management strides by their middle 30s.

The appearance and draw of a management position looks radically different when you're on the climb up however, than when you are actually saddled with the responsibility. Sometimes you hear folks give the old warning "be careful of what you wish for." It's not however, actually as severe a misgiving as all that. It's more like crossing the razor's edge between two distinct and incompatible points of view.

While you're on the upward climb a management position appears as though it could be a good place to share your knowledge and discoveries about how to be a creative professional. Once you're actually there however you often find that your subordinates aren't particularly interested in your opinions, and secondly that you spend most of your time consumed by political positioning, "gaming", and preventing infighting.

What it all boils down to eventually though -- the real guts of the viewpoint canyon -- is a deep social and spiritual divide over the concept and purposes of "work." A simplified way to describe it is like the difference between being a successful feline and being the boarding caretaker for said herd of cats.

From the lone cat's (and lone programmer's) perspective, the objective is to keep your claws (your skills) sharp, to stay light on your feet, to be cautious and curious and aware of the changing environment. You are in a world where you need to hide the mice you discover so that other cats don't steal them. You stay coy and aloof and full of misdirection. Your concept of "work" involves a certain amount of territorialism.

From the perspective of the cat herder you just mostly want to ensure that people aren't spending all of their time picking cat fights. There is some sense of direction and movement you want to achieve, of course, but mostly you want to avoid having the cats bored to tears, sleeping on the job, or scheming for their next kill. You really just want to keep them out of trouble. Your concept of "work" is about the gestalt of your employer.

More about how a manager reconciles these viewpoints in later posts.


Thursday, August 12, 2010

Artful Digression


This blog is focused on the art and science of software development, but I don't want to imply that the contents herein represent a full picture of a programmers life. A great deal of outside experience ultimately influences your qualities as a software developer. This varies by person and personality, but for me the key outside activities for success are reading and walking.

The best source of inspirational reading in our rapidly changing world is a good library. Here you'll discover various trade and technical magazines, and the library may subscribe to online services that you wouldn't otherwise consider visiting. You should make an effort to research the state-of-the-art in the business use of computers as well as strategic advancements happening in your industry and related industries. I also recommend a broad general reading background of a variety of magazines: you never know when a strange juxtaposition of unrelated ideas will lead to a new breakthrough.

I can't overstate the value of walking. Not only does it clear your head of the clutter and confusions of political interests, the rhythm of your legs and the change of natural scenery will make you more aware of the proper balances in design. It will help you create a more naturalistic and organic path for your growth. Walk. Read.


Friday, July 9, 2010

The Art in the Vision


Once in a great while you end up in the right place and at the right time in the flowing river of people, companies, and technologies, where you are able to offer a Vision. You know something about a specific technology that your employer can leverage to a competitive advantage. This presents both amazing opportunities and complex personal challenges.

On the one hand, the impetus to share and promote your vision is intense. You know in your heart that it has great value, and if you don't take action on it then after a while it will lose its competitive advantage. At the same time though sharing it puts you in an awkward position with your peers. They may resent what they interpret as your self-important viewpoint, or they may simply be jealous of the attention you receive for your ideas.

Is there a way for you to proceed that doesn't get you laughed out of town? The key to this is actually twofold: first comes the "progressive reveal," and second comes the retained ever-expanding ballast.

To accomplish progressive-reveal you need to explain enough of your idea to the highest person in your company that would logically support you, at a level of detail to convince the listener that this is something you can achieve. You don't want to give away the whole tamale -- don't explain the "how", just the "what." Then assume the responsibility to make it happen. In return get a firm commitment from the person in charge; you will be progressively revealing more of the "how" as the project proceeds.

Once you actually unfold your idea into reality you will need to expand some "ballast." The ballast is the counterweight that keeps control of the idea's implementation from floating away from you, and prevents the debt the company owes you from sinking your soul. The method to accomplish this varies, but generally always remember that "control" provides the compensation for the actuarial value that you create.

Of course there is a managerial "flip side" to this process as well: how to create an environment that allows your most savvy employees to instantiate their visions, but that is a topic for a later post.


Saturday, June 5, 2010

The Art of the Job


Every couple of years my mom asks "What exactly do you do?"

Exactly? Well you see she only knows about computers from her laptop and the internet. So what does the job of being a software developer actually consist of? The easiest way to describe it (the work-work part of the job that is, aside from the social or sociological part of the job) is in terms of all of the steps involved in battling through a software project. This is the so-called SDLC, the software development lifecycle:

Research current and near-future relevant technology
Interview or focus sessions with clients
Develop implementation alternatives
Research vendors
Review alternatives with management
Develop a project plan
Develop functional specifications
Design data flow and data structures
Develop design specifications
Design draft of interface
Various programming tasks
Unit test programming
Software corrections from unit testing
System and stress testing Software
Corrections from system and stress testing
Alpha testing
Software corrections from alpha testing
Regression testing
Software corrections from regression testing
Technical documentation
Develop implementation plan
Develop training materials
Develop online help
Beta or parallel production testing
Training
Post implementation corrections
Production Support

Well yeah, it's a lot of stuff, and it's what makes the job always interesting and challenging.


Friday, May 7, 2010

Artistic Patching


Most of the time when you're developing software you get buried in writing code to flesh out a bunch of business requirements, you set up a test desktop environment, and then slave away and work through the bugs. Then you tie up a handful of loose ends, catch up a bit on your documentation, throw together some training notes, and then finally the big install. Ach, it doesn't work in production. Nothing can be more frustrating.

You go back and check your setup notes, make sure all your key tables have the right data, make sure all the network paths are mapped and exist, triple check your configuration file settings, and still no-go. What the heck could it possibly be? All the DLLs look correct, all the web services are up, and as far as you know all your cohorts installed their respective pieces.

When you have reached the end of your rope it's time to think outside the box. And the part that you are overlooking is simply this: you need to apply all the service packs and Windows Updates on the production boxes. Yeah the SQL service packs as well.

At times it seems like a royal pain to hassle with software infrastructure that works as the foundation that you seldom actually think about. But the whole reason that you have development tools that have the power that they do is because they build upon this humongous hidden foundation. Do you want to avoid installation problems? Practice the art of keeping your core software fully patched.


Friday, April 2, 2010

Artistic Multitasking


Multithreading is a wonderful tool but you need to use it very carefully. First don't use it recklessly, as there are specific instances where it is of most benefit (see this post for examples). I have four tips to help you along your way.

1. Once you read about the threading class you'll recognize they are several steps to get it going. First there's some setup, then some properties you can initialize, and then you thread.Start. Away you go. Tip 1 is to be sure to assign the Name property an each thread you start. This is really the only way to tell which thread caused exceptions and is the only clue when you're debugging of how you got here. Use a name relevant to the instigator method and the serial count of that particular thread.

2. Think in terms of threads working on an instance of an object. This helps keep multiple threads from stepping on each others memory space. Put all the values for input into properties of your new object, create a method in that object that performs the "heavy lifting" and deep calculations, and then execute that method through the thread.Start (placing return values back into a property). As an added tip I like to build an array-list of all the objects I have actively submitted to threads; when the thread terminates I can pop its values out of the array and then null out its instance.

3. If you anticipate that you may ever need the capability to abort the thread you are starting (for example if the user cancels the operation) it is far far better to make provisions for this within the thread, in the method you are executing, rather than using thread.Abort. I usually create a boolean property in my main class called panicStop. All threads check this value within each iteration of a for-loop, and bail out appropriately.

4. Manage the quantity of threads you allow to run simultaneously. Beyond a certain threshold (depending on the number of CPUs on your box and other factors) firing more threads doesn't aid performance much. So manage it.

Multithreading works great as long as you remember to use it for appropriate tasks, and pass each thread a new object to work on. Remember that you are flowing parallel, but in separate "streams" -- or to quote one of my favorite older comedy movies, "whatever you do, don't cross the streams."


Saturday, March 20, 2010

More Art in Change


Business rules change and you will need a way to accommodate that. To maintain system resilience and modular compatibility you must however avoid certain habits; here's how. The four secret words are inheritance, overload, deprecation, and propertizing.

These are pretty standard concepts in the object oriented world, but using them correctly takes a bit of discipline. Part of the issue is that post-hoc seat of the pants changes are a poor excuse for thoughtful refactoring in the first place.

For example say you have a routine that estimates a car's mileage based upon a single measurement plus a date of measurement. This gets implemented as myCar.getCurrentMiles. Now your company wants to change the method to use two measurements and two measurement dates instead. How do you proceed?

Look at all the options and consider what they buy you, but also consider what they break.

The first and easiest option is the overload. You already have myCar.getCurrentMiles (measurement, date), now in the same class you add myCar.getCurrentMiles(measure1, date1, measure2, date2). Of course this new method starts out with the code that used to be in the old method (have the old method call the new method with null values for the second measure and date).

External calls using the old method will still work, and developers coding for this method will see both signatures in their intellisence pop up. This does have the drawback however of failing to provide much to the consumer in the way of choosing the newer signature of the method over the older. When to call it with one measurement, and when with two? More about the other alternatives for handling change in a later post.


Thursday, February 11, 2010

Artful Minimalism


Nowadays you can buy development tools that incorporate tons of form-behind widgets and code generation that can produce web pages with pop-out scroll overs, call-outs, and just about every kind of special effect imaginable. Is all of this necessary?

Unless you are building a data entry form (which has its own special challenges) you are probably better off just to make sure your web pages meet a certain set of minimum requirements. After you have thrown together your page, run it through a few simple tests:

1) Window Resizing
Open your page in a browser and resize the window to various heights and widths to see what happens. Did your layouts get mashed? Do you need to change column widths from fixed to a percentage?

2) W3C compatibility
Submit your page to the free W3C verifier, just as a courtesy check to assure that your tags are all balanced and that your links are all valid.

3) Powersave Mode
Fire up a browser on a smaller screen device and in the browser options turn off the setting that allows the web pages to "set their own colors." Also go into the properties tab on your desktop and change the color scheme to a power saving configurations, with a black background and white text. Now open up your web page to see what happened. Do you need to remove some "color" tags to keep it legible?

4) Just The Facts
Go back into the browser settings and turn off automatic image loading. Refresh your web page. Does it still make sense with just the facts? Did you provide the necessary alt tags so that the user can still figure out where to click for navigation?

Sure, spinning flashing widgets are fun to view on your site. For all of about ten seconds. What stays as important though is the actual informative content that you provide. Try to make it work under all conditions.


Monday, January 18, 2010

Artful Influence


The art of software development can be much more than accomplishing projects. Often the successful path begins by focusing beyond the project at hand -- you need to review everything you can think of: personalities, creative ideas, political issues, hidden agendas, insecurities, technical questions, doubts about the future direction of technology, everything.

You may find a need to be intensely aware of a company's culture. At other times it may appear that your real purpose is to change the culture, and your development project is just a means to achieve that end. You may also need to include a bit of an appraisal as to the strategic direction and positioning of your company: it might be wrong for you to try to turn your employer into the Nordstrom's of retailers if its intentions and strategy is to be the K-mart.

In some consulting environments your purpose is not to accomplish anything. Your project is actually an anti-project, the staff is against you, and you succeed by making the staff accomplish their own agenda. You must use grace to provide a backflow, purposefully pointing away from their objectives. Occasionally you can be successful overall (and act in the best interest of your retainer) even though your own personal accomplishments and monthly status reports might lack a certain luster.

Around one quarter of software design could be considered "art" in every sense of the word. Congruent to other creative arts a software designer encapsulates thought into both visual and written structures. Sometimes though the whole point of creating software is to go through the process of meeting with people and moving them from their preconceived positions to change the culture, nature, and very heart of your employer. So once in a while the parallels to art go deep down to its truer purpose: to move people's souls.