On The Economics of Technical Debt

Abigail - (Booking.com)
Programming
Location: Portland 256
Average rating: *....
(1.94, 31 ratings)

On The Economics of Technical Debt

Technical debt is often seen as something that ought to be avoided as
it will lead to problems in the future. And we programmers often jump
at the opportunity to reduce technical debt: we refactor, spend time
writing extensive test suites, and polish the code until it works under
all circumstances. Lots of projects never reach version 1 because there
is always something that can be improved.

But this is not always the optimal way of working in a business. In this
presentation, we will look into scenarios where it may make sense to
collect technical debt. We will show that not gathering “technical debt”
requires investments, and that the answer to questions like “do we need an
automated test suite” or “do we have to spend time refactoring this code”
is not always “yes”.

Abigail -

Booking.com

Abigail has presented on 50+ Perl and academic conferences, in over a dozen countries on four continents. Working in the computing world since the 1980s, Abigail is currently working as a team lead for Booking.com, the worlds leading online hotel reservation company. Abigail has contributed to Open Source for more than two decades.

Comments on this page are now closed.

Comments

Chris Pall
07/24/2012 7:18am PDT

I think we can agree about the following things:

1) When giving a presentation at an OPEN SOURCE convention, do not come and ask for your presentation not to be recorded.

2) While many in open source make money from their projects, their primary motivation is not money. Therefore, this talk, which was primarily centered around convincing developers that their “concerns over code quality are misplaced. The primary concern is revenue generating features”.

Even at a startup company, I have never heard that it’s simply ok to let developers run some local tests, skip code review and deploy.

I come to conferences to improve my development methods and to learn new possibilities. I understand talks like this will happen, but alas, it is unfortunate I had to attend it.

Perhaps Abigail is used to a more captive audience. I recommend next time he not draw attention to his fleeing spectators.

Richard Meneely
07/20/2012 11:13pm PDT

I would like to echo some of the comments by Zach Burke in that I believe this was one of the best and most interesting talks as OSCON. This was the only talk that actually got me to think and question if I am doing things the best way, or simply how I’ve been trained to think.

I walked into the talk expecting to hear how I should always refactor code and how I should constantly be striving to automate testing at every possible opportunity and how we all fail at these. Instead I was pleasantly surprised to hear that the presenter asked people to better understand the tradeoffs of doing so and make those decisions based upon actual value and not simply because we’ve been taught that it is what we should do.

Picture of Chris Busbey
Chris Busbey
07/20/2012 6:42am PDT

I can’t stress enough how disappointed I am that this OSCON speaker stipulated that his talk not be recorded. I want the video as an example of how not to run a software company. Awful, irresponsible policies at Booking.com. These ideas only support the bullshit that is cowboy development and hero worshiping. Pity their developers, don’t use (test) their site.

Picture of Llewellyn Falco
Llewellyn Falco
07/20/2012 5:11am PDT

I couldn’t believe my eyes when I sat down for this session. I have never been to a session that advocated writing code that no one else would understand.

At one point the speaker said don't change the code, because the 1 and only 1 person who works in that section might become confused, as if the only way a section of code could be readable was to have spent time months and months with it.

He then advocated that there was a piece of code that he wrote that was still in production 3 years later. Never been changed, so it must have never “needed” to. It seemed beyond the speakers comprehension that maybe for that code the cost of change was greater than the pain of not changing it, and that this might be different than not needing to change it.

This is the same problem that keeps so much COBOL in production today.

He also said things like “unit tests where too hard to write because everything touched the database” as if he had never heard of the most basic parts of seams or mocks to write code such that everything doesn’t have to touch the database. This is really 101 of unit testing.

On the plus side, I make my living recusing companies where their legacy code has gotten out of control and its cost of maintenance and change has become so high it has ground to a halt. More talks like this at national conferences are sure to keep me well employed for decades to come.

Eric Cantori
07/19/2012 10:40pm PDT

The general point that decisions about paying down tech debt should be ROI based is well taken.

The rest of this talk were excuses for poor programming practices redolent of every disaster I have ever worked on. Copy and paste is OK, unit testing is not worth it because tests break when thing change (duh), project coding standards are pointless because (of course) only you will ever work on that code and on and on.

Really no excuse for this at at conference of this caliber.

Picture of Zach Burke
Zach Burke
07/19/2012 10:07pm PDT

I thought this was one of the best talks at OSCON. Like a distant tidal wave starting far out at sea, I feel this information will someday crash on the shores and be hailed as programmer canon. I felt there were too many coders in the audience that simply aren’t ready to admit the truth that this talk contained.

Thom Williams
07/19/2012 8:33pm PDT

I had much higher hopes. I went in expecting some quantitative data / analysis on what are real and often important software project / architectural management decisions in some situations… there were some decision points but no “economics” in this talk.

Sponsors

For information on exhibition and sponsorship opportunities at the conference, contact Sharon Cordesse at (707) 827-7065 or scordesse@oreilly.com.

View a complete list of OSCON contacts