This document contains Ken DeLong's work history, activities, favorite books, strengths, and views on software engineering best practices. It emphasizes hiring the best engineers, optimizing for learning, reducing waste, attention to quality, and avoiding technical and cultural debt.

1. Ken DeLong
6/8/2015 1

2. Work History
• Chief Software Architect, VP of Engineering,
Babybcenter
• Director of Engineering, Illumina
• Principle Consultant, Valtech Technologies
• Senior Software Architect, GE
6/8/2015Footer Text 2

3. Activities
• Meetups
o East Bay Java Users Group
o Tri-Valley Technology Professionals Meetup (I have spoken at this one)
o Docker, Containers & Cloud Foundry PaaS East Bay Meetup
• Github
o A library of Spring interceptors to facilitate stability in high-load servers
o A JMX console for viewing mbeans in a browser
o From a previous life: a program to characterize ultrashort laser pulses using
iterative phase retrieval
o A DSL to create AWS environments with Gradle (project died when I found
Ansible and CloudFormation!)
o A fractal imaging demo program
• Blog
o http://www.jroller.com/kenwdelong
6/8/2015Footer Text 3

4. Favorite Books
• Software Craftsmanship, Sandro Mancuso
• Clean Code, Bob Martin
• Lean Software Development, Mary Poppendieck
• Test-Driven Development, David Astels
• Release It!, Michael Nygard
• Planning Extreme Programming, Kent Beck
• The Goal, Eliyahu Goldratt
6/8/2015Footer Text 4

5. My Strength
• I think my greatest strength is to understand the
long-term ROI of projects, large and small.
• To know when it’s a good idea to invest in doing
something right, or when the shortcut will be good
enough.
• My overall goal is to maintain a high ROI (features
built per hour worked) indefinitely
o You can’t do this if all the previous features you wrote keep breaking or
have bugs or made the software so complex that you can’t alter it safely.
o You can’t do this without some kind of automated testing.
o You can’t do this without monitoring and data from production.
o Most engineers are happy to sacrifice tomorrow’s ROI in order to “get this
feature out” quickly. This is a trap.
6/8/2015Footer Text 5

6. Software Engineering
• Over $75 billion is wasted each year on failed
software project in the US alone. – Standish Group
• Therefore, there is a huge amount of research on
how software development works, what the KPIs
are.
• However, the vast majority of practitioners are
nearly completely ignorant of this research.
o Therefore, they work by “intuition” and “seat-of-the-pants”, making the
same mistakes over and over.
o A lot of the research result are counter-intuitive.
o So, to get it right, you need to be aware of the principles and stick to them.
6/8/2015Footer Text 6

7. A Quote
• “Why do so many teams practice crisis-driven
development in horrible code bases?” – Ashley
Johnson, Industrial Logic
6/8/2015Footer Text 7

8. True Cost of Software
• We know: about 70-90% of the total cost of software
is maintenance.
• Therefore: Engineer it correctly. You can reduce
your costs, and increase your ROI, up to a factor of
10, instead of rushing it out.
• Complete a feature (done done) so that work on it
does not continue into the indefinite future
o Long after it no longer appears on the project schedule.
6/8/2015Footer Text 8

9. The Bottleneck
• We know: the bottleneck in software development
is learning, not typing.
• Therefore: optimize for learning.
o Code reviews
o Pair programming
o Group design sessions
o Refactor endlessly
6/8/2015Footer Text 9

10. Flow Accounting
• We know: ROI is best measured by flow accounting,
not cost accounting.
• Therefore: reduce WIP and optimize for cycle time
of finishing a work item.
o Use Scrum or Kanban
o Stop starting and start finishing
6/8/2015Footer Text 10

11. Communication
• We know: poor communication is a major factor in
failed software projects.
• Therefore: optimize for communication
o Co-location
o Explicit sprint planning and group design sessions
6/8/2015Footer Text 11

12. Clarity is ROI
• We know: poor requirements is another major factor
in failed software projects.
• I have seen project teams, and whole departments,
flail due to a lack of proper clarity and planning
upfront.
• Therefore: be sure you have clarity from all team
members before you start, even if it takes “too long”
o Sprint goals
o Project goals
o Department goals
• An aligned team is amazingly productive; an
unaligned team can waste astounding amounts of
time and money.
6/8/2015Footer Text 12

13. Quality is Speed
• We know: obsessive attention to quality is a major
factor in successful, and fast, software projects.
• High quality software is a great asset
• Low quality software can easily have a negative
ROI
o Software projects with identical requirements have been documented
with up to a factor of 200 difference in cost.
• Therefore: Attention to quality is one of the most
important things to ensure the future value of the
work.
6/8/2015Footer Text 13

14. Teams are Key
• We know: high-performing teams are far more
effective than groups of individuals. Yet
o Few people have experienced true team-based development
o Fewer still have been on high-performing teams
• Working as a team yields both higher-quality code
and people
• Therefore: treat the team as a team, not a group of
individuals.
o Do not “divide and conquer”.
o The team owns the responsibility.
o Hire team players.
6/8/2015Footer Text 14

15. Hire for Passion
• We know: we describe our best employees in terms
of ownership, passion, self-motivation, versatility.
o Yet we often recruit for resumes with bullet points.
• Therefore: recruit for those qualities. Look for
o Github account
o Contributions to open source
o Conferences attended
o List of favorite books
o Blog
o Meetups attended, or organized
o Presentations given
o Concrete evidence of technical curiosity
6/8/2015Footer Text 15

16. Hire the Best
• We know: the best developers have been
documented at 20-50 times more productive than
the worst.
o That means they do more in the first half of January than the least
productive do in a whole year. This is an astounding ratio.
• Therefore: hire the best. If they are 20X better, you
do not have to pay them 20X more. Maybe not
even 2X more.
6/8/2015Footer Text 16

17. Technical Debt
• Technical debt seems to last for about 3 years.
• Generally, the interest is about 200-400%/year
• Therefore: only deliberately incur technical debt if
you think it’s worth 200-400%/year for 3 years.
6/8/2015Footer Text 17

18. Cultural Debt
• Similarly, once a bad culture gets installed, it takes a
long time to fix.
• Therefore: keep on top of the culture and make
sure it evolves the way you want it.
6/8/2015Footer Text 18