Friday, January 21, 2005

When Not to use the SDLC

Reasons and Examples why developers or support analysts would NOT want to use a FORMAL Software Development Life Cycle?

There are a number of reasons why a formal SDLC is not a good fit.

The following are contributing factors that directly affect the formation of the SDLC process, its structure and organization.

  • Logistics
  • Costs
  • Available Skill sets of people
  • Number of people in the project
  • Budget, Funding, Retainer or PO
  • Available tools (software, hardware, communications and connectivity)
  • Collaboration tools (software, hardware, remote access)
  • The utilization of the most current RAD tools
  • Leadership Skills
  • Team Developer Skills
  • End User process knowledge and skills
  • Time-Frame
  • Project "In-Demand" need
  • The personal motivations of all the people involved in the project
  • This is NOT and all inclusive list. There are many more factors too.

With each factor being a variable the SDLC structure as presented in the text does not allow for flexibility. A development process success is dependant upon many factors to include all parties being flexible to change as things change. The only constant in IT is change.

Areas of application development were SDLC is not a good fit are:

  • Proof of Concept Testing
  • Running a series of never before performed processes, functions or methods.
  • Running a series of combination tests to see what happens.
  • Running a series of tests to intentionally try to break the application process to examine for security and potential points of failure.
  • Running a series of unorthodox user tests to observe the reaction and behavior of untrained or unskilled users to trap for the unexpected use of the applications.
  • Experimentation
  • Developing algorithms to perform tasks that do not yet exist.
  • Refining existing methods and procedures for better performance and smaller footprint.
    Individual Projects
  • An individual user doing small utility development.
  • There are many more, but these are a few.

One might argue that these are individual components of the SDLC. Situation dictates the scale and perception of where and when the SDLC process begins and ends. The SDLC can be a used by single user or by a massive army of developers. In the development community the term SDLC is not used. Common terms that mean the same thing are process development, application development, team development and systems development. The life cycle part is a MBA buzz word.

SDLC can provide structure where chaos is, however if the SDLC is in acted as company Law it can actually impede, hinder and prevent creative application development.

Examples of where the SDLC was NOT used that resulted in creative and industry changing applications.

  • Compaq's original IBM compatible XT PC
  • The original Compaq system BIOS
  • The original Apple computer
  • Tim Berners-Lee development of HTML and the first Mozilla Browser
  • Shawn Fanning's development of Napster
  • The development of the original UNIX and DOS OS's
  • The original spreadsheet application
  • The original email application
  • I could go on and on....

So the moral here is for the carpenter to apply the right size hammer to the right size nail.


No comments: