Maintainability & Marketing
Negotiating 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 Magazin
discussing 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

More Related Content

PPTX
Lei nº 4.898 abuso de autoridade esquematizada
PPTX
Building Quality in Legacy Systems - The Art of Asking Questions, JavaZone VR...
PDF
Software testing kn husainy
PDF
How To Integrate Independent QA To Shorten Development Cycles
PDF
01 the value of quality
PDF
software engineering unit 3 chapter1-190805164730.pdf
PPTX
Software Engineering by Pankaj Jalote
PDF
NessPRO Italy on CAST
Lei nº 4.898 abuso de autoridade esquematizada
Building Quality in Legacy Systems - The Art of Asking Questions, JavaZone VR...
Software testing kn husainy
How To Integrate Independent QA To Shorten Development Cycles
01 the value of quality
software engineering unit 3 chapter1-190805164730.pdf
Software Engineering by Pankaj Jalote
NessPRO Italy on CAST

Similar to Presentation daniel takai (20)

PPTX
Lecture 3 software_engineering
PPT
System quality attributes
PDF
Ady beleanu automate-theprocessdelivery
PDF
Rtc2014 automate the_process_deliver_quality_ady_beleanu
PDF
Building Quality in Legacy Systems - The Art of Asking Questions
PPT
3. quality.ppt
PDF
5 Quality
PPTX
Software quality
PPTX
Quality of software
PPT
Software quality assurance lecture 1
PPTX
Lecture 3 software_engineering
PPTX
vnd.openxmlformats-officedocument.presentationml.presentation&rendition=1.pptx
PPT
Improving software economics
PDF
Software systems engineering PRINCIPLES
PPTX
What is Software Quality and how to measure it?
PDF
Software Quality Assurance Model for Software Excellence with Its Requirements
PDF
High Quality Software Development with Agile and Scrum
PPTX
software quality planning and management
PPT
Softwaretesting
Lecture 3 software_engineering
System quality attributes
Ady beleanu automate-theprocessdelivery
Rtc2014 automate the_process_deliver_quality_ady_beleanu
Building Quality in Legacy Systems - The Art of Asking Questions
3. quality.ppt
5 Quality
Software quality
Quality of software
Software quality assurance lecture 1
Lecture 3 software_engineering
vnd.openxmlformats-officedocument.presentationml.presentation&rendition=1.pptx
Improving software economics
Software systems engineering PRINCIPLES
What is Software Quality and how to measure it?
Software Quality Assurance Model for Software Excellence with Its Requirements
High Quality Software Development with Agile and Scrum
software quality planning and management
Softwaretesting
Ad

More from connectwebex (19)

PDF
Jackrabbit OCM in practice
PDF
Building Creative Product Extensions with Experience Manager
PDF
AEM 6 DAM - Integrations, Integrations, Integrations
PDF
JCR, Sling or AEM? Which API should I use and when?
PDF
Build single page applications using AngularJS on AEM
PDF
SonarQube for AEM
PDF
Presentation thomas simlinger
PDF
five Sling features you should know
PDF
Efficient content structures and queries in CRX/CQ
PDF
Web, Mobile, App and Back!
PDF
Tighten your Security and Privacy
PDF
THE BREAK-UP - A user interface love story
PDF
Configuring CQ Security
PDF
Integration Testing in AEM
PDF
Sling Component Filters in CQ5
PDF
Integrating Backend Systems
PDF
Scaling CQ5
PDF
Auto-testing production CQ instances with Muppet
PDF
CQ Maven Methods
Jackrabbit OCM in practice
Building Creative Product Extensions with Experience Manager
AEM 6 DAM - Integrations, Integrations, Integrations
JCR, Sling or AEM? Which API should I use and when?
Build single page applications using AngularJS on AEM
SonarQube for AEM
Presentation thomas simlinger
five Sling features you should know
Efficient content structures and queries in CRX/CQ
Web, Mobile, App and Back!
Tighten your Security and Privacy
THE BREAK-UP - A user interface love story
Configuring CQ Security
Integration Testing in AEM
Sling Component Filters in CQ5
Integrating Backend Systems
Scaling CQ5
Auto-testing production CQ instances with Muppet
CQ Maven Methods
Ad

Presentation daniel takai

  • 1. Maintainability & Marketing Negotiating sensible schedules for content heavy, volatile system development Daniel  TakaiBasel,  24.  Juni 2015
  • 2. © 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…
  • 3. © Unic - Page 3 I’m a witness of failure…
  • 4. © Unic - Page 4 … because time-to-market … but they’re rarely based on sound and sensible planning Schedules are tight…
  • 5. © Unic - Page 5 Sorry, we already booked the TV spots.
  • 6. © 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
  • 7. © Unic - Page 7 You do the right thing and start negotiating. Option two
  • 9. © 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
  • 10. © 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
  • 11. © Unic - Page 11 Qualities One of the main reason of software “failure” are missing quality requirements. Performance Security Usability etc.
  • 12. © 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.
  • 13. © Unic - Page 13 Maintainability … describes the ability to change your software system across it’s entire lifecycle.
  • 14. © Unic - Page 14 Conceptual Integrity … … describes the degree of cohesion and consistency of requirements
  • 15. © Unic - Page 15 Conceptual Integrity
  • 16. © 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
  • 17. © 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
  • 18. © Unic - Page 18 Consistency
  • 19. © 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
  • 20. © 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
  • 21. © Unic - Page 21 Analyzability
  • 22. © 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
  • 23. © 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
  • 24. © Unic - Page 24 Testability
  • 25. © Unic - Page 25 If you lack testability … … you might as well stop now and save yourself the trouble
  • 26. © 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
  • 27. © Unic - Page 27 Changeability
  • 28. © 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
  • 29. © 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
  • 30. © Unic - Page 30 Negotiation techniques
  • 31. © 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
  • 32. © 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
  • 33. © 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.
  • 34. © 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
  • 35. © 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
  • 36. © 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
  • 37. © Unic - Page 37 The iron triangle of project management Cost Time Scope Quality
  • 38. © Unic - Page 38 The Scotty Principle Gross overestimations will buy you time, but will they help you in the long run?
  • 39. © 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.
  • 40. © Unic - Page 40 Find out more! I’m publishing a series in Java Magazin discussing quality requirements of web systems
  • 41. © 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
  • 42. © Unic - Page 42 @danieltakai
  • 43. © Unic - Page 43