http://www

D:\~~aapaula\Gen_knowl\eCommerce\r_change.doc Created on 07/21/99 9:36 AM

http://www.datamation.com/PlugIn/workbench/appdev/stories/9907hayes1.html

"To Win at Software Development… you have to change the game"

In order to succeed in developing software, you've got to discard old-fashioned methods and mindsets and come up with new ways to create good software. Without exception, software developers and testers at every company I've ever worked in or with have harbored the belief that they--and they alone--are victims of uncaring management, undefined requirements, unreasonable customers, and absurd schedules, while other companies are developing and testing their software the "right" way.

Well I have news for you…. Everyone, everywhere is in the same situation. The next company I see that has an orderly, timely, formal, and effective approach for developing software will be… the first. Don't get me wrong, lots of companies are making valiant attempts to define their development processes and stick to them, but somehow, somewhere, it all goes by the wayside.

The fundamental question is, why?

Although we all laugh about how the mainframes of yore can fit on a chip today, the fact is, software development in the past was a far more disciplined process. Flowcharts, diagrams, and coding pads existed for a reason: At one point in time, people actually used them. Application development was approached as a scientific discipline and was commenced only after extensive analysis, planning, and design. Testing was equally systematic, with methodical techniques for deriving test conditions and cases. Computer programmers were revered as geniuses.

So what was different then?

It all comes down to time. In the early days, computers were new, and they were replacing tasks already being done manually. Accounting, for example, was commonly automated first. Because it was all so new and because there were manual alternatives in place, software could be developed over a two-to-three-year period and no one thought anything of it. Development took as long as was required to get it right.

Today, 90 days is the norm for development cycles. Computers have infiltrated every aspect of our lives and company operations, forever changing the way we conduct communications and commerce. Software is a competitive weapon, used both offensively and defensively: If your competitor announces a new billing plan or fare-pricing program, you've got to respond quickly or risk losing business.

Ironically, this collapse in the timeline for development is exacerbated by an expansion of complexity in technology, a byproduct of advancement. The number of variables involved in hardware, software, and the applications they support now, compared to then, is orders of magnitude greater. So we've got more to do and less time to do it in. And there you have it. It's not that everyone forgot how to do it right, or developed bad attitudes or sloppy practices, it's just that economic realities have forever changed. You can't win this game playing by the old rules.

What can you do about it?

Start by changing your beliefs. Quit castigating yourself, your company, your coworkers, and your customers for failing to adhere to principles that have all the immediacy and relevance of dinosaur mating rituals. Accept the fact that it's a new world and software is organic instead of static; that it's part of a continuous flow of economies and realities reflecting the state of commerce and not the state of the art.

Next, change your approach. Instead of clinging to the old systems-development life cycle because it makes sense--or used to--reorient your thinking to today's conditions. It's like changing from a marathon runner to a sprinter--it takes a completely different strategy and approach to succeed.

Here are a few tips…

Become a team player. There is no substitute for a cross-functional team that includes marketing, development, testing, training, documentation, and support personnel. Act and think like a sports team: Everyone plays their position but covers for everyone else when necessary, and everyone wins or everyone loses.

Ask your customers to join the team. Instead of being treated as outsiders and critics of the product, customers should be insiders, participants to the whole process. If you sell your product to other organizations, recruit "alpha" sites to join in. This sense of ownership will help you--and your customers--make critical decisions about priorities, risks, and schedules. You'd be surprised how practical customers' demands become when they see what is actually involved.

Release early and often. Traditional wisdom says it's better to wait until all of the functionality is ready before releasing the product. These days, it's better to add functionality incrementally, in the smallest possible pieces that will still work and make sense. This gives you faster feedback and allows you to incorporate design changes before the product is too far along.

Pace yourself. Once you realize that every schedule will be a crunch, you'll stop believing you can kill yourself today and recover later. Later will never come. Instead, work hard and be just as aggressive about maintaining balance in your life. It will greatly improve your productivity and your attitude.

Measure what you do, not what you don't do. It's a crime to measure a product by its defects--it completely ignores what it does well. Software is never perfect, and it never will be. Instead, focus on what you achieved in terms of new functionality, problems corrected, and performance enhanced. This doesn't mean you should turn a blind eye to defects, just realize that they are only one small measure.

Simply put, the rules have changed. So, change your game and the way you play it…