10 Thesen zur professionellen Softwareentwicklung

© OPITZ CONSULTING 2021 / Öffentlich
10 Thesen zur professionellen SW Entwicklung
Zur professionellen SW
Entwicklung
#SEACONdigital, 21.04.2021
Richard Attermeyer
10 THESEN

THE GOOD OLD TIMES

 JSF (Java Server Faces) or Spring MVC:
Java Programming Model for the web
 Java, the Language
 No JavaScript, SQL, … everything abstracted away
 Tomcat: A small web container
 Install it plain on your machine
 RDBMS
Oracle, abstracted away by JPA/Hiberante
 That‘s it.
 Ok, Maven, git and Jenkins CI.
 That‘s it… really

One Language
One Development Stack
Production is an afterthought

10 PROPOSITIONS
 Market trends that influence SW architectures
and development processes
Foto von Monika Baumgartner von Pexels

10 PROPOSITIONS
 Feedback Cycles and common
responsibility (DevOps culture) is a must to
run the applications
 The git pull-request model must be
mastered by every IT professional
 Shift-left many things
 Cloud-native as guiding principle
 Software Craftsmanship is established, but
more important than ever
 There is no fullstack-developer
 Everything is code
 Automate everything to reduce turn-
around times and handle complexity
 Openness to adapt to a quickly changing
ecosystem is vital
 Hybrid multi-cloud is the default

FEEDBACK CYCLES, DEVOPS AND
THE PIPELINE MODEL
 Individual, Team and the world
I
Foto von Isaac Weatherly von Pexels

DEVELOPER
Red
Green
Refactor
1. Write a test that fails
2. Make it work
3. Optimize. Eliminate
redundancy. Make code
more expressive without
adding new functionality
This cycle happens on the
developer‘s machine.
UNIT-TEST-CYCLE

DEVELOPER AND HIS TEAM
Branch /
Fork
Code
Collaborate
Merge
1. Create a branch for the task
2. Solve the task
3. Create a Pull Request and
collobarate with team to improve it
and fulfill Definition-of-Done
4. Merge to common development
branch
GIT-PULL-REQUEST-CYCLE

Plan
Develop
Verify Deploy
THE AGILE DEVELOPMENT CYCLE:
DEVELOPER, TEAM, PRODUCTOWNER
 Deploy to various staging environments
 Early feedback from product stakeholders on
the system under test
 Shorten feedback cycles for development
teams
 This will often work with only „working
software“
 Progress indicator: „working software“
 Shown in sprint review
AGILE CYCLE

BUSINESS
 Shorten value creation
cycle
 Shorten feedback cycles for
product teams
 This only works with
professional software that
can go into production at
any time
 Progress indicator:
live software with business
KPIs
Plan
Develop
Verify Deploy
Release
Monitor
Operate
Improve
PRODUCT-DEVOPS-CYCLE

THE DELIVERY PIPELINE
 Assumes no cycles and concentrates on the main process from commit to production
Commit Stage Build Stage
Automated
Verification
Stage
Deploy to
staging
environments
Manual
Acceptance
Test
Load Test /
Performance
Test
Security Test
Deploy to
prod
environments
Release
Code Pipeline Deployment Pipeline
 Ensure Software is always releasable
 Runs less often, only if software is
guaranteed to be working
 Feedback cycles often days up to 2-4 weeks
 Runs often
 Feedback cycles 10-15 min
Continuous Delivery Continuous Deployment
 Automatic deploy
and release to prod
 Needs to eleminate
manual steps in
continuous delivery

GIT MODEL
II

GIT PULL-REQUEST MODEL
▪ Traceability: Tickets, Build status
▪ Collaboration, discussion and knowledge
sharing
▪ Transparency: Who changed what and when
Branch /
Fork
Code
Collaborate
Merge

Every IT professional must understand the model and be
able to use git:
Developers
Operations
Business Analysts
… everyone involved in creating a solution

SHIFT-LEFT
III

SHIFT LEFT
 Move tasks from later stages to earlier stages in the pipeline to shorten cycle time
 Identifying issues earlier in the pipeline makes it cheaper to address issues and does not later
delay release
 You will build quality in earlier in the pipeline… and you discover delays in your project earlier
Commit Stage Build Stage
Automated
Verification
Stage
Deploy to
staging
environments
Manual
Acceptance
Test
Load Test /
Performance
Test
Security Test
Deploy to
prod
environments
Release
Code Pipeline Deployment Pipeline

SHIFT LEFT: ROLES CHANGE
Commit Push
Code Style
Check
Compile Unit Test
Integration
Test
Manual
Acceptance
Test
Load Test /
Performance
Test
Security Test
Deploy +
Release
 Specialists performed manual checks and created reports of findings
Commit Push
Code Style
Check
Compile Unit Test Image Build
Integration
Test
Statical
Source Code
Analysis
Load Test /
Performance
Test
Automated
Acceptance
Test
Security Test
Manual
Acceptance
Test
Deploy Release
 Specialists provide consulting, guidance and perform process control
 Recommend tooling and configure platforms
From
traditional
delivery
To
Modern
delivery

CLOUD-NATIVE
IV
Foto von Magda Ehlers von Pexels

CLOUD-NATIVE
THE RISE OF THE CONTAINERS
 Delivering Container images instead of simple
archives (Jar, War, zip)
 Local Development stack (on developer host) based
on docker-compose or „micro kubernetes“ distros
(kind, k3s)
 Containers are then deployed to various
environments (Kubernetes or non-Kubernetes)
 Container and kubernetes know-how is an essential
skill for every developer
 Yes, basic know-how of common network
components, like proxies, reverse-proxies, subnets,
becomes more important

OBSERVABILITY IS KEY!
Observability is key
in modern,
distributed IT system
landscapes
Important to identify
potential issues or
bottlenecks
Absolutely necessary
to ensure SLA
conformity
Try to get as much
insights as possible
by externalizing as
much information as
possible
Different levels to track:
API monitoring
Service monitoring
End-to-end monitoring
Log analytics
Application Performance
monitoring
Distributed Tracing

SOFTWARE CRAFTSMANSHIP
V
Foto von igovar von Pexels

SOFTWARE IS EVERYWHERE
The Brake System is powered
by Software
The quality of the brake
software is similar to the code
that you committed last week
Your mother-in-law is
about to get into the car
Your kids are about to get
into the car

DO YOUR KIDS DRIVE WITH THE CAR IF THE BRAKE SYSTEM
SOFTWARE HAS BEEN DEVELOPED BY YOU?
How do you know?
• How do you know that your system is
working correctly?
• … and how it deals with real life situations?
Why not?
• what is your software good enough for?
• for a demo, a PoC or a strictly controlled
prototype?

SOFTWARE CRAFTSMANSHIP:
FROM WORKING SOFTWARE TO PROFESSIONAL SOFTWARE
 Working software: Focus on functional aspects
 From functional to quality aspects
 Professional software: Focus on code quality on non-functional
aspects.
 Professional software: Task for the team and the whole group to
deliver software to the world
Functional
Specification & Unit
Test
Working Software
Professional Code
Built Software
Deployable Software
Professional Software:
Live and -able
Ready-
for-Code
Definition-
of-almost-
DONE
Definition-
of-DONE
ABLE
Verifi
Test
Oper
Read
Evolv
Maintain
Observ
Scal
Recover
Prov
Afford
Deploy
Audit
Impenetr

NO FULLSTACK DEVELOPER
VI

WHAT IS A FULLSTACK DEVELOPER?

NO FULLSTACK DEVELOPER
ONLY ONE FULLSTACK DEVELOPER
VI

THERE IS NO MORTAL FULLSTACK DEVELOPER
 Cloud-native applications rely on zoo of tools
and technologies
 Developers need a growing portfolio of skills to build
and maintain front-end tools, back-end architecture,
and all the supporting systems
 In-depth knowledge of programming languages,
databases, quality assurance, information security,
DevOps and more
 Differentiate between competency and
mastery
 Full-stack developers are generalists. They
can only be a master of one or two areas.
 What differentiates different levels is how
quickly a developer can apply his or her
competencies to exploit new technologies or
solve issues
 Mastery requires dedication
and time to
a single field (studying
the force, piano,
or an IT knowledge domain)

EVERYTHING IS CODE
VII
Foto von luis gomes von Pexels

EVERYTHING IS CODE
Not only code, but everything should
be kept in source control
Traceability and automation for ephemeral
environments
Source Code, Infrastructure Descriptions (e.g. Kubernetes ressources),
scripts to setup (e.g. Terraform) and configure infrastructure (Ansible),
Configurations and Documentation
Documentation as Code
Keep documentation in the same repositories as the
code
Support PR workflow for every artefact ➔ Generate
Diagrams from ASCII descriptions or at least embed
descriptions into images (PlantUML etc. / drawio)

DOCUMENTATION AS CODE

… OR USE IT AS DOCUMENTATION SITE GENERATOR
Antora Publication Pipeline
used by a lot of projects
 Couchbase
 Fedora
 Owncloud
 Apache Camel
 OC Engineering Handbook

NOT ONLY OPENSOURCE, BUT MICROSOFT
NOT ASCIIDOC, BUT MARKDOWN
 docs.microsoft.com built on
github
 See:
https://github.com/MicrosoftDocs

AUTOMATE EVERYTHING
VIII
Foto von Markus Winkler von Pexels

AUTOMATE EVERYTHING
 Automation is the way to provide expert knowledge to the project team
 Automation enables quality at scale when
 Generalists are in projects
 Experts are rare and not in the specific projects
Commit Push
Code Style
Check
Integration
Test
Statical
Source Code
Analysis
Load Test /
Performance
Test
Automated
Acceptance
Test
Security Test
Manual
Acceptance
Test
Deploy Release
Code scripts,
Policies,
pipelines,
platforms for
consumption
by project
teams

AUTOMATE EVERYTHING
 Automation is the way to provide expert knowledge to the project team
 Automation enables quality at scale when
 Generalists are in projects
 Experts are rare and not in the specific projects
 Experience gathered in project can be fed back using Pull Reqests
 Automation: documenting „WHY“ not „How“ is important
Commit Push
Code Style
Check
Integration
Test
Statical
Source Code
Analysis
Load Test /
Performance
Test
Automated
Acceptance
Test
Security Test
Manual
Acceptance
Test
Deploy Release
Pull Requests
document
experience
gathered in
projects

MINDSET
IX

MINDSET: SOFTWARE IS ONLY A MEANS TO AN END
OPENNESS TO ADAPT TO A QUICKLY CHANGING ECOSYSTEM IS VITAL
 We build software not for the sake of building
software
 We don‘t reinvent the wheel
 We support solving a real world problem and
want to generate business value
 Languages, tools and platforms change to better
support building the software that solves a
problem
 In unstable times, the tool landscape will be
unstable to
 If you do not adapt to the changing environment
you will go extinct (survival of the fittest)
Having the right mindset of adopting new tools, languages, platforms is vital.
Especially, if the main asset we sell is the knowledge to solve a customers‘ problem.
We need to quickly adapt to changing and varying customer requirements.
Customers do not expect experts in a specific technology. They expect experts in
quickly understanding technology and to turn it into an advantage.

HYBRID IS THE DEFAULT
X

HYBRID IS THE DEFAULT
 Systems are run on-premise and in the public
cloud
 You have to understand cloud models to
solve your customer‘s problems
 You need to understand limitations and
benefits of using cloud
 Consult on workloads suitable for clouds
 Know the data privacy implications when using
public cloud or SaaS options
 ….

QUESTION AND ANSWERS

Richard Attermeyer
Principal Architect
Software Development & Integration
richard.attermeyer@opitz-consulting.com
@rattermeyer

10 Thesen zur professionellen Softwareentwicklung

Related slideshows

More Related Content

10 Thesen zur professionellen Softwareentwicklung