Arieh's Weblog

Over my career, I have too often seen (lived through) cases where software development is seen as an activity whose primary (and often sole) purpose is to yield a running program.

Such an approach is more often than not the cause of endless difficulties and additions of schedule, cost, effort to the project, and decreased quality perception.
Experience has led me to view the software development process as a wholistic activity.

What do I mean by that ?

The activities of development, which begin from the gathering of requirements (that hopefully ;) satisfy customers' requirements), the conceptual design, the architectural design, and go through aspects such as the actual development process: establishment of code guidelines, test plans, technology selections, common build environments, software configuration and management (scm), integrability of test organizations (early and often) in the process, workflow tracking, have to be considered all along.

Moreso, we should not believe that releasing the product to GA (general availability) is where the process ends.

The infrastructure, processes, methodologies need to be in place so that the services organization, through its call centers, field engineers, and other will be able to handle problems submitted by customers.

Given that we expect our software to evolve, readiness for upgradability (as well as downgradability) needs to be built into the product through the infrastructure and methodologies that the project team has set up.

Training and documentation, a big part in making a product successful are often considered 'after the fact', having impact in the cost, time-to-market, perception of quality that the product will receive.

At one point, the sustaining activity for the product may be transferred to organizations other than the one who may have created the original version(s). In order to facilitiate that transition, the technology selections and the documentation of the process needs to be done in a thorough manner.

At the end of the road, project teams need to understand that support goes on until EOL/EOF.

The human aspect, which may appear here last but not least, is essential. Team dynamics, the selection/emergence of leads, mentors from which more junior team members can learn are fundamental.

It is my belief that by having such a wholistic view, we will be able to create compelling products that satisfy customer needs, be proud of their quality, and do so in an efficient and cost-effective manner.

I am hopeful that others who feel as passionate as I do about software development will follow this thread.