Software Development
 
Search this site

Navigation

Copyright


© 2008 Ben Gidley.

Why Do We Build Software

The Basics we must NEVER Forget

  • Projects exist to deliver a business need 
  • All work done should further that goal
  • Techniques exists to help deliver business need - they should be measured in their utility
  • Techniques are processes that aid the Project Management and the Software Development Process (or both)

Some History 
Historically there has been a big divide between 'Waterfall' and 'Agile' software development methods.
Waterfall - e.g. SSADM tend to have the following key features
  • Define the requirement and assume it will broadly not change
  • Define the design
  • Implement
  • Test
  • Use
Some Waterfall techniques suggest strong feedback loops between these phases and allow a project to 'iterate' between the phases (which almost makes them agile). 

Agile - e.g. SCRUMM, XP, DSDM, RUP tend to have the following key feature
  • Engage the development team directly with the business
  • Work in short period (aka Sprints or Timeboxes)
  • Deliver a slice of the system in each timebox
  • Requirements are gathered relatively informally and are assumed to charge at the whims of the business
  • Strong focus on programming techniques (XP, SCRUMM)
  • Strong focus on busiess value (DSDM)
In reality very few projects strictly follow either approach. Most end up somewhere in the middle. Many start off with waterfall style defined requirements and then use an agile like iterative approach to hit their goals. Others start off with weak requirements (agile style) but end up being 'fixed' by writing strong clear requirements during the project.
 
Unfortunately (for the IT industry as a whole) the advocates of Waterfall and Agile (well mainly Agile advocates) appear to believe they are on some religious crusade and therefore people find it really hard to admit to joining the two approaches. I have seen quite often a 'smart ass' come into a project and say
Either
  • If you only had more and better documentation all would be well
Or
  • If only you used more agile techniques all would be well
And what is really annoying - is they are often a bit right. I don't mean all will be well - as there are no Silver bullets - but that adding some new ideas midway through a project is a useful way to stop group think and to stop people hiding things.
 
In addition to the agile/waterfall debate - there is the Project Management approach debate. Many development staff often see Project Management as kind of seperate to the development process. I think this is a major mistake. Politics, issues, change control, risk management, reporting and tracking are critical to any project regardless of the development approach.
 
When looking at Project Management techmniques the same test should apply as to any other technique - does it help deliver the business need.
 
So to recap project techniques should be selected to meet the business need.
 
The above sentance is a good summary - but next we need to understand business need. It often is a combination of
- Delivery of some features within a timeframe
- Delivery of a cost/benefit analysis
- Delivery within acceptable tolerance for risk

See my page on determining business need for some more thoughts on this.