The Software Development Process – Science, Engineering, Art, or Craft?

oops-small.jpg

There is general consensus that the software development process is imperfect, sometimes grossly so, for any number of human (management, skill, communication, clarity, etc) and technological (tooling, support, documentation, reliability, etc) reasons.  And yet, when it comes to talking about software development, we apply a variety of scientific/formal terms:

  1. Almost every college / university has a Computer Science curriculum.
  2. We use terms like “software engineer” on our resumes.
  3. We use the term “art” (as in “art of software development”) to acknowledge the creative/creation process (the first volume of Donald Knuth’s The Art of Computer Programming was published in 1968)
  4. There is even a “Manifesto for Software Craftsmanship” created in 2009 (the “Further Reading” link is a lot more interesting than the Manifesto itself.)

The literature on software development is full of phrases that talk about methodologies, giving the ignorant masses, newbie programmers, managers, and even senior developers the warm fuzzy illusion that there is some repeatable process to software development that warrants words like “science” and “engineer.”  Those who recognize the loosey-goosey quality of those methodologies probably feel more comfortable describing the software development process as an “art” or a “craft”, possibly bordering on “witchcraft.”

Read the whole article on the Code Project.

 

Advertisements

The Clifton Manifesto

manifesto.png

Individuals and interactions and processes and tools
Working software and comprehensive documentation
Customer collaboration and contract negotiation
Responding to change and following a plan

In direct contrast to the Agile Manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Why?  Because the Agile Manifesto creates tension between frequently opposing forces, leading to imbalance and extremes, which is one of the reasons Agile Development fails in actual implementation.  Conversely, I prefer to find the appropriate balance between the two, as appropriate for the client and the task at hand.