When and why should you refactor code?

One of the tenets of the agile methodology is the concept of "re-factoring", or the "disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior".  I consider an attitude that favors re-factoring to be a very important trait of a good software engineer, and vital to the maintenance of quality software.  But, not always.


The "Engineering Tax"

In my team, we call re-factoring the "engineering tax".  That is, we won't always offer up all of our coding bandwidth strictly for the quickest route to the release of new features.  Sometimes we have to take a step back and restructure things for the longer term.  As engineers, we know the code best and it's up to us to recognize these needs when they arise.  We have to tell product managers that it will take longer this way, which means we better have a good pitch as to why it's necessary.

It can be a hard sell, because product managers want features that generate revenue.   If you're spending time on something whose value is not user-facing, they probably don't care about it.   Some of the arguments I make to sell an extended development cycle due to re-factoring are as follows:

• If we change the underlying data-structures, it will enable a simpler UI.  Simpler is always better.
• When you want "the next feature" in this area of the product, we'll be able to build it faster.  In fact, we've already thought about the "next feature" you've been considering, and we've realized that this restructuring enables it.  So time now has a direct payback against time later.
• Our QA for this feature will be shorter, because with less complex code that more closely resembles the business logic, we will make fewer mistakes and there will be fewer bugs.
• If we're being asked to build something that is "like something else we have, but a little different," we need to combine the code for the two features and share it between them.  This will prevent two parallel implementations going forward, and cut down long-term regression risks.
• We can build unit tests for the new code, where there may not have been any for the old code.  More QA savings and regression risk reductions.
• Perhaps our re-factoring plan includes a performance improvement...wouldn't that be nice?

In short, you're trying to sell a lower overall long-term cost due to re-factoring.  It will be difficult to prove ahead of time, especially to a product manager without an engineering background, but hopefully over time you'll be able to look back on some success stories from re-factoring and some failures from when it wasn't done.


When NOT to re-factor?

But like anything, the attitude for re-factoring can be taken too far.  There are right times and wrong times...right reasons and wrong reasons.  Here are some thoughts on when you should re-consider whether a re-factoring project is a good idea, at least right now.

Have you taken the time to thoroughly understand the existing design?
Some engineers have a default attitude that if it's existing code written by someone else, it's therefore bad code and needs to be re-written.  Often times, they're really just facing style differences.  There's more than one way to write good code and you owe it to your forbears to understand their intentions before you throw their code out the window.  In fact, if you decide to do this new thing in a different way, you could be harming overall code quality by introducing yet another "style" into the code and thereby confusing developers that come after you.  The worst travesty on earth is an "improvement" that makes things worse!

What are the product stresses at the moment?
Even as an engineer with a strong re-factoring ethic, you need to respect the point of view of product management.  They may be facing a revenue-impacting deadline that is just around the corner.  They may have made promises to customers.  If you know you can deliver the feature without the engineering tax, and your product manager is making a strong case for it, you need to listen.  You need to consider time pressures in your decision.


Is the re-factoring huge?
If you're wanting to charge an engineering tax of, say, 50%, meaning that half of your coding time is going towards re-writing with no end-user value, then it might not be worth it.  You better be taking a long hard look at the long-term benefits and making every attempt to quantify them so you can justify the cost.  In general, the higher the tax, the more justification is needed.  In my product, we've done a lot of re-factoring over the years, but we've also left a ton of ideas un-done, because the costs simply weren't warranted.

Is it close to a release?
Re-factoring can introduce risk in a code base.  It's more "new" code, and therefore it's more "untested" code.  If you're coming close to a release, you can't afford to introduce such risks, and you should consider making your changes in a code branch with a longer horizon before it ships.

Are you just being a perfectionist?
I've seen some developers who take the attitude to the extreme.   They re-write code they wrote yesterday, or next month they re-write thousands of lines they wrote last month.  I appreciate their high standards in their work, and as an engineer I can definitely relate to the nagging feeling that "I can still make this better".   But this has to have its limits.  Code needs to ship or it is useless to the world.  You need to reach a point where your new ideas go on the engineering backlog and you focus instead of stabilization and shipping.

In summary, the decision to re-factor or re-write code is a subjective one.  It can be difficult to quantify the costs and benefits, and many different engineers will have different opinions.  The factors above are some things to consider.

In my current case, I work on a very old application (10 years), and I consider re-factoring to be critical to its long-term health and code quality, so I generally support and encourage developers to re-factor.  But I also keep them in check with the questions and considerations above, and my vote is not always "yes" to the engineering tax.

What about change ideas from others?

In my last post I talked about how to instigate process change, which is something managers should always be thinking about.  Now I'll take a look at it from another angle, which is: how do you handle ideas for change that come from others, especially those on your team.

You should consider yourself lucky if you have members of your team that think this way.  Nobody is likely to promote a change that they think will be detrimental.  They probably have good intentions and are trying to improve things.

The Scrum process teaches the "sprint retrospective", where at the end of each sprint, the team talks about how things went, and folks are encouraged to suggest how to make things better for the next go-around.  In my teams, some people are not very shy.  I've been a part of over 100 sprint retrospectives, and there's always someone with something to say in each one.

As a manager, I have a unique role in these conversations, in that my reactions to people's comments is very important.  The individual contributors with new ideas will look to me to implement them.  Some ideas will be great, out-of-the-box improvements (like: "let's automate this or that mundane task we do every day"), while others will just be new time sinks that aren't all that practical (maybe: "I don't like the architecture...we need to rewrite the app from the ground up").   Other times you'll just hear complaints in a retrospective, and you'll be the guy expected to come up with ways to make it better.  My favorite complaint (sarcastically speaking) is "people aren't communicating enough...".  Ok, so now what?


When you're in agreement...

The easy situation is when someone makes a suggestion and everyone, including you, agrees.  Ya, let's do that!  It's important, is valuable, and we can do it immediately.  The only problem you might have is whom should get the implementation task?  Well that's easy too.  I usually kick it back to the person with the idea.  If they really believe it, they should be the one to champion it.  Buy-in is already there.  Done.


When you're not in agreement....

Disagreement about a new idea might be your own, or it can come from others in the team.  But the handling for the manager is the same.  You should make sure my initial reaction is always positive.  I always try to start by voicing appreciation for the idea and the positive effects it could have, whether I like it or not.  Then its time to explore the idea further.

The most important question, and the guiding principle for this whole blog post is...

What problem are we trying to solve?  

As I said in my last post, I believe we should always be looking for ways to change or improve, but I also believe in "don't fix what's not broken."   Let's say, for example, someone suggests using a cool new app that does a virtual scrum board on an iPad, where you can drag sticky notes across the screen as you pass around the iPad in the daily standup.  Sounds cool, right?  Let's buy iPads and start doing this!  Or not.  What problem are we trying to solve?  Seriously, what real problem does your team have that this solves for you?  If you can't answer that clearly and easily, it's not worth making the change.

Once you know what problem you're trying to solve, now you have to examine the merits of the proposed solution.  Does it solve the problem long-term?  What is the cost and resources required to implement it?  What is the priority relative to other things going on?  What other ways are there to solve the same problem?

This might sound like a naysayer who's just looking for ways to say "no" to the idea.  That's not a very positive attitude, is it?  Well, no its not....and yes it is.  It depends.  Its all about the initial reaction being positive, and the subsequent considerations that lead you a decision.  If your initial reaction is always "no", you've started out all wrong, and you'll stifle future suggestions and damage team morale.  But, if you're ultimate answer is still "no", even after showing due consideration for the idea's merits,  then folks are likely to respect your decision much more.

Choose your battles

A final consideration for a manager when facing an idea that meets with disagreement is what you might call "choose your battles".  If someone has an idea you're not necessarily comfortable with, but their intentions are good and they seem really motivated, then you have to decide if nixing the idea is a good call, even after considering and discussing all its merits and pitfalls.

The point here is that someone had the idea, and they will feel good if it gets adopted.  You see flaws in the idea, and you would never suggest it yourself.  But you want people to feel good, so you should let them pursue their idea, right?  Sometimes.

This is where your own confidence comes into play.  If you're going to put your foot down, you darn well better know that you're right, because there will be a large morale cost to saying no if you're not able to convince others with reasoning.  If you're not sure of yourself, well, maybe you're wrong.  Maybe the idea will be a winner.  You'll also earn a lot of goodwill by letting go of your objections and empowering your employee.


In summary, the "happy place" is when your team is full of ideas, everyone loves them, they're all willing to implement them, and you have the resources available to do so.  I haven't discussed that much here.

But things are less rosy...when you have more ideas than resources, or ideas meet with disagreement, that's where your management skills have to kick in to help the team figure out when to say "yes", "no", or "maybe later".

How do you make change happen?

As a manager, part of my responsibility is to be an instigator for process change.  That's not to say I believe in change for change's sake.  Far from it actually.  I'm a firm believer in "don't fix what's not broken".  But at the same time I also believe there's always room for improvement, and if you're not going for it, you're stagnating.  If fact, you are even likely to regress and fall back into bad habits.

In this post I'll talk about change ideas that come from you, the manager.  In the next, I'll talk about ideas that come from those on your team.


Changes I Want to Make


Suppose I have a great idea for a process improvement.  As the manager, all I have to do is tell my team to do it, and its done, right?  Heck no!

The last thing I want is to be seen as a dictator who makes decisions unilaterally and imposes more work on people.  "More work" is exactly the negative connotation your idea will receive if it's pushed on people without their buy-in.

A better approach I like to use to socialize the idea over time.  First, the light bulb turns on in your head.  Then, spend a while thinking about it on your own.  Then, start looking for opportunities to sell it.  If your team does scrum, it might be in a sprint retrospective, where people are noting a problem that your idea solves.  Another great time is during one-on-one conversations, or over lunch, etc.  Over lunch is a particularly good time to share, because your listener is likely more relaxed and willing to hear you out.  They're not feeling rushed to move on through their work day.

As you do this, you'll get feedback to help you improve and develop the idea.  Perhaps that feedback will come from naysayers.  All the better.  You can use this feedback to improve it, and come back later to sell it again with their input taken into account.  Socializing your idea before mandating it can only help your cause.

The (in my view, acceptable) down side of this technique is that it requires patience.  It might take weeks, months, or even years!  Your idea might be some really big change that meets a lot of resistance, and there's no way you're going to make it happen overnight.

Let's say, for example, that you want to create a culture of Test Driven Development in a team that is accustomed to black box testing.   Your developers feel that TDD takes too much time, and your QA team feels threatened by it, or doesn't believe it produces a better result.  If you simply say "From now on we're doing 100% TDD" you'll surely be met with revolt.

Think baby steps.  Maybe start just by e-mailing online articles about your idea, so folks can see that it works elsewhere.  Come up with a smaller idea that's easier to sell and heads you in the right direction.  Make it happen, and then celebrate the results.  You could even start "doing it yourself" to set an example that others will follow.

Another technique is to build a base of allies gradually.  If you have one person on your side, try to get that person selling the idea for you.  If the naysayers hear it from more than one source, they're more likely to warm up to the idea.

And lastly, I hate to say it, but if you work through all these techniques with diligence and you're still not able to make your change happen, then maybe it shouldn't happen.  Simply put, if others don't buy in after patient and persistent encouragement, then maybe there's a flaw in the idea.  Putting your foot down and insisting on it will only make you unpopular, and them unhappy.

Describe some of your role models for software management.

When I think back to my days as an individual contributor engineer, I think about the past managers I've had, which of them I want to emulate, and which I saw as examples of "how not to be" as a manager.  Three past managers come to mind as people I have learned good things from.

Edan

Early in my career, I was hired by Edan into what would be my first startup experience, having come from a big company environment.   I enjoyed working with Edan for several reasons.  For one thing, he was an extremely fast thinker.  He knew how to run a meeting and always had his finger on both where the conversation was going and where it needed to go.  He was very quick to jump in and keep us on track.

This showed through in one-on-one conversations as well.  What I remember about those was that there was always a sense of urgency in his tone.  He really made me believe that my work, and the pace at which it was done, was critical to the company's success.  This helped me stay motivated to work hard.

And one other thing I remember about Edan was that he helped me learn about my own strengths. There was one time when a key engineer resigned and I had to take over his rather complicated code.  After a couple weeks, I had things under control and Edan praised me for being "great at figuring out complex new code written by someone else."  He was right, I am pretty good at that.

Mark

A few years later, I met Mark at another startup.  I'll never forget that our relationship got off to a great start in the job interview.  After interviewing with several engineers, he came in for his turn with me.  Within five minutes he said "I'm not here to interview you, I'm here to hire you".  He had already gotten feedback from the other interviewers, and that plus our five minutes together was enough for him.  Interviews are stressful for the candidate, and so it felt great to hear this.  Right away I knew I wanted to work hard for this guy to return the favor.

We worked together for a couple years at this company.  Over this time, the mutual respect grew even stronger.  Like Edan, Mark recognized things I was good at, praised me for them, and gave me even more of that type of thing to do.  I wanted to work hard because I knew he appreciated it.  I wanted to be forthright and not bullshit him, because I knew he trusted what I had to say.

Mark was not what I would call a highly technical manager, in that he didn't write code himself and hadn't for a long time.  He was a people person with a technical background, which was enough for him to understand what engineers had to say.  He treated me like a peer, and often asked my advice on technical decisions he needed to make.  I really liked that.

Tim


A final role model boss from my past is Tim, but for different reasons that Edan and Mark.  Tim was a perfectionist, and everything was important to Tim.  In my management experiences, I sometimes want to shy away from challenging people to strive for perfection, thinking if I push them too hard they will hate me.  But then I think back to Tim, and the results he obtained by doing so.  Tim wasn't afraid to push me, even to the extent that it might make him unlikable.  Oddly enough, I liked that.

We were building and supporting an application with several hundred thousand users, and when things went bump in the night, Tim wouldn't let us sweep anything under the rug.  Let's say a server crashed or a bug turned up that had a workaround....As much as I would want to just restart the server or workaround the bug and move on, Tim would insist on digging until we found and fixed the root cause so it would never happen again.

In a similar vein, Tim taught me that "edge cases happen".  You can't build a quality product by ignoring your handling of edge cases.  If you do, you will hate your life down the road when they happen and you have to deal with them as a support case.

Tim also helped me make my own career transition from the technical ladder to the management ladder, by being the first one to tell me that he valued my management skills.  Actually, the way he put it was that he valued my management skills more than my technical skills.  At first I took this as a put-down, but gradually came to realize that a technical guy with management skills is more of a rare breed than just a strong technical guy.  At that point I knew where I was headed.

Anti-role models


In general I think I'm a pretty easy-going guy.  I don't get peeved very often and I usually see the silver lining in every cloud.  Because of this, I have a pretty good relationship with most former managers and co-workers.

But a blog post about role models wouldn't be complete without some comments about traits I don't want to emulate as a manager.    I won't name names here, but I've had a couple managers in the past who really made me want to say "F*$% You!".

In most cases, the situations have been ones where the person tries to flex their authority without a human touch and consideration for my feelings.  I remember one in particular where I spent some extra hours implementing a feature that wasn't part of the requirements, but it made perfect sense to me that it was useful and would be cool.

When my manager heard about it, she called me into her office and sternly scolded me.  "Don't you ever do anything like that again without my permission!".  It was so stern I thought I was about to get fired.  And all for something where I was trying to go above and beyond!

Another anti-role model boss was a guy who was just simply never there.  He left me completely on my own for several months while he traveled, schmoozed other execs, and paid attention to anything but the engineers who worked for him.  Then at review time, he gave me a poor review for not having done the things he wanted done, even though he had never actually told me what those were.

So in summary, my role models from the past have had a big influence on how I manage my teams today, and if folks that work for me say any of the same things that I've said here, I would be very proud.  In short, I would hope they would say I respect them, trust them, appreciate them, and push them.  And also that I am very organized, efficient, and I know what I'm talking about.

And, some of them have....

What's the most important responsibility for a software manager?

I'll probably ask and answer this question many times over the course of this blog because, as I've said, there are many very important aspects to software management.  But for today, I'll say "the most important responsibility is: recruiting."

I used to work for a guy who would say "Hire people who are smarter than you" and "fill your team with superstars and your job will be easy."  I couldn't agree more, but man, what a challenge this is!

As a manager, your job becomes less about your own coding skills and more about your ability to leverage your team.  Simply put, you are responsible for more than you can do yourself, and the quality of your help is of paramount importance.

Recruiting is a huge time sink, and often feels like a burden because we all have "real work" that needs to get done.  But its much worse to recruit poorly and end up with engineers that don't produce good results or need too much hand-holding.  These things become a long-term (and often hidden or intangible) time sink, whereas the recruiting burden is only temporary.

So when I'm in recruiting mode, I maintain a couple key principles:

1. Invest a lot of time, especially in preparing for the interview
2. Keep your standards high...don't settle!

Invest the time

Strategies for the interviewer are a topic for another post, although Joel Spolsky's article is a good start when it comes to good advice.  The point I want to stress here is that interviews are an extremely brief opportunity to get to know someone well enough to make the hiring decision.  You had better make every second of the end-to-end interview process count.


To that end, I always do the following...

• Write a concise but detailed job posting.   Think a lot about words and style and how it will attract the type of person you're looking for, as well as scare away the ones you don't want anyway.
• If you have a recruitier on the front lines, give them a list of pre-qualification questions and insist on seeing a write-up with the answers before you'll consider a candidate.
• Read every resume thoroughly (until you can safely conclude "no thanks").  I don't buy the old adage that a hiring manager only spends 30 seconds on a resume.  I spend a good five minutes or more.
• Treat every candidate differently.  They all have unique histories, strengths, and weaknesses.  A boiler plate set of questions won't give you as much info as questions you tailor based on what you already know about the candidate.
• Prepare for the phone screen, for at least half the time of the phone screen itself.  You don't want to get stumped by the awkwardness of the first encounter and waste that time.  You should have a script going in that is tailored to the uniqueness's of the individual.   Ask them questions about their resume, know what you want to hear, anticipate the responses and have follow-up questions prepared, so that no line of questioning is wasted.
• Do the same for the interview itself:  Prepare.  I have a library of several dozen questions I am constantly revising.  There's never time to ask them all, so before each interview I read through it and pick the ones that are best for this particular candidate.
• Make sure your interview team all does the same.  You may only have 45 minutes with this person, but they'll probably spend 4-5 hours or more in the total interview.  If any of that time is wasted by too many softball questions from inexperienced or ill-prepared interviewers, your risk of a bad decision is increased.

Keep your standard's high

I agree again with Joel here:  "If there's any doubt, say no."   You may feel that you really want to be done with recruiting and get back to developing product, and hence be tempted to compromise.  You may see some really positive attributes of the candidate, but "just one red flag".  But imagine if that red flag turns out to be the dominating attribute of the candidate....  Sure, you've lost a couple hours on this person so far, but if you hire them you'll be regretting it for months or years to come.


In writing this post I thought of many aspects of recruiting and interviewing worth discussing, but I'll have to save the rest for later posts.  The bottom line for today is:  Recruiting is serious business.  Spend the time to do it right!

How did you make the transition from software engineer to manager?

Like most career-minded folks, I've never been willing to say "I'm happy where I'm at, and I'm not interested in further career growth". With that in mind, I've had to constantly examine my limits, my talents, and my passions to figure out my direction.

My limits: I love Computer Science. I got my BS and MS degrees in Computer Science. But I don't identify myself as a "Computer Scientist." That, to me, is a much more intense title. I don't have the patience or the mental capacity to solve the hardest problems in my field. I find complex problems like search algorithms, frameworks, or massive scalability to be intellectually fascinating, and I love learning how they were solved, but I'm not the guy who's going to solve them myself. This is why I chose not to follow a purely technical ladder beyond the level of Senior Software Engineer, or go for a PhD.

My talents: What I bring to the table is a healthy mix of technical and architectural skills coupled with organization, communication, and interpersonal skills. I have a strong sense of the "keep it simple" design philosophy, and I'm unlike many engineers in that I see value in and am good at writing clear specs, diagrams, e-mails, plans, and other forms of engineering beyond code. As I like to say "Even a simple e-mail has a user experience that needs to be considered." Also, over time, I've gotten good at paying attention to more work going on around me, but at a higher level. This is a key function of a manager, but not so much a requirement for an engineer.

My passions: I a nutshell, my passion is for seeing ideas turn into applications in an elegant way. As an engineer, I got to do just that pretty much on my own, and it was rewarding. But I was often frustrated that the coding process just took too long. As a manager, I get to do it with leverage. I get to be involved in more projects coming to fruition. As long as I'm involved, I don't feel the need to be the actual coder. Quite often I'm heavily involved in conceptualizing requirements and creating high level design (like, for instance, the data model), but then leaving the coding to one of my engineers.

Anyhow, to answer the question, my transition to management happened in my current job, where I hired on as an engineer six years ago and gradually became more and more of a manager. Yes, there was a specific moment early on when my job title changed, but the mental transition was much more gradual, and in some sense is still not finished. With a team size that has grown from 2 to 9, my hand was somewhat forced, and I've had to learn to resist the inclination to just "do it myself." Its been a good learning experience.

At one point a couple years in, my boss said to me point blank "I value your management skills much more than I do your technical skills." That was a real eye opener, since at that point I still identified myself as an engineer, and a good one at that. It was hard not to take it as a put down.

But I've come to realize that good engineering skills are a required part of a bigger package that makes a good engineering manager. At this point in my career I'm cultivating the rest of the package.

Tell me more about this marbles analogy...

Sure. And please note its not that I'm calling the folks on my team a bunch of marbles. Rather, the marbles are the issues a manager has to deal with every day. The point is, there's no focus on one single thing, like there is for an engineer. A manager has to be able to deal with a little bit of everything, and context switch almost constantly. One moment you're advising product management on the feasibility of a new feature, and the next you're deciding if a bug should be fixed or deferred, or being asked for advice on a topic you may know little about. Then, you've got recruiting to do, performance reviews to think about, and perhaps an action item or two you took in your last meeting. Sometimes you're reacting to a fire, and other times you're thinking proactively about change. For the manager, responsibilities are all over the map.

For the engineers that you manage, it should ideally be the opposite. Their job is to take on a coding project and get deep into the weeds with it. The more minutiae and boring (in their mind) meetings you can shield them from, the more the good engineers will thank you, and the more productive they will be. They don't want to be discussing the requirements...they want to be coding them.

If I were to title a different blog about the mindset of an engineer, it might be called "Getting the real work done." In fact, letting go of that mentality, that feeling of "I'm not being useful unless I'm coding," was one of my biggest struggles when I transitioned into management, but that's a story for another post.