Presentation daniel takai

Maintainability & MarketingNegotiating sensible schedules for content heavy, volatile system development

Daniel  TakaiBasel,  24.  Juni 2015

© Unic - Page 2

… are often cornerstones of marketing endeavors

… should usually serve business for many years

… require many different editors producing content 24/7

… in many languages

… in a global environment

… are subject to frequent change

Content heavy web systems…

© Unic - Page 3

I’m a witness of failure…

© Unic - Page 4

… because time-to-market

… but they’re rarely based on sound and sensible planning

Schedules are tight…

© Unic - Page 5

Sorry, we already booked the TV spots.

© Unic - Page 6

You agree with the schedule, chuckling about their naive innocence, knowing well that once the time comes nothing will be finished or working.

You immediately plan a vacation for the release date.

Option one

© Unic - Page 7

You do the right thing and start negotiating.

Option two

ETHICS

© Unic - Page 9

- Avoid unnecessary and uncontrolled complexity

- Foster trust

- Respect the interests of others

- State of the art

- Work against unreasonable expectations

- Do not squander resources

Software professional ethics

Examples taken from the Ethics guidelines of the Swiss Informatics Society

© Unic - Page 10

What will make your project later?

… adding manpower

… no requirements, but a detailed specification, 3000 pages

… service integrations

… no architecture

… waterfall … or no understanding of agile

… stakeholder communication

© Unic - Page 11

Qualities

One of the main reason of software “failure” are missing quality requirements.

Performance

Security

Usability

etc.

© Unic - Page 12

Qualities

A quality usually has a large impact on the architecture of a system – and therefore on the cost of the system.

Think Availability 99.999%.

So for each quality desired, a list of measures to reach that quality must be discussed and negotiated.

© Unic - Page 13

Maintainability

… describes the ability to change your software system across it’s entire lifecycle.

© Unic - Page 14

Conceptual Integrity …

… describes the degree of cohesion and consistency of requirements

© Unic - Page 15

Conceptual Integrity

© Unic - Page 16

If there is no integrity…

… your system will be more difficult to change because conflicting requirements will be mirrored in the code base

… your system will be more difficult to change because the code base is larger if cohesion is low

… the usability of your system will degrade due to low cohesion because the intent is more difficult to explain to a visitor

© Unic - Page 17

Consistency …

… describes the continuous application of design decisions

… fosters the unified usage of product, production and documentation technologies

… is basically about creating and keeping a known environment that the team is comfortable with

© Unic - Page 18

Consistency

© Unic - Page 19

If there is no consistency…

… the changeability of your system suffers, because due to increased complexity, changes take longer and are therefore more expensive to implement

… your system will suffer a slow, agonizing death

© Unic - Page 20

Analyzability…

… desribes the effort needed for analyzing a defect

… describes the effort needed for failure diagnosis

… desribes the effort required for identification of parts to be modified

… can be pro-active

© Unic - Page 21

Analyzability

© Unic - Page 22

If your system is not analyzable…

… bugfixing will take longer

… change impact analysis will be spotty, resulting in large cost over- or underruns

… you run the risk of performance and security issues

© Unic - Page 23

Testability …

… is concerned with being able to verify the quality of the system

… includes the physical possibility of testing

… but is mainly concerned with being able to automate tests as this is the most sustainable investment

© Unic - Page 24

Testability

© Unic - Page 25

If you lack testability …

… you might as well stop now and save yourself the trouble

© Unic - Page 26

Changeability …

… describes how your system can be changed

… applies to both adaptive as well as perfective changes

… determines cost per change across the system lifecycle

© Unic - Page 27

Changeability

© Unic - Page 28

If you lack changeability …

… you will have a hard time getting changes into production

… which means increased costs and time-to-market

… which means your system will die sooner rather than later

© Unic - Page 29

Once the system cannot be changed within a reasonable amount of time and for a sensible amount of money, it is considered

legacy.

Legacy  Scare

© Unic - Page 30

Negotiation techniques

© Unic - Page 31

Step 1) Create awareness

Software development is hard because …

… software is intangible

… software is malleable

… software has hidden complexity

So discussing required system qualities, especially maintainability is very important

© Unic - Page 32

Step 2) Investment appraisal

Having explained the legacy scare, find out how many years the system shall live

Then discuss the change rate and the number of releases scheduled per year

Calculate cost per release with

varying factors depending on how much

is invested in maintainability

© Unic - Page 33

Step 3) Marchitecture

Create a simple building block diagram which shows the main system components. Use this to illustrate change and planning discussions.

© Unic - Page 34

Step 4) Separation of concerns

Split content form its representation via a defined content model

Use content page tables to further editorial work

© Unic - Page 35

Step 5) Decouple content entry

Use a separate system for content entry

You can use another AEM instance for this, or a SAAS service like GatherContent

© Unic - Page 36

Step 6) Scope

Use the iron triangle to your advantage and limit the scope

Less is more, especially in the beginning of a web project

© Unic - Page 37

The iron triangle of project management

Cost

Time Scope

Quality

© Unic - Page 38

The Scotty Principle

Gross overestimations will buy you time, but will they help you in the long run?

© Unic - Page 39

Step 7) Foster trust

Whatever  happens,  you  must  deliver  as  promised.

Software  must  work.  There  can  be  no  such  thing  as  a  functional  defect.

© Unic - Page 40

Find out more!

I’m publishing a series in Java Magazindiscussing quality requirements of web systems

© Unic - Page 41

Join my workshop on web architecture in Munic @ W-JAX 15

6. November 2015

https://jax.de/wjax2015/sessions/webarchitektur-und-qualitaetsmerkmale

© Unic - Page 42

@danieltakai

© Unic - Page 43