The document discusses technical debt in CyberArk. It begins by introducing CyberArk and defining technical debt. It then describes how CyberArk started assessing technical debt through code quality tools and meetings with teams and management. CyberArk allocated time to focus on technical excellence, refactoring, and infrastructure upgrades to reduce technical debt. The document outlines lessons learned around the long-term nature of reducing technical debt and the need for manager engagement and consistent effort to drive change.
Right Money Management App For Your Financial Goals
Technical debt in cyber ark [agile practitioners-2015]
1. 1
Technical Debt in CyberArk
Noam Zweig, System Architect & Technical Lead, R&D
Ran Deri, Group Manager, R&D
2. 2
CyberArk Snapshot
▪ Specializes in targeted cyber-attacks and advanced-threats protection
▪ Fast Growing, Market Leader in Privileged Account Security
▪ 2nd largest Israeli Information Security Company
▪ Proven successful continuous innovation
3. 3
Other IndustriesFinancial ServicesCommunications &
Media
Pharmaceuticals Energy & Utilities
Trusted experts for more than 1,600 organizations worldwide
Customer Snapshot
40% of the Fortune-100 18 of the Top-20 Global Banks 8 of the Top-12 Pharmaceuticals
4. 4
What are we talking about?
▪ Technical Debt
A little debt speeds development so long as it
is paid back promptly with a rewrite... The
danger occurs when the debt is not repaid.
Every minute spent on not-quite-right code
counts as interest on that debt. Entire
engineering organizations can be brought to a
stand-still under the debt load of an
unconsolidated implementation, object-
oriented or otherwise
- Ward Cunningham
http://c2.com/cgi/wiki?WardExplainsDebtMetaphor
5. 5
What are we talking about?
▪ Technical Debt
A little debt speeds development so long as it
is paid back promptly with a rewrite... The
danger occurs when the debt is not repaid.
Every minute spent on not-quite-right code
counts as interest on that debt. Entire
engineering organizations can be brought to a
stand-still under the debt load of an
unconsolidated implementation, object-
oriented or otherwise
- Ward Cunningham
http://c2.com/cgi/wiki?WardExplainsDebtMetaphorEventual consequences of poor system design,
software architecture or software
development within a codebase
- wikipedia
http://en.wikipedia.org/wiki/Technical_debt
6. 6
What are we talking about?
▪ Technical Debt
A little debt speeds development so long as it
is paid back promptly with a rewrite... The
danger occurs when the debt is not repaid.
Every minute spent on not-quite-right code
counts as interest on that debt. Entire
engineering organizations can be brought to a
stand-still under the debt load of an
unconsolidated implementation, object-
oriented or otherwise
- Ward Cunningham
http://c2.com/cgi/wiki?WardExplainsDebtMetaphorEventual consequences of poor system design,
software architecture or software
development within a codebase
- wikipedia
http://en.wikipedia.org/wiki/Technical_debt
Like a financial debt, the technical debt incurs
interest payments, which come in the form of
the extra effort that we have to do in future
development because of the quick and dirty
design choice
- Martin Fowler
http://martinfowler.com/bliki/TechnicalDebt.html
7. 7
What are we talking about?
Continuous attention to technical excellence
and good design enhances agility
- Principles behind agile manifesto
http://www.agilemanifesto.org/principles.html
8. 8
Let’s return the debt!
▪ After learning the area, we found out that the
regular HK mechanism is not satisfying
for proper return of Technical Debt
▪ So why not extending the
mechanism/invest in it?
PSHHH…
That’s not easy to perform cross R&D
10. 10
Drifting into the comfort zone…
▪ Housekeeping time we can choose to improve:
▪ “do it fast” and
“do it on time” ->
Immediate and tangible value
“do it right”
and “keep doing it” ->
Long term and intangible
Do it
fast
Do it
right
Do it on
time
Keep
doing it
12. 12
And so we started
- Results analysis with teams
13. 13
And so we started
- Meetings with Business People (PM,
management)
14. 14
And so we started
0
5
10
15
20
Alpha Beta Gamma Delta
Debt Allocation
- Pre quarter – time allocations
- Allocations are correlative to debt
15. 15
And so we started
0
5
10
15
20
Alpha Beta Gamma Delta
Debt Allocation
- Focus on “do it right”
- UT infrastructures
- Separating coupled components
- Refactor complex areas
- Upgrading infrastructures
16. 16
And so we started
0
5
10
15
20
Alpha Beta Gamma Delta
Debt Allocation
- Collected info + visualize
17. 17
And so we started
0
5
10
15
20
Alpha Beta Gamma Delta
Debt Allocation
- And back again…
18. 18
Lessons learned
Enhance and groom the
non-functional
areas of the products require
long and
permanent work
(Especially when
the need is “burning”)
Convince levels
(“this is important
“let’s work on it”)
Measurement helps!
