« Hurricane Katrina - Our Tsunami? | Main | "May I be frank" and the power of candor »
September 05, 2005
Mediocrity, the root of many evils (not just in software development)
"When small men attempt great enterprises, they always end by reducing them to the level of their mediocrity." - Napoleon Bonaparte
One of the root causes of many problems I, as much as many other entrepreneurs, face throughout the life of a company is mediocrity. Over the years I have developed an insatiable desire for perfection and excellence in the products and/or services I want put my name behind. To be honest, it isn't particularly hard to set these types of high standards. Making your organization live by them, however, is a different story; it’s extremely difficult! I still struggle with the execution of some of these standards at times as it is a constant uphill battle.
If you truly start to enforce your high quality standards you will most likely loose some people along the way, which is why you should always start by getting "buy in" from everybody. You will experience that the "buy in" part is actually pretty easy most of the time, because in theory people usually have no problem agreeing on high quality standards and bettering a product or service. Now, as you might have guessed, it’s an entirely different picture following through with that in today's day-to-day operations.
Most companies I have founded or co-founded in the U.S. were based on software development one way or another. Well, in the world of software development the desire of releasing product oftentimes overrides some quality standards. This is not to say that you need to treat every release like you are Microsoft® releasing a new Windows® OS, but you should follow a development process that allows ample opportunity to plan the product and the effects it will have on your customers, including all times lines, milestones, release dates, execution of the development, and a sufficient testing plan to ensure your quality standards will be met. A good example for a testing architecture is here. Then execute your plan, and adjust timelines to reflect the most realistic release date possible. Keep your customers informed about your progress and reassure them, your team, and yourself that you are releasing nothing less than a high quality product.
However, quality is obviously a very subjective term. It will depend on who the 'customer' is and their overall influence in the scheme of things. A wide-angle view of the customers of a software development project might include end-users, customer acceptance testers, customer contract officers, customer management, the development organization's management, accountants, testers, salespeople, future software maintenance engineers, stockholders, magazine columnists, etc. Each type of customer will have their own slant on quality - the accounting department might define quality in terms of profits while an end-user might define quality as user-friendly and bug-free. This is why product and service quality assurance is so important. The purpose of software quality assurance is to define the techniques, procedures, and methodologies that will be used at your company to assure timely delivery of the software that meets specified requirements within project resources.
I define quality (non-mediocre) services and products as reasonably bug-free, professionally and friendly, delivered on time, and within budget. It meets (not exceeds) organizational and customer requirements and/or expectations, and is properly maintainable.
So, how do you know if you're organization is (or is perceived as) mediocre or not? Well, if you are asking this question you need to put your ear to the ground and listen to what others say about you and/or your products/services. The following is a list of adjectives you want to avoid when you or others talk about your products, services, or organization as they are a clear sign of mediocrity or worse: insignificant, mainstream, mean, evil, bad, middling, sucking, ordinary, passable, run-of-the-mill, second-rate, so-so, tolerable, undistinguished, unexceptional, uninspired, inadequate, insufficient, lacking, unacceptable, and unsatisfactory.
Contrary to the list above here is a list of adjectives you do want to hear when you or others talk about your products, services, or organization: distinguished, excellent, exceptional, exquisite, rocking, first-class, first-rate, matchless, optimal, optimum, outstanding, peerless, preeminent, special, superior, supreme, top-notch; unmatched, unparalleled, and unsurpassed.
At times I have used online services to monitor Internet postings about my companies and to feel the public's "pulse" about companies and projects I'm involved in. Listen to customer feedback (especially the ones you hate to get). It pays off to do whatever you can to avoid being stamped a mediocre company. Strive for excellence and don’t compromise too much. Apple fellow and “almost” Yahoo CEO Guy Kawasaki once said “Great companies start because the founders want to change the world ...” So, if you are thinking about it, stop reading now, set yourself some high goals, and go out there and do it!
Posted by Ben at September 5, 2005 11:42 AM
Trackback Pings
TrackBack URL for this entry:
http://www.benneumann.com/mt/mt-tb.cgi/11
Comments
This is not to say that you need to treat every release like you are Microsoft® releasing a new Windows® OS
I hope not too.. Microsoft always releases a batch of patches (or a whole Service Pack) pretty quick after a new OS release ;-)
The testing structure you've linked to is reasonable for the user level, but too high-level in my opinion. Testing should start from the single lines of code upwards.
No method or action should go untested in an app. Indeed, some methodologies exist where you write the tests before you fill in the code to satisfy them. This way, as soon as someone touches some code, adds a new feature, etc, you can automatically run a whole battery of tests and find out if the entire system works from top to toe. Most user complaints are not founded upon sloppy implementation or poor focus, but actual failures and severe bugs in systems.
Testing is something coders should be doing from the first hour, not a process which follows a development.
Posted by: Peter Cooper at September 16, 2005 11:41 AM
This is really great stuff! Thanks Ben. Keep writing!
Best,
Greg
Posted by: Greg at September 19, 2005 08:14 AM