My Adventures in Coding

March 15, 2008

Refactoring – Convincing Managers

Filed under: Refactoring,SD West 2008 — Brian @ 11:14 pm

While at SD WEST I was lucky enough to attend a talk by Joshua Kerievsky on refactoring. The following is just a summary of my notes from the talk.

The 5 stages of a software company (They all make the same mistakes)

  • V1.0 – Developers are happy. The team can develop software quickly. No legacy code to read or fix, no maintenance or scalability issues to deal with (yet). All work is on new features so managers see the value in all the work and are happy.
  • V2.0 – Still pumping out new features just as fast as in V1.0. Starting to notice some technical debt. However, at this point it is small enough to not slow development down or be that big of a concern.
  • V3.0 – More focus on just new features. Same focus as in V1.0 and V2.0. However, now the maintenance bugs are starting to flood in. Stability of the product is decreasing. Customers are getting frustrated. Management reacts by adding more support people and creates a team of maintenance developers.
  • V4.0 – The really great talent starts leaving the company out of frustration. Management starts to look at out sourcing for support and maintenance tasks as a solution.
  • V5.0 – Finally, managers call in experts to help fix the issue, which means a great deal of refactoring work. This is paying a great deal of interest on technical debt that could have been avoided if that debt was dealt with on a regular basis (like paying your credit card bill monthly, not once every year or two).

How to get Managers to Understand the Cost of Legacy Code

Explain it in terms of poorly written driving instructions:

  • You spend a lot of time reading the instructions trying to understand them, this is a waste of time
  • So you then try and ask other people if they understand the instructions, each having a different interpretation
  • Now you try and drive there, how many times do you get lost, how much longer does the drive take?
  • If only the instructions were clear and concise, imagine how much time could have been saved

Now imagine how hard it is for a new developer to understand an existing system that is in a similar state as these driving instructions. The root problem is many different styles from many different developers. As a result code gets more and more confusing over time. Continuous refactoring can help mitigate this problem. Refactoring is the ongoing process of making software simple and concise.


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Create a free website or blog at

%d bloggers like this: