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.


Monday, August 26, 2013

Artful Versions


When you focus on modular resilience, one item that helps a great deal is to pay attention to versioning. Version numbers are of use not only for change management but for testing and customer support as well. Apps developed with Microsoft tools keep their version numbers in a config file. You should standardize on a common meaning for the four subparts of version numbers.

Upgrades that produce a system that is incompatible with a prior release should increment the "major" version number. Upgrades that retain compatibility but that add significant functionality, should upgrade the "minor" version number. Bug fixes that get packaged into a distribution should increment the "release" version number. Finally the developers should increment the fourth component, the "build" number, with every compilation.

I like to present versions to the customer as major dot minor, for example this is versions 2.4 of the software. This version should display in a welcome pop-up and in the title bar of the main screen of your application. But for purpose of technical support I like to display (in a pop-up "About" box) something like version 2.4.3 build 118. Of course all of the version components are retrievable using the system reflection class.

Another helpful trick is to include a parallel matching version number within the backing database. When the client begins to run your software, make sure the version number in the data is compatible with the number in your software.

You should also version all of the modules within your software in a similar fashion. Although the component module versions aren't typically presented to the end user, reflect them to a called module (for debugging purposes) so that the called class can display the version of the invoker whenever it throws an error.

Sometimes it may seem superfluous, but it only takes about 30 seconds to update a version number, and with multiple developers on a project you will find that having this tracking available is invaluable.


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.


Tuesday, June 25, 2013

The Art in Value


One of the challenges in a creative profession is managing the perception of your “value” including the work that you perform, the objects that you create, and the temperament that you nourish. These are truly three independent metrics.

Due to the demands of the profession and its continually advancing technologies developers tend to dwell more on what they already know (or what they need to learn) rather than focusing on how others perceive them. As software development is both an art and a vocation however, it is important to pay attention to both your internal qualifications as well as the perceived external value that you add to your job.

The value of your physical software development opus is fourfold: it may provide a revenue stream by itself, it may tender “goodwill” to customers and draw them in to purchase other products, it may offer cost savings as the business operates, and finally it may give a strategic advantage by opening new markets that create unique services.

The value of the product you help design is a separate matter however from the value of the actual work that you perform. Somewhat impishly, you can lead a project that creates the next YouTube and still only get paid like a system designer. Your employer compares your base salary to that of any other developer they could hire off the street. The cost of a foot of electrical wire inside a jet plane is the same even if you only use it to connect your power outlet to your reading lamp.

But now let’s consider your actual value as viewed by your employer. This is a more nebulous quantity that relates to a host of factors, many of which are strictly outside of your vocation. Are you a healthy employee? Then you add value by your contributions to the company’s medical plan. Are you cheerful and easy to work with? Then you add value by improving the morale of the workplace. Are you a good mentor? Then you add value indirectly through improving the productivity of others.

As a professional remember not only to stay sharp on your skills, but also to pay attention to the art in your value.


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.


Tuesday, April 23, 2013

The Art of Humor


A friend consulting with me on an Data Warehouse development effort (Lee Laniear) once told me an excellent metaphor that explains the three types of software development projects.

You are like an archer with a quiver full of arrows. In the first type of project, your user places the target in the distance, you grab and load your straightest arrow from your quiver, you draw back the bowstring, take aim, and you give it your best shot. The objective, of course, is to hit the bullseye. You may hit or you may miss, and certainly the aim is more difficult with increasing distance to the target or with increasing crosswinds. But the main point is that you can see where you want to go.

In the second kind of project, you are still the archer, but the user runs back and forth fifty yards away carrying the target. The objective, of course, is to hit the bullseye (not the client). He may stop, run one way, then suddenly stop and run another. He may stand still for brief periods of time, and then without warning start running around again. You grab your straightest arrow from your quiver, you draw back the bowstring, and you aim where you think the target is going to be by the time your arrow reaches it. Your success depends to a great extent on your historical observations of how the user changes his mind. And your self-control to aim safely for the target and not allow your emotions to divert your attention toward more animated ends.

In the third kind of project, you grab your straightest arrow from your quiver, you draw back the bowstring, and then leaning backward, you shoot your arrow straight up into the air. The object is to get the user, carrying the target on his head, to position himself directly underneath the falling arrow.

Successful project managers have an ability to separate themselves from their immediate feelings about the folks providing them with work. They need to be able to understand a larger picture of how others view their world, have a sunny disposition, and cultivate a fair amount of self-effacing graceful humor.


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.


Friday, March 22, 2013

Artfully Clean


Imagine buying a house and then never doing the laundry, vacuuming, taking out the trash, or washing the dishes. You just let stuff pile up until you run out of space and then you throw your up hands and go “oh, it must be time for a new house.” Sounds ludicrous eh?

In a highly competitive development environment though you build tables and files and directory folders, develop software, test a bit, and away you go. You patch up the bugs, optimize the queries, add a handful of indices, and you’re flying.

After a couple years though people are wondering why things take so long. Unsurprisingly the typical reason is a failure to archive and then remove the old data. Nobody is taking out the trash! Data retention and archival policies never get baked into the original specifications as the sponsors seldom see any immediate competitive value from them. Eventually however a clean system becomes less of a luxury and more a necessity. Folks start to notice the pile of dirty dishes.

The effort required to retrofit for cleanliness is about the same as the effort for planning for this up front. Strictly operationally however it is better to delay this expenditure until a system becomes a mess as you will then have a better understanding of the corners with the most fuzzballs.


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.


Sunday, February 24, 2013

Artful Vendor Relations


In any business, nobody does all the work themselves. We all rely on outside vendors from such mundane chores as providing the toilet paper up through providing phone lines, tax services, and legal assistance. And here in Information Technology we have our own set of vendors with wonderfully peculiar characteristics.

We group our unique compatriots into three worlds: the language vendors, the software package vendors, and the hardware vendors. We'll get to all three in due time, but today we will chat about the marvelous world of language vendors.

Selecting a language vendor is a lot like choosing a wife. You may not have as much actual contact with the vendor as you would like, but you will get to deal with what she cooks up, and her aesthetic tastes will affect you long after she is gone. Yeah and changing language vendors is as painful as going through a divorce, but that's a story for another post.

So what should you look for when selecting a language vendor? Probably the most important consideration is to perform an evaluation of their openness and how they admit to bugs and problems. Upgrades to language tools are major undertakings and a vendor doesn't take it lightly. So to meet ongoing challenges they should show resolve to provide workarounds.

Languages and development tools constantly change (and I've never seen a version of a language released with fewer verbs than the previous version). To some extent, the vendor is trying to remain competitive by adding the functionality that becomes available in competitors' products or other languages. A software vendor employs a large number of programmers, who need to keep releasing new versions in order to maintain their livelihoods.

So it turns out to be a bit of a balancing act managing your relationship with a language vendor: stability helps your programmers be productive, and yet staying current of tools allows you to incorporate new aesthetics and retain younger talent. If you happen to be in the position of selecting a vendor at the start of a large project you will partly need to use your intuition (and contacts in the industry) to get a better sense of the credibility of the press and of the vendors.

On the other hand, if one of the major vendors announces their plans for their next release of one of their market-leading programming tools, then you would be remiss to overlook its pending availability in your plans. So take your time and be very deliberate when choosing a language vendor, for you will be living with your choice for a long time.


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.


Tuesday, January 22, 2013

Artistic Sparsity


Even though we know it in our hearts, we still fail to account for how a software system grows and becomes more complex over time. Designing interface screens is a lot like planning an informal garden; if you want it to look great once all the plants take hold and fill out you need to think a bit about the future. Instead folks tend to wireframe a product that looks “complete” with reasonable use of the menu real-estate and a felicitous spread of field-density on the screen at the initial planting, as if the product is somehow “finished” once you implement it.

In doing this we make things look good in the /present/, yet we fail to account for system growth. When we later add significant new functionality… surprise, our screens and menus appear too overgrown and cluttered. It’s as if you planted all the apple trees two yards apart because it looked better; now that they have branched and fruited they are all atop on another.

Therefore when you are creating a new system plan for expansion by deliberately under-designing menus and occupancy: make the interface artistically sparse. And then don’t worry about it; like a garden your interface will “fill out” as it matures.



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.