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