In the demanding, 'net-speed, pressurized world of software development, software professionals would do well to reflect on some truths about their customers, their industry, and themselves. Following a few tips will help you achieve what is ultimately the most important issue - satisfying the customer.
Developing What the Customer Wants
OK, so we all know staying ahead of rivals is a constant challenge in today's highly competitive software industry. And then there's the daily battle of proving to existing customers and prospects alike that we software purveyors can supply what is needed. We'd like to think that we provide customers with software they will love to use. But if we hold a mirror up to our work and look closely, do we provide any service beyond the lines of code? There's more to providing a good product than just generating basic functional code. If we aren't producing the intrinsic value-adds that should be supplied in our products, we might soon be spending our days job hunting, wondering where we went wrong. Here are some guidelines we can follow to help prevent that from happening.
Embrace Creative Depth
Since customers aren't software designers, they aren't always aware of the possibilities of our magical world; therefore, they don't always know what they can ask for. Creativity is left to software professionals. Consequently, providing the customer with a product that we would be excited - yes, excited - to use ourselves becomes our responsibility. Our results should always exceed the customer's expectations, and not burden them with frivolous bells and whistles they may never use.
We must reject the "minimalist" approach of simply giving the customer "what they ask for." We have a duty to build "robustness" into every line of code delivered. After all, what's the point of writing software that only serves the basic needs of our customers, then later requires improvement? And where is it written that we cannot expand the horizons (and the capability) of our software right out of the gate, to make it as attractive as possible to as many customers as possible?
Know the Customer. Let the Customer Know You.
How is this miracle accomplished? Actually, it may be simpler than we think - start by talking to the customers. Study and ask questions about their jobs. Learn the ins and outs of daily tasks. Discover key functions that are necessary for completing those tasks. The more we know about the customers' needs, the better we are able to provide good solutions. Sure, understanding our customers' worlds is difficult, time-consuming, and requires more preparation than simply creating our software in a vacuum, but we must understand their pain. We're talking about our customers here - they keep us in business.
People inherently mistrust or fear things not understood. Not every software user has our knowledge and confidence in the functionality and dependability of a program. A "timid" user accepts the notion that software will do what it is supposed to do, and believes he could never understand how it all happens. But even the timid user knows how to simplify his job. Therefore, we are obliged to make the software's usability as intuitive as we can to help him accomplish his tasks with as little doubt or angst as possible. This means judiciously placing "feel good" tidbits into the product: reminders, success messages, on-screen instructions, help text that's truly helpful (plain English, please), etc. Let users know what should be done, what was improperly done, that all is well, and finally, that they did things correctly.
The flip side of the coin is getting our customers to learn more about us. Software professionals traditionally fail at building legions of raving fans, in part because we rarely dispel the air of mystery surrounding our profession. We clandestinely revel in this self-serving secrecy about what we do and how we do it. But this secrecy causes a rift between programmer and end user that hinders the communication that is critical for success. We must enlighten customers about our IT capabilities. When designing software, we need to discuss possible functionality with the customer, not just with our peers. Just as we strive to understand the issues our customers face each day, we should also let go of our egos and seek to educate them about the magic we can perform - and about the issues this magic poses for us. In short, we should offer them the same level of professional respect we routinely demand in return.
Provide Consistency
Consistency is a cornerstone of building a solid product and a host of faithful users. When users see consistency in a product, they feel comfortable believing the creative process was well conducted - like an orchestral performance in which all members use the same sheet music - with everyone working together to achieve the same goal. Conversely, inconsistency sows the seeds of doubt regarding quality and usability. When the look, feel, and function of a product are "all over the map," customers are naturally uncomfortable using it. Consistency can only be achieved if everyone involved adheres to proven standards. Mavericks, however glorified by popular culture, can ruin the consistency necessary for customers to vote a product solid and robust.
Take the Long Approach
Despite the fact that members of the IT community often leap from job to job in search of the next big challenge or paycheck, the software created remains and should be designed to last. Yet change is inevitable, even in the code we once thought was perfect. The applications we create must have solid foundations, which means we must have a commitment to good planning on the front end. They must be robust in function, which means durable, well-thought-out code that works every time. And they must withstand the tests of time and change, which means, in part, maintaining "living" documentation on the back end that is in step with the changes we make.
Offer Structure in an Unstructured World
With all the whizbangs, geegaws, and shortcuts available to modern-day software professionals, some programmers fashionably ridicule "the old ways" of creating and delivering code. "It was too structured," some say. "It took too much time," others say. But today's software professionals would do well to keep in mind that these laborious, rigidly structured methods provided the framework in which the software industry developed to the point where we can now be casual, unstructured, and even sloppy in our practices. Today's development tools have made some of us lazy. They perform functions that once required arduously repetitive coding (think: "sorting a file" - and if this doesn't compute for you, ask an old-time programmer about it). The old ways were successful because strict adherence to structure and "following the rules" were required as a part of the job. Just because today's employers don't make us wear neckties does not relieve us of the responsibility to be rigid in our approach to the design and creation of our future masterpieces. We don't have to program the old-fashioned way, but we need to hang on to some of the old-fashioned ideals.
Maintain a Zero-Defect Attitude
One of the scariest goblins lurking in the IT shadows is the casual and almost routine acceptance of bugs and inadequacies, regardless of severity, in the software tools we use to build our products. The danger is not so much the bugs themselves; rather, it is the mindset of complacency bred into coders who benignly believe that software bugs are simply an accepted way of life in IT. These coders may never develop the professional ethic necessary to give customers a product that is NOT riddled with problems or hard to use. They'll simply think that it's OK to create and sell software that has bugs, as long as there is some kind of workaround, hokey or not. Sure, there will always be some bugs - it's unavoidable. However, even moderate-level bugs are often unacceptable to customers. In fact, my own IT experience tells me that the "moderate" bugs exasperate customers the most. And remember, it is the customers who keep us in business.
Lest you think I have forgotten that all of these methods require time, which we never have enough of, rest assured that I have not. Neither have I forgotten about pride in performance, responsibility, and what my grandmother used to call "elbow grease." If the situation calls for it, we need to work both smarter and harder.
After all of the dot-com busts of the '90s, software professionals may no longer have the "wiggle room" we once had, especially when it comes to customer acceptance of our assumed deity status. We need to take a good look at not only what we do, but how we do it. And no matter how good we are, or think we are, we need to be better for our own sake as well as for the sake of our customers. Remember: the customers keep us in business.
Poor-quality software should be anathema to those who develop it, as much as it is to those who ultimately get stuck using it. As we build our products, we need to constantly be walking in our customers' shoes. And keep remembering who keeps us in business.
