User Tools

Site Tools


sustainableproductivity

Requirement #3: Sustainable Productivity

Sustainable productivity is one of the basic RequirementCategories. It's a lifetime requirement rather than a runtime requirement. Its quality cannot be checked by the customer by exercising the software. Instead the development over time of costs per feature, cycle time, and number of bugs need to be observed.

Flow-Design argues that to keep the productivity high code needs to be:

  • correct
  • changeable

Correctness

If code is not correct, i.e. does not fulfil functional and efficiency requirements, then further development is impeded. If incorrectness is not constantly kept at a minimum it will increase and eat more and more resources. Rather than adding new features developers will fix bugs. But fixed bugs don't help sell the software, only new features do.

Correctness of a growing code base can only be guaranteed with automated tests with considerable code coverage. Such tests serve two purposes:

  • Maturity - With regard to a new feature software is mature if the code is already correct, i.e. passes acceptance tests.
  • Freedom from regressions - With regard to already implemented features software is free from regressions if the code is still correct, i.e. passes all previous acceptance tests.1)

Whereas maturity might be established in certain cases with manual tests (which is still done by many developers on a regular basis), freedom from regressions cannot be reliably attested with manual tests. Manual tests don't scale.

Changeability

Incorrect code needs to be changed to correct it; but even correct code needs to be changed all the time. That's what software development is about: a constant flow of change request of unknown impact on a code base. The primary property of code thus needs to be changeability. It needs to be easy to adapt it to new requirements, small and large.

For Flow-Design such changeability consists of:

  • Understandability - Code needs to be easy to read, easy to reason about. Only if developers can quickly determine what code currently does and how that's accomplished they can hope to efficiently and effectively alter it to conform to new requirements.
  • Testability - In order to easily change existing Logic and to introduce new Logic it's paramount that code can be tested automatically without much effort and in a fine grained manner.

From the point of view of Flow-Design testability is the goal and modularity is a means to achieve this goal.

1)
A regression occurs if a system falls back to a previous level of maturity. It looses a capability it already had. The more complex a code base becomes the higher the risk of regressions. While adding a feature here developers break a feature over there - inadvertently and without realising it. Automated tests provide a safety net against this.
sustainableproductivity.txt · Last modified: 2018/04/22 10:39 by fdadmin