friday-rant
Software & Web Development

Rant: The Theory and Tragic Reality of IT Projects

Most of today's senior coders will have kickstarted their programming careers after learning their trade at school, on a small beige box running a variant of BASIC. Misty-eyed nostalgic types and authors of sanitised books on the subject will wistfully recall their first BASIC program:

10 PRINT "HELLO WORLD!"

20 GOTO 10

This is inexcusable rewriting of history, since what they actually wrote was:

10 PRINT "SMIFFY IS A W*****!"

20 GOTO 10

Regardless, BASIC required a simple form of development model. You had to decide what you were going to write... and then write it. Since the computers of the day had barely enough memory to contain one of today's HTML emails, thinking too much about development methodology was redundant.

But the days of the lone programmer writing a serious piece of software from start to finish are almost over. It is still possible, and there are some shining gems produced this way, but most corporate software projects today involve groups of developers, often working in remote teams and with numerous personnel changes over the lifecycle of a piece of software.

This type of project requires careful management, regardless of the programming language involved. Several different types of development model have evolved to cope with the challenges of creating software code that works well, is properly commented and can be updated later by people who weren't involved in writing the original program.

With, it must be said, varying levels of success. Here are some of the development models currently in vogue (with definitions courtesy of Wikipedia) followed by what tends to happen in practice.

 

Waterfall model - the theory

Developers have to follow these phases in order:

  • Requirements specification (Requirements analysis)
  • Software design
  • Implementation and Integration
  • Testing (or Validation)
  • Deployment (or Installation)
  • Maintenance

In a strict Waterfall model, after each phase is finished, it proceeds to the next one.

 Waterfall model - the practice

  • Requirements specification is carried out by asking the business lead what he or she wants. Business lead knocks up a vague PowerPoint presentation on a Friday afternoon. Dev team asks for more detailed information, receives a hastily-drafted Word document full of contradictions. Document is batted back and forth until a compromise is reached that suits nobody, with seething resentment on both sides.
  • Software is designed, with liberal 'initiative' taken by dev team to work around gaping holes in the specification.
  • Software is implemented, bearing vague resemblance to initial business case requirements. Business lead has shouting match with dev team project manager.
  • Testing is carried out by bribing random employees with coffee and sticky buns. Testing team approves software, aside from list of irrelevant and exotic complaints that leads dev team to question their sanity.
  • Software is deployed anyway, with catastrophic effects on morale and business efficiency.
  • First 'maintenance' release is actually a ground-up rewrite. Business lead absent due to stress-related illness.

 

Spiral model - the theory

The key characteristic of a Spiral model is risk management at regular stages in the development cycle. It includes some aspects of the waterfall model but with emphasis on deliberate iterative risk analysis, particularly suited to large-scale complex systems.

The Spiral is visualised as a process passing through a number of iterations of the following activities:

  • Formulate plans: identify software targets, implement the program, clarify the project development restrictions
  • Risk analysis: an analytical assessment of selected programs, to consider how to identify and eliminate risk
  • Implementation of the project: the implementation of software development and verification

Spiral model - the practice

  • Plans are laid, unencumbered by reality. Business lead wants an all-singing, all-dancing system and specs it out lavishly, including a vague reference to 'the cloud' which looks good but does nothing.
  • Risk analysis: dev team read through specs, cry with laughter, post them online for other devs to laugh at, then explain to business lead in patronising language why the inherent risks are so large that the contingency costs would sink the company. Business lead scales down plans, but keeps the cloud bit.
  • Dev team implements the project, oblivious to the business risks in their own coding techniques.
  • Process repeats for subsequent phases, like building a Plasticine skyscraper on foundations of custard.

 

Iterative and incremental development - the theory

The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier parts or versions of the system. Learning comes from both the development and use of the system, where possible key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented.

Iterative and incremental development - the practice

Exactly as per the theory, because the grand name of this method is merely putting lipstick on a pig. In short:

  • Build it
  • Realise it doesn't do what it was supposed to do
  • Add another bit to handle that
  • Fix the bits that broke when you added the new bit
  • Repeat

This is the natural way for humans to program machines, but giving it a fancy name allows programmers' CVs to look more impressive.

 

Agile development - the theory

Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes fundamentally incorporate iteration and the continuous feedback that it provides to successively refine and deliver a software system.

Agile development - the practice

Same as Iterative and incremental, only with Agile you get to blame a bigger group of people, especially the customer, when it all goes wrong.

 

Combined models - the theory

These days it's common for different development models to be used for different sections of a software project, before the finished parts are assembled into a working whole.

Combined models - the practice

The flaws in each method are magnified dramatically when combined, leading to iterations of agility that incrementally spiral downwards into a waterfall of broken code.

 

 

Freelance technology journalist Alex Cruickshank grew up in England and emigrated to New Zealand several years ago, where he runs his own writing business, Ministry of Prose.

PREVIOUS ARTICLE

« News Roundup: Dating Experiments, Tech Savvy Kids and Dancing Elephants

NEXT ARTICLE

Why Corporations Must Help Lead the Education Charge »
author_image
Alex Cruickshank

Alex Cruickshank has been writing about technology and business since 1994. He has lived in various far-flung places around the world and is now based in Berlin.  

  • Mail