Design options ...

Design Options

Changes effect all users.

Developer:
Theme:
Components:

Software Development Meta Issues

First Published (Original Date):
2006-12-28%
Datetime Format:
EDTF with spaces.

What are Software Development Meta Issues?

There are lots of terms floating about that are used to describe thinking about the best way to develop software. We have: "Structured Approach"; "Software Engineering"; "Software Development Methodology"; "Software Development Method"; "Software Development Process"; or "Process Models". There is no consistency.

When thinking about the nature of these candidate concepts in software development we can speak of being involved in "meta issues". In this article we will mainly explore the meta issue of differentiating and defining "Methodology", "System", and "Method" as far as they apply to software development. We also look at a Software Development "Taxonomy" and "Approach".

Of the many candidate terms floating about which should we use? The first consideration: it is not just about process. For example, thinking about the best way to develop software includes thinking about team design. This is a matter of "people" not mere "process". So a mere "process model" is not sufficient to capture all the relevant thinking.

Secondly, "Methodology" can come dangerously close to being wanky synonym for "Method". However we need both of these terms for an important distinction. The American Heritage Dictionary usefully points this out:

Usage Note: Methodology can properly refer to the theoretical analysis of the methods appropriate to a field of study or to the body of methods and principles particular to a branch of knowledge. In this sense, one may speak of objections to the methodology of a geographic survey (that is, objections dealing with the appropriateness of the methods used) or of the methodology of modern cognitive psychology (that is, the principles and practices that underlie research in the field). In recent years, however, methodology has been increasingly used as a pretentious substitute for method in scientific and technical contexts, as in The oil company has not yet decided on a methodology for restoring the beaches. People may have taken to this practice by influence of the adjective methodological to mean "pertaining to methods." Methodological may have acquired this meaning because people had already been using the more ordinary adjective methodical to mean "orderly, systematic." But the misuse of methodology obscures an important conceptual distinction between the tools of scientific investigation (properly methods) and the principles that determine how such tools are deployed and interpreted.

Methodology Entry. The American Heritage Dictionary of the English Language, Fourth Edition, Houghton Mifflin Company, 2004. As quoted in Dictionary.com (accessed: August 30, 2006).

In software development, and in general, it is useful not only to distinguish "method" from "methodology" but "system" too.

As free beings we can come up with a number of possible definitions. What follows is one possible set of definitions. It's merely the best one I could come up with at the time that also has the advantage of not straying from common usage.

Definitions for any project

When thinking about the best way to execute any project, in general, we can employ "Method", "System", and "Methodology" with the following meanings:

Method
A way of doing things in accordance with a plan.

Consider the project of swimming. There are a number of possible methods we could use to swim:

System
A coordinated combination of methods.

Often it is only particular combinations of methods that work well together. A system, a coordinated body of methods, often emerges:

Methodology
The science of methods.

We are interested not just in enumerating methods but evaluating them. We wish to determine which are the best methods and systems. Swimming Methodology would entail such things as:

Definitions for Software Development Projects

Method

We can make these definitions specific to software development.

Software Development Method
A way of doing things in accordance with a plan in order to develop software.

Different aspects of a software project have many well known possible software development methods. For Example:

A Team Method (or "Team Design")
E.g. Surgeon/Nurse Model; Classic Business Model (With a Team Leader); SWAT (members utilizing specialist and complimentary skills); Skunkworks (Environment closed of from normal bureaucratic structure); Pair Programming.
Software Lifecycle Method
E.g. Evolutionary Prototyping; Throwaway Prototyping; Spiral; Pure (or "Classic") Waterfall; Staged Release.
Methods for Soliciting Requirements
E.g. Joint Application Development; Serial Interviews; Prototyping.
Specification Document Types
E.g. Formal "Mathematical" Methods including State Diagrams; Wireframes for the Web; Prototype Screen printouts; Data Modeling with Entity/Relationship diagrams.
Coding Conventions
E.g. A Code Naming Convention like Reddick VBA; A Coding Style Convention; the XHTML 1.1 W3C recommendation.
Programming Craft
E.g. Object Oriented Programming; Datatype Choice; Defensive programming principles.
Quality Assurance Methods
E.g. Technical Inspections; Code Reading; Walkthroughs; Execution Testing; writing tests before writing the code.

"Coding Conventions", "Programming Craft", and "Team Design" above I'm deeming "methods".

A single software project will require several methods. A single software project will entail choices between, or a combination of, methods.

Methods may operate for: part of a phase (e.g. using a Code Naming Convention, like Reddick for VBA, for the Coding Phase), across several phases (e.g. Using Prototyping during the Requirements Analysis, design and specification phases), as well as throughout (most of) the project (e.g. Team design, and lifecycle method).

System

Software Development System
A coordinated combination of software development methods.

This entails:

  1. Software development methods to use always, on any project.
  2. Software development methods use by default, on any project.
  3. A range of possible competing methods with a means to decide between them depending on the unique characteristics of a project.

Software Development System Examples:

A software development system is not usefully equated with a lifecycle method. Alas, it often is. In part this is because software development systems often: feature their preferred lifecycle method (Martin's Rapid Application Development favours a throwaway prototyping driven lifecycle); have only one lifecycle method (extreme programming calls for an iterative lifecycle); or constituted nothing but a lifecycle method (as in the classic waterfall method).

A software development system is not just a lifecycle method. It is a combination of methods. For example a software development system will require: a team organization method, code convention (= method), a quality assurance method, and much more.

A software development system need not limit itself to one choice of method. For example a software development system might advocate many quality assurance methods to be deployed at the same time: execution testing; code reading; and write-tests-before-writing-code.

However, a software development system generally alleges that some methods work better than others. For example, the Extreme Programming System's team method emphasizes pair programming, its lifecycle method is iterative (entailing "Incremental Design" and "Daily Deployment").

Using a system to choose between methods need not sound (or be) so arduous, as if some lengthy scientific investigation needs to be launched at every step of the project. Often enough the best method will become obvious as the project proceeds. For example, imagine we are developing a Customer Relationship Management Application. Perhaps our client requires contact details as a matter of urgency and financial details can wait. Then the right lifecycle method may be apparent. Staged Release may be right here: the contact module released first, then the financial details module.

Methodology

Software Development Methodology
Using reason and evidence to determine how best to deliver a software solution.

Doing Methodology will bear the following fruit:

  1. A Software Development Taxonomy.
  2. An evaluation of possible methods and therefore a Software Development System.

There are a number of things to get clear on what a software development methodology is and is not.

Methodology is not System

As defined above a software development methodology is not a software development system. For example, Extreme Programming is not a software development methodology. Extreme programming is a combination of methods. To arrive at this combination of methods methodology was done.

Methodology is not tied to a particular technology

Methodology is not technology particular. It is a general body of thought that can be applied to any software project regardless of the technology. This needs qualification. Choice of technology may effect method choice. For example, developing web apps will entail specification document types that are different from windows apps. However, methodology is thinking at a layer "above" any particular technology.

Another motive for separating methodology from a particular technology is to acknowledge that large body of information and code that is technology particular. That information and code is grouped with methodology under "Software Development Approach" below.

Who does Methodology?

Those who do software development methodology include:

  1. Authors of a book on a software development system (like extreme programming).
  2. Readers of a book on a software development system. You'll be evaluating whether the author is convincing.
  3. Computer Science academics doing a study on a software development method or system.
  4. Software developers on every project. They ought do this at the start, during a development system synchronization phase, and after the project is complete, to examine how the development system might be improved.

The authors of Extreme Programming, like the authors of any system, do methodology in order to write their book. They think about competing methods, look at evidence, and come to conclusions on which are the best ones. They do methodology in their book when they justify one method (e.g. pair programming) over another method (e.g. traditional business team). Their software development methodological activity bears the fruit of a software development system, a grab bag of privileged methods.

It is worth emphasizing group 4:

All software developers on a software project ought do methodology.

The first reason why methodology ought be done on every software project is that the developers in a team will have differing preferred Software Development Systems. Okcana will prefer Extreme Programming, Bill may prefer Rapid Application Development, Lisa might like Crystal Clear. There will come a point where the developer's must choose one method over another. Methodology is making a choice between competing systems, and ultimately competing methods based on reason and evidence.

Secondly, after every project there is opportunity for improving the software development system, either as an individual software developer or as a software development house.

There is only one Methodology

Suppose we where to define methodology more broadly to be "Determining how best to deliver a software solution". That would be to drop the requirement for using reason and evidence. In that case there would be many different methodologies, many different ways to choose between candidate methods and systems:

However, as defined there is only one methodology: using reason and evidence to choose between methods. Of course, two different developers using this one methodology may come to different conclusions about which is the better method. Jack may reckon pair programming is the better team model for this project (or for projects in general) while Jill might reckon the traditional business team is better. Reasonable people can disagree. Further, to some extent, in many cases mere personal preference might be the only basis available for choosing one method over another.

Additionally, personal skill may be relevant in choosing one method over another. When developer is stronger in prototyping, rather than Joint Application Development, then this becomes a reason in favour of prototyping. (Joint Application Development and prototyping are requirements solicitation methods. Joint Application Development essentially entails a series of contiguous day long meetings between developer, client, and users).

Software Development Taxonomy

Software Development Taxonomy
A categorization of software development thought and methods.

A Software Development Methodology is more than deriving a means to decide between methods, and in turn a system. It is also yields a Software Development Taxonomy. It is a taxonomy of methods.

This taxonomy of methods serves two purposes.

Firstly, as an overview of all the methods that a particular system will prescribe.

Secondly, as an overview of possible methods that any systems must have. This allows comparison between systems. In other words the Software Development Taxonomy facilitates doing Software Development Methodology. The Software Development Taxonomy facilitates a debate between developers on which methods, and therefore systems, to use.

A Software Development Taxonomy is defined, by us, to be different from a Lifecycle Taxonomy. A Software Development Taxonomy is a taxonomy of methods. A Lifecycle Taxonomy is a taxonomy of activities (grouped into phases and eras). "Lifecycle" might be a synonym for "Process". Software development is more than thinking about and organising the process. So a Software Development Taxonomy includes, and is broader than, the Lifecycle Taxonomy.

Here is our Software Development Taxonomy.

Approach

Software Development Approach
All and any knowledge and code that can be brought to bare on how to best to deliver a software solutions.

Software Development Approach:

  1. Software Development Methodology
    1. Software Development System
      1. Software Development Methods
    2. Software Development Taxonomy
  2. Technology Specific Code (libraries, IDEs, examples, tools, etc)
  3. Technology Specific Information (tips, techniques, quick references, etc).