The key defining characteristics of software is the software lifecycle. The lifecycle defines the type of software development in many ways and some of the most significant software ‘screw-ups’ and dissatisfaction can come from applying software development methodologies appropriate for one software lifecycle,  to a very different software lifecycle.  Best practice for one software lifecycle should not be assumed to be best practice for a different lifecycle.

Many software developers and businesses predominantly experience one lifecycle category, so are unaware just how different things are on the ‘other side’. This page looks at things how software changes vastly based on the lifecycle picture:

• developer single use software
  • a developer writes software to either their own or an existing spec for the use case that they themselves will use the software or submit the software for making
  • lifecycle: all software development ends when developer is satisfied or after ‘acceptance tests’
  • examples: single use software, reporting software, exercises to learn software development, data analysis software, prototypes
  • methodology: ad hoc development
• custom development project software
  • someone other than the developer(s) either suggested or commissioned the development of the software
  • software is written to a specification and will be complete once the specification is considered ‘met’, or acceptance tests pass
  • examples: IT department projects, some software product versions
• Continuous development software
  • the development team design and develop software to meet a perceived need
  • lifecycle: development continues until software is ‘end of life’
  • example: agile product software / Software as a service
  • definition: software in continuous ongoing development
  • examples: products software with frequent updates, product web sites such as Amazon, Facebook etc
• Spaning Lifecycles.
• The impact of type/lifecycle on development
• Conclusion (TL;DR): It is all about the Spec and The Tests.

Developer Single Use Software

Definition: The developer will be the main person to use the software. Once it ‘works’, the code may never need to changed. The Software will only be used when the developer is present, or through automated testing tools.

Lifecycle: The source code is usually no longer needed once the code is judged as complete. On occasions, this software can be ‘brought back from the dead’, but usually, only the developer even knew the software existed.

This is ever expanding area of software.  Just as typing was once performed by specialist typists, but now everyone can type, we are moving towards a world where everyone can program.

Examples:

• Tutorials, Education exercises and assignments
• Data conversion software and single run reports and data analysis
• Some embedded systems
• Software for environments that will never change
• The very first computer programs

Why write software for a single use?  This is not how most non-programmers think of software, but in fact a very significant and ever increasing proportion of software is written for use only by the author of the software, and for use in a few runs of the software, with the software very often then abandoned.  Consider how we learn to program.  Once the software is marked, it has served its purpose and will normally be abandoned.  In fact, most of us learn to program writing almost only single use software. Over and over we improve this skill.

Having learnt to program, some software developers will then need to change processes to those used in custom software developments or agile continuous developments, while others continue to write software that they will run for their own use, and will continue with the single development process.

There are also custom developments where the software is frozen once written.

Examples of this type of development may also occur within software teams developing custom single use software or continuous developments.   As an example, consider a program to migrate a database from one format to another, which is a program that will no longer be needed once the software has been successfully migrated.

However many developers will focus only on single use software. Many clinical trials or other scientific data collection collect only one single data set, or a very limited number of datasets, and the team developing the software will also run the software (or assist in running the software).  Once the data reporting is complete the software to analyse a given data set will often no longer be required.   Researchers and astronomers or people who have software as a skill which enables them to write their own programs to get results are example of people who may never experience any other programming that single, developer is the user software.

Some software has only a single use, but that single use occurs over and over without any requirement for the software to ever change.  This software is only developed once, but the developers of the software are not available when the software is to be used, which gives a one time development, but without the characteristic of the software being for the use of the developer(s).  A toaster could contain embedded software that fits this description.  The operating system will never change, nor will any of the toaster hardware during the production.  If any new model will be a complete redesign, then the software will in some ways be single use, but still better fits the Single Custom Development Software pattern.

Single Custom Development Software

Methodology:  Rapid Development, then maintenance.  There is a range of software under this heading, but most developments are undertaken to a specification, effectively in a single sprint (one sprint = waterfall).   While TDD may be justified, there is less real need for unit tests after the original development as there may be modifications as part of maintenance but continued development is not the plan at the time the project is written.

Definition: Bespoke Software, written to meet a specific identified requirement, and then judged as complete once the software passes acceptance tests.

Lifecycle: Once the software meets ‘acceptance tests’, the main software development is complete and ‘mature’, and maintenance is then the only ongoing development.

Examples:

• Contracted Developments for an IT Department
• Most IT department Internal Projects
• Discrete, Large Scale Software Product Releases

Most of the IT industry is involved in the production of Bespoke, Single Development software.  The classic example is a software system written for a government department or large corporation to automate data collection and data processing. While the key characteristic of Bespoke software is an acceptance test process, which could seem to preclude product software, individual releases of product software can be also produced as bespoke, single development projects, with product management in the role of the development customer.

Methodology: Usually waterfall.

Continuous Development Software

Definition: Developers continually modify code to add enhancements with new functional versions available daily or at least monthly, even if many of these updates are labelled ‘early access’ or ‘insiders’. New major releases are usually available on regular intervals and the ‘acceptance test’ is gone and replaced by automated unit and integration tests which are run not to be passed once, but to be passed as often as daily.

Lifecycle: Development never ends while the software is active.

While with Single Use and Single Development software, the software is released for use when development has finished.  The announcement development will finish for continuous development software will lead to all users of the software moving to an alternative.

Examples:

• Python (the language, as on Python.org)
  • release whenever chosen stories complete
• Android
  • a release around August each year
• Windows 10
  • new releases on six month intervals (1803 for 2018-03)
  • Previous Windows seemed more like Single Development
• Ubuntu
  • Released April and October each year

Methodology: Unit tests and easy maintenance are as important as the implemting of functionality. With Single Use/Single Development software the goal is simply to get the functionality working and pass acceptance test. With continuous development software, functionality added today will likely be as waste of time without easy maintenance and unit tests. The code will soon be dropped by a subsequence developer if they cannot understand the code or did not even know the functionality was ever there.

Spaning Lifecycles.

Agile really only came into existence with the agile manifesto in 2001.  Prior to that, waterfall was the most followed approach.  That there are today so many continuous development projects mean some teams and projects move from one development lifecycle to another.

A large bank, may have their own internal website and//or mobile apps now developed as continuous development projects, but there internal banking systems developed as traditional waterfall with the external management giving comfort.

The Impact of Lifecycle on Development.

A continuous development lifecycle requires agile developers in place of waterfall programmers, analysts and project managers, and at least compare to waterfall programmers, this is a greater skill set which can result in a more expensive team.

Further, to reach a given milestone, more effort is generally required.  It takes longer to write concise readable code than just get a solution working.

However, a team developing as a project a series fixed developments for each release will tend to plateaux – with new releases failing to be seen as a step forward, as the less readable code is continually replaced from scratch.  This leaves developers starting again over and over rather than standing on the shoulders of others, and not being able to reach the same heights.

Of course, continuous development without sufficiently readable code will have the same plateaux effect.

Conclusion: its all about the Spec and Tests

The role of the spec.

The form of the spec determines the lifecycle, which in turn determines the suitable development methodology.

• Single use software often has a spec which simply lives in the authors mind.
• Single Development software typically has a well formed and detailed spec, and the agreement of that spec, and a timeframe and/or cost to deliver that spec may be the basis on which the development project is launched.
• Agile Developments have an ever evolving spec, and with continuous development projects, sometimes even evolving requirements.

Single use/development software is coded to a fixed spec, which is optimised more for waterfall, while coding to an evolving spec requires agile.

The software is ‘complete’ when final tests are met.

The Role of Tests

The reality is, in all cases, the tests become specification of the actual system.  The tests represent what the system is measured to deliver, and the spec documents are relegated to ‘design goals’.   Think of a car developed with to a specification, the car engine should develop 100kiloWatts of power. Once the car is developed, the real output is measured, and that goes on the specification.  The original ‘spec’ is now considered a design goal.  You set out to build a bookcase, and want it 1 meter wide.  But the real ‘width’ spec is determined by measuring, not by what the goal was.

If software was developed under contract, then the contract is paid once acceptance tests are passed.  If a feature was in the ‘spec’ but not in the acceptance test, then it may not be in the software.  The spec was really a design document for both the code and the tests.  But in the end, what is measured is the real specification.

The key point is that if a feature is not included in testing, it may not be in the system.  With continuous development, if a feature is not included in tests, it may not stay in the system even if it was there at one time.