Lessons learned: refactoring yourself out of business
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Lessons learned: refactoring yourself out of business

  • 808 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
808
On Slideshare
805
From Embeds
3
Number of Embeds
1

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 3

https://eat1-searchindev01.linkedin.biz 3

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Lessons Learned: Refactoring yourself out of business 30/06/10 7:16 PM Share Report Abuse Next Blog» Lessons Learned by Eric Ries WEDNESDAY, JANUARY 28, 2009 Subscribe via email Refactoring yourself out of business Enter your email address: Let me start out by saying I am a big fan of refactoring, the ongoing process of changing code so that it performs the same behaviors but has more elegant structure. Its an essential discipline of good Subscribe software development, especially in startups. Nonetheless, I want to or, add to Google Reader: talk about a dysfunction Ive seen in several startups: they are literally refactoring themselves to death. Heres a company I met with recently. They have a product that has Blog Archive a moderate number of customers. Its well done, looks professional, ► 2010 (35) and the customers that use it like it a lot. Still, theyre not really ▼ 2009 (88) hitting it out of the park, because their product isnt growing new ► December (4) users as fast as theyd like, and they arent making any money from the current users. They asked for my advice, and we went through a ► November (1) number of recommendations that readers of this blog will already be ► October (7) able to guess: adding revenue opportunities, engagement loop ► September (9) optimization, and some immediate split-testing to figure out whats working and whats not. Most of all, I encouraged them to start ► August (8) talking to their most passionate customers and running some big ► July (8) experiments based on that feedback. ► June (7) ► May (8) I thought we were having a successful conversation. Towards the end, I asked when theyd be able to make these changes, so that we ► April (5) could meet again and have data to look at together. I was told they ► March (11) werent sure, because all of their engineers were currently busy ► February (10) refactoring. You see, the code is a giant mess, has bugs, isnt expandable, and is generally hard to modify without introducing ▼ January (10) collateral damage. In other words, it is dreaded legacy code. The Achieving a failure engineering team has decided its reached a breaking point, and is Refactoring yourself out of taking several weeks to bring it up to modern standards, including business unit tests, getting started with continuous integration, and a new Three freemium strategies MVC architecture. Doesnt that sound good? Lean hiring tips I asked, "how much money does the company have left?" And it was Why PHP won this answer that really floored me. They only have enough money to CPI > CPC last another three months. Lessons Learned office hours I have no doubt that the changes the team is currently working on Sharding for startups are good, technically sound, and will deliver the benefits theyve Lessons Learned on Mashable claimed. Still, I think it is a very bad idea to take a large chunk of today time (weeks or months) to focus exclusively on refactoring. The fact Happy new year that this time is probably a third of the remaining life of the company (these projects inevitably slip) only makes this case morehttp://www.startuplessonslearned.com/2009/01/refactoring-yourself-out-of-business.html Page 1 of 8
  • 2. Lessons Learned: Refactoring yourself out of business 30/06/10 7:16 PM company (these projects inevitably slip) only makes this case more ► 2008 (59) exaggerated. Labels The problem with this approach is that it effectively suspends the agile (8) companys learning feedback loop for the entire duration of the refactoring. Even if the refactoring is successful, it means time audio (3) invested in features that may prove irrelevant once the company case study (2) starts learning again. Add to that the risk that the refactoring never continuous deployment (10) completes (because it becomes a dreaded rewrite). customer development (11) Nobody likes working with legacy code, but even the best engineers engagement (3) constantly add to the worlds store of legacy code. Why dont they events (35) just learn to do it right the first time? Because, unless you are working in an extremely static environment, your product five whys root cause analysis (6) development team is learning and getting better all the time. This is hiring (5) especially true in startups; even modest improvements in our iPhone (3) understanding of the customer lead to massive improvements in developer productivity, because we have a lot less waste of lean startup (12) overproduction. On top of that, we have the normal productivity listening to customers (10) gains we get from: trying new approaches on our chosen platform to minimum viable product (4) learn what works and what doesnt; investments in tools and learning how to use them; and the ever-increasing library of code we are able product development (19) to reuse. That means that, looking back at code we wrote a year or recommended reading (5) two ago, even if we wrote it using all of our best practices from search engine marketing (5) that time, we are likely to cringe. Everybody writes legacy code. slides (11) Were always going to have to live with legacy code. And yet its sllconf (10) always dangerous to engage in large refactoring projects. In my split-test (5) experience, the way to resolve this tension is to follow these Rules for Refactoring: startup visa (7) Test-driven development (8) Insist on incremental improvements. When sitting in the midst of a huge pile of legacy code, its easy to despair of video (8) your ability to make it better. I think this is why we naturally virtual goods (2) assume we need giant clean-up projects, even though at some level we admit they rarely work. My most important lesson in About Lessons Learned refactoring is that small changes, if applied continuously and Welcome to Lessons Learned by with discipline, actually add up to huge improvements. Its a Eric Ries. Want to learn more about version of the law of compounding interest. Compounding is me? Try About the author. Trying not a process that most people find intuitive, and thats as to learn more about lean startups? true in engineering as it is in finance, so it requires a lot of See Four Myths about the Lean encouragement in the early days to stay the course. Stick to Startup or The lean startup. some kind of absolute-cost rule, like "no one is allowed to Get in touch: spend more time on the refactoring for a given feature than the feature itself, but also no one is allowed to spend zero Twitter time refactoring." That means youll often have to do a Email refactoring thats less thorough than youd like. If you follow Facebook the suggestions below, youll be back to that bit of code soon enough (if its important). Linkedin Only pay for benefits to customers. Once you start making lots of little refactorings, it can be tempting to do as many as possible, trying to accelerate the compounding with as much Additional resources refactoring as you can. Resist the temptation. Theres an Startup Lessons Learned, infinite amount of improvement you can make to any piece ofhttp://www.startuplessonslearned.com/2009/01/refactoring-yourself-out-of-business.html Page 2 of 8
  • 3. Lessons Learned: Refactoring yourself out of business 30/06/10 7:16 PM Startup Lessons Learned, infinite amount of improvement you can make to any piece of All Seasons: Every post code, no matter how well written. And every day, your from the blog, in one 600+ company is adding new code, that also could be refactored as page PDF. soon as its created. In order to make progress that is Startup Lessons Learned meaningful to your business, you need to focus on the most season one: Every post critical pieces of code. To figure out which parts those are, from the blogs first year you should only ever do refactoring to a piece of code that in print form. you are trying to change anyway. Startup Lessons Learned for For example, lets say you have a subsystem that is buggy and Kindle hard to change. So you want to refactor it. Ask yourself how Startup Lessons Learned - the customers will benefit from having that refactoring done. If conference. April 23, 2010 in San the answer is they are complaining about bugs, then schedule Francisco. time to fix the specific bugs that they are suffering from. Lean Startup Wiki - including a Only allow yourself to do those refactoring that are in the complete list of local meetups areas of code that cause the bug youre fixing. If the problem and meetup organizers. is that code is hard to change, wait until the next new feature Lean Startup Circle - a mailing that trips over that clunky code. Refactor then, but resist the list of dedicated and helpful urge to do more. At first, these refactoring will have the entrepreneurs. Bring your effect of making everything you do a little slower. But dont questions. just pad all your estimates with "extra refactoring time" and make them all longer. Pretty soon, all these little refactorings FeedBurner FeedCount actually cause you to work faster, because you are cleaning up the most-touched areas of your code base. Its the 80/20 rule at work. @ericries on Twitter Only make durable changes (under test coverage). Theres no Terrible iPhone 4 bug today: gets point refactoring code if its just going to go back to the way stuck in an endless loop with it was before, or if its going to break something else while hotel wifi that redirects via SSL. youre doing it. The only way to make sure refactorings are Had to reboot. about an hour ago actually making progress (as opposed to just making work) is to ensure they are durable. What I mean is that they are @zburt afraid not, but sounds somehow protected from inadvertent damage in the future. like a great event about 9 hours ago The most common form of protection is good unit-test more updates... coverage with continuous integration, becaus that makes it Facebook Fans almost impossible for someone to undo your good work without knowing about it right away. But there are other ways Startup Lessons that are equally important. For example, if youre cleaning up Learned on Facebook an issue that only shows up in your production deployment, Like make sure you have sufficient alerting/monitoring so that it would trigger an immediate alarm if your fix became undone. Startup Lessons Learned has 676 fans Similarly, if you have members of your team that are not on the same page as you about what the right way to structure a certain module is, its pointless to just unilaterally "fix" it if they are going to "fix" it right back. Perhaps you need to hash Chris Eric Mike Adam out your differences and get some team-wide guidelines in place first? Share what you learn. As you refactor, you get smarter. If Jenny Linda Keren Jeff thats not a team-wide phenomenon, then its still a form of waste, because everyone has to learn every lesson before it starts paying dividends. Instead of waiting for that to happen, Recent & Upcoming Events make sure there is a mechanism for sharing refactoring lessonshttp://www.startuplessonslearned.com/2009/01/refactoring-yourself-out-of-business.html Page 3 of 8
  • 4. Lessons Learned: Refactoring yourself out of business 30/06/10 7:16 PM make sure there is a mechanism for sharing refactoring lessons 2010 with the rest of the team. Often, a simple mailing list or wiki I am experimenting with using is good enough, but judge based on the results. If you see the Plancast to track my 2010 event same mistakes being made over again, intervene. schedule. Take a look and let me know what you think. Practice five whys. As always with process advice, I think its essential that you do root cause analysis whenever its not 2009 show working. I wont recap the five-whys process here (you can read a previous post to find out more); the key idea is to refine all rules based on the actual problems you experience. Amazon Symptoms that deserve analysis include: refactorings that never complete, making incremental improvements but still feeling stuck in the mud, making the same mistakes over and over again, schedules slipping by increasing amounts, and, of course, month-long refactoring projects when you only have three months of cash burn left. Back to my conversation with the company I met recently. Given their precarious situation, I really struggled with what advice to give. On the one hand, I think they have an urgent problem, and need to invest 100% of their energy into finding a business model (or another form of traction). On the other, they already have a team fully engaged on making their product architecture better. In my experience, its very hard to be an effective advocate for "not refactoring" because you can come across as anti-quality or even anti-goodness. In any event, its enormously disruptive to suddenly rearrange what people are working on, no matter how well- intentioned you are. I did my best to help, offering some suggestions of ways they could incorporate a few of these ideas into their refactoring-in-progress. At a minimum, they could ensure their changes are durable, and they can always become a little more incremental. Most importantly, I encouraged the leaders of the company to bring awareness of the business challenges to the product development team. Necessity is the mother of invention, after all, and that gives me confidence that they will find answers in time. Like Be the first of your friends to like this. Labels: agile, product development, Test-driven development 11 comments: William Pietri said... Great post, Eric. Back when it first came out, Fowlers book Refactoring was what got me into the Agile world, so it holds a special place in my heart. But I agree completely: not a week should go by without visible and hopefully released progress toward satisfying real users.http://www.startuplessonslearned.com/2009/01/refactoring-yourself-out-of-business.html Page 4 of 8
  • 5. Lessons Learned: Refactoring yourself out of business 30/06/10 7:16 PM satisfying real users. The only way a team can judge the value of particular refactorings is in a context where the primary focus is on frequently delivering value. Otherwise, the opportunity for redesigning is infinite. In the same way that product managers must be ruthless about product prioritization, developers should be ruthless about choosing which bits of code are really worth polishing right now. My one counterbalancing piece of advice is that the code base should get a bit better each week, rather than a bit worse. The pressure to release should always be present, but never so strong that technical debt increases over time. January 29, 2009 12:08 AM Mahesh said... [okay my comments were eaten first time around] Excellent post. The rigor of engineering teams needs to be balanced with the realities of the commercial environment. Code that Fowler would be in awe of is useless if it does not generate revenue. Product and engineering managers will be better off if they adopted a iterative approach to refactoring. Refactoring at a large scale has similar risk characteristics as re-writing an application. And we all know what the success rates of rewrites are! January 29, 2009 12:48 AM mooders said... I would also suggest, and the engineers will almost certainly hate this suggestion, that the decision-maker asks for hard metrics to justify the refactoring effort in the first place. I have often been told by programmers that the project needs to slip by x weeks or months because the code needs to be refactored. When asked how they know, the answer is invariably defensive in tone and vague in its explanation. Writing this, I can recall four occasions when the hard metrics (gathered at my request by members of the QA team) proved the code was indeed performing sub-optimally - but only at the microscopic level, e.g. cpu utilisation running at 3% instead of 2%. In each of those four cases, it was cheaper and faster (by several orders of magnitude) to beef up the hardware. Only one occasion was a substantial rewrite justified based on performance metrics. And in that one case (hard to pull a trend from one data-point, I know, but this is indirectly substantiated by anecdotal evidence from other projecthttp://www.startuplessonslearned.com/2009/01/refactoring-yourself-out-of-business.html Page 5 of 8
  • 6. Lessons Learned: Refactoring yourself out of business 30/06/10 7:16 PM substantiated by anecdotal evidence from other project managers and my own programming career) the rewrite over- ran by almost half, principally because the senior programmers recommended a course of action based on incomplete knowledge. I do hate it when they call it Computer Science :) January 29, 2009 2:44 AM Travis said... Im in this exact position with my startup, industrialinterface.com. We had some work done by an external group that isnt up to snuff (from my POV), and now we need to fix it AND move forward. Fortunately, my co-founders are also engineers and understand the need for some of the stuff I do. Weve reached a middle ground -- they know that I have a tendency to over-engineer and "beautify" code. Im honest when Im doing the "unnecessary" re-factor, and the business guys decide if its worth the time. One caveat: it can indicate good things about a dev team if they want to refactor constantly. It means theyre embarrassed about their past work, which means 1) theyre constantly getting better, and 2) they take pride in the quality of their work. IMO, those two reasons are enough to justify some of the refactoring time (although 1/3 of the businesses TTL seems like a bad plan...) January 29, 2009 11:13 AM William Pietri said... @mooders: Note that refactoring is improving the internal design, not the performance or other aspects of the functionality. The goal of refactoring is to make it easier to do future development. There are some metrics that may help with that, but its something where you mainly need to trust the professional judgment of your senior developers. January 29, 2009 1:11 PM Paul W. Homer said... I seen this in practice too, a company that reaches its end with a better product, but not enough business. Its a problem with their priorities. You have to solve the biggest problems first, and unfortunately for many techies, the business ones often trump the technical ones. Refactoring is a long-term strategy, it makes no sense if you cant survive long enough to acquire the benefits of the work. Once next year becomes a possibility again, then it should gohttp://www.startuplessonslearned.com/2009/01/refactoring-yourself-out-of-business.html Page 6 of 8
  • 7. Lessons Learned: Refactoring yourself out of business 30/06/10 7:16 PM Once next year becomes a possibility again, then it should go back onto the table (too many short-term choices are as bad as too many long-term ones). Balance is important. Paul. January 30, 2009 7:52 AM Mathew Johnson said... Eric - There is definitely a business/marketing analog to exactly this situation that happens a lot too. The long refactor of business model and market research (as opposed to more organic iteration) is just as bad. Would love to read a post from you about that side of things. -Mathew www.blist.com January 30, 2009 9:55 AM Toby Ho said... Nice post. If you have a mess that big, you have to go about the refactoring bit by bit. Everything in moderation. January 30, 2009 11:59 AM Leo Richard Comerford said... Sounds like creeping elegance. January 31, 2009 2:05 PM Anonymous said... In my opinion there are too many examples where people in the industry use the word "refactor" to justify their work, but what they really do is re-enginering, redesign, unstructured/informal code cleanup or even complete rewrites. February 17, 2009 12:32 AM Brett Veenstra said... There does come a time when code debt is literally killing a companys cash flow. Little refactoring sessions are certainly a good step and sometimes the business needs to realize they have leveraged their code base as far as it can take them. This is usually exacerbated by zealous sales persons who oversell the features, or even more typical, promise completely new features. @mooders - Performance is not the only metric deserving analysis of a refactoring effort. You should take note at the amount of effort estimated by your engineers to implementhttp://www.startuplessonslearned.com/2009/01/refactoring-yourself-out-of-business.html Page 7 of 8
  • 8. Lessons Learned: Refactoring yourself out of business 30/06/10 7:16 PM amount of effort estimated by your engineers to implement new features and/or squash bugs. If those estimates are going up, you already have serious code debt. A healthy code base is one where you can add features easily over time. February 25, 2009 1:46 PM Post a Comment Comment as: Select profile... Post Comment Preview Newer Post Home Older Post Subscribe to: Post Comments (Atom)http://www.startuplessonslearned.com/2009/01/refactoring-yourself-out-of-business.html Page 8 of 8