10 ms·

Why you should never ask permission to clean up code.

160 points by jakedahn 16y ago

sdizdar 16y ago
Simple rule of development: You should always leave code in better shape than you find it.
- shaggyfrog 16y ago
  Sounds like a hacker's spin on Dan Savage's campsite rule. https://secure.wikimedia.org/wikipedia/en/wiki/Savage_Love#.22Campsite_rule.22 https://secure.wikimedia.org/wikipedia/en/wiki/Savage_Love#....
cdevroe 16y ago
Thanks for submitting this jakedahn! If anyone has any questions, I'm around to answer them.
boyter 16y ago
This is something that took me 2 years or so to learn. One day I realised nobody was really looking at my timecards in depth so I started allocating extra time to things and using the extra time to fix the things I thought needed fixing. Once I started delivering on this I showed my manager who agreed that it was a good use of time. I was given free reign to fix anything I felt would add maximum value, provided the bug fixes continued to be delivered without any major compromise. Since that time I have refactored quite a few of our codebases; added unit tests, fixed some build processes, improved performance and generally feel happier at work for getting things done that are important to me. Dont get stuck in constant bug fix mode would be my suggestion. If you cant get approval to fix things then change jobs because bug fix after bug fix is depressing and will bring you down.
- cdevroe 16y ago
  This is awesome.
  - stanleydrew 16y ago
    That's what the up arrow is for.
    - famousactress 16y ago
      Sure, but considering this is the author of the article we're commenting on, I think an exception is reasonable here. I'm interested in which comments the author's aligned with. It's a discussion, after all.. one that this person started. I'm not saying vote up.. but we could lay off the down arrow.
      - stanleydrew 16y ago
        Fair enough. I admit I hadn't noticed it was the original author making the comment.
- nikster 16y ago
  Yep - I learned it in my first job after college. We had a hacked-together app that was 99% complete. It then remained 99% complete for the next 2 years as we fixed bug after bug after new-bug-that-was-introduced-by-the-last-bugfix. The codebase was unstable from the very beginning. It did eventually ship when we had added enough duct tape, but it never turned into a solid app. Towards the end of year 1 I already knew that most of this simply needed to be re-written and done differently, but I was overruled by more senior folks who were responsible for this mess. It was always "we can't do this now, because we need to ship as fast as possible".
consultutah 16y ago
A good boss will say, "Sure, just make certain that you have adequate unit tests and code coverage before you start cleaning it up."
ojbyrne 16y ago
At my current job, I basically started cleaning up code in my spare time, just because I was leaving. But just deciding, oh wait, I'll just ignore my boss, and whatever culture is in place, on company time, is basically saying "I'm inexperienced." Someone here recently talked about a factoring algorithm that some entry level programmer just decided had to be "cleaned up." He had to be lectured about the bits he failed to understand.
onan_barbarian 16y ago
From the article: “Can I take some time to clean up this code? It is horrendous.” The answer should always be yes to this question. No, it shouldn't. This entirely depends on the long-term prospects and importance of the code. Assuming that your boss is doing his job, he might understand the trade-offs between having you doing 'code gardening' in subsystem A vs. building new functionality in subsystem B. He may even understand them better than you. Mileage varies, of course, depending on Pointy-Hairedness.
- orblivion 16y ago
  I agree, this seems to be based on the feeling some of us have that code has to be "done right", forgetting that the code isn't there for its own sake (at least in a job setting). The bottom line is really what matters in the end, and your boss is closer to that than you are. On the other hand, coding efficiently in the long term will likely sometimes be good for the bottom line, and you are closer to your code's efficiency than your boss. So one should make sure to understand why the boss wants to make a certain call.
  - nikster 16y ago
    I guess you could say: Make it good. Just don't make it _too good_. Not all code needs to be super general, extensible, and re-usable. However, all code needs to be simple and elegantly designed, and unit tested. It needs to not smell.
- cdevroe 16y ago
  I think the perspective I was taking in my post was that many bosses do not fully understand the inner-workings of the codebase for their own product and they also don't need to maintain it. So developers truly are the best person to help weigh the need for maintenance. Of course, there are bosses that fully understand all of this and if you're lucky enough to work for one - awesome.
  - Stormbringer 16y ago
    Fundamentally it is a deeper problem. If you have to put your hand up in order to be allowed to go to the loo, you are not in an environment that respects human dignity. If you have to ask permission in order to do the right thing then you are in an environment that is ethically deficient. Moreover, despite everybody claiming to value success, it is likely that your definition of success is significantly different from the PMs definition of success. Their definition of success is likely to be something like "all activities marked as completed and on time", whereas your definition of success is likely to be something like "the bloody thing actually works properly". This is why testers have such a sucky job, because they always come under pressure from the PMs to give the final sign off on something that they know isn't working properly or 'good enough'. Testers that do their job properly and stand up to the PMs are in danger of losing their jobs. This is why testers need an 'advocate' that has at least as much political clout as the PMs (if not more so - if the PM is putting pressure on the testers to sign off on a crappy product, it isn't the testers who should get sacked...)
Dove 16y ago
never ask for permission for things you know are vital to your work I agree to an extent. It can be easy to fool yourself about what constitutes good code -- in the sense of making a product better or work on it easier. Sometimes bad code is better left as is. Even working totally unconstrained, I prefer not to refactor something unless I have a pressing reason in mind. My rule of thumb is this: as a programmer and an employee, I am professionally bound to produce quality software efficiently. If I know I can complete an assignment faster (or in equal time, but leaving behind a better code base) by rewriting something, building a tool, fixing something architectural . . . I will silently do it. No point in asking permission. It's in my charter. On the other hand, if I want to take a lot of time to rearchitect something -- an order of magnitude more than it would take to just do whatever it was that brought me there -- at that point, it's a strategic decision and management deserves to know about it. The way I see it, management has no right to require me to produce an unprofessional product in my day to day work. And I have no right to force management to use engineering considerations only in strategic decisions.
- cdevroe 16y ago
  Excellent points to add to this discussion. One must always weigh the time it would take clean things up. I think the main point I was trying to make with my post was; a lot of times it would take less time to just fix things than it would be to ask for permission to do so.
  - Stormbringer 16y ago
    The corrollary of this is that it almost always takes longer to explain to a Project Manager why something isn't done yet/can't be done/shouldn't be done that way (etc) than it would do just to finish it or do it another way or do it properly (as the case may be).
- theoj 16y ago
  Then again, refactoring without permission could be a really bad idea. You need to ask yourself a few questions before you proceed. Do you have thorough unit tests for the code that you are trying to refactor? If not, be aware that there is no way to know for sure that your refactoring won't break the functionality of the code. Suppose it breaks the code. Have you thought about the operational impact to clients and the financial costs? Let's say the costs are low. How big and political is your organization? What kind of trouble will you find yourself in? As the hysteria rises, will you be fed to the dogs over this? How bureaucratic is your company and how many people do you need to interact with to fix a functionality breakage? The more people you will need to interact with, the more damage you will do to yourself and your reputation. Others will resent working in panic mode to clean up after you (now widely known as the "rogue" programmer).
jconley 16y ago
This is highly subjective. There is often much more at stake than clean code. On one end if you are shipping source code to an SDK of some sort, the clean code is extremely important, as it is documentation for your users. But, if it's an ancillary system on an internal project, well, sorry, but it probably isn't worth the time cost and risk of introducing new bugs by refactoring. Talk to your boss about it. If they can't articulate the reasons why it's not a good idea to clean up that code, then you should get a different job. Also (self promotion), see: http://www.jdconley.com/blog/archive/2009/01/26/put-down-the-abstract-factory-and-get-something-done.aspx http://www.jdconley.com/blog/archive/2009/01/26/put-down-the...
groaner 16y ago
Why is this the typical reaction? Because bosses don’t have to read, edit and support the code. I dunno about that -- mine actually watches SCM check-ins and flips out if there's some unauthorized code cleanup happening (it "adds risk", supposedly). And yes, I've also been asked to remove unit tests because they were "making things break" (really just causing builds to fail if a regression was introduced).
- syncsynchalt 16y ago
  Time to move on?
  - groaner 16y ago
    I've mentally checked out of this place for quite a while already.
- billybob 16y ago
  Does your boss understand the concept of tests? Removing unit tests because they're "making things break" is like removing your smoke alarm because it's "making annoying noises." To stretch the analogy, it's only a matter of time before the building burns down. If you can't come to a common understanding about this, you need to leave the building ASAP. Find another job.
nostrademons 16y ago
The reasoning behind not cleaning up your code is that if you wait long enough, the problem will often go away - literally! Technology moves fast enough that your feature is usually obsolete within a year or so; if you're not on the critical path that everyone is building upon, chances are your project will just be canceled and all the time spent polishing your code will be wasted. Better to get stuff out there so you have a better chance of being on that critical path, and dealing with the inevitable messes and complaints of "this is shit code!" later. This is the "cascade of ADHD teenagers" development methodology, which is much maligned by professional programmers, but actually seems to work quite well. Google, FaceBook, and Twitter all use it to varying extents, and the entire valley startup ecosystem is based around it.
- mistermann 16y ago
  In the "enterprise" environment, at least the ones I've worked in, this is definitely not the case. But it certainly should be!
  - wr1472 16y ago
    If you look at some of the big investment banks and hedge funds, they won't bother refactoring; they'll just throwaway and re-write. Their architecture is designed to be really modular and very loosely coupled. So you there is little value lost in throwing away and re-writing (ie. You won't throw stuff away thats working fine with the studd you want to re-write).
- astrofinch 16y ago
  Hm, my understanding from poorly-recalled internet surfing was that Google had a very strong culture of code reviews. But I suppose as a former (current?) Google employee you know better.
  - nostrademons 16y ago
    Google has a strong culture of code reviews, but that's not mutually exclusive to accepting an expedient but ugly solution and moving on. Most code reviewers are sensitive to pressure to launch; in rare occasions, you'll see something held up while a bunch of architectural decisions are redone, but usually the point of a code review is to fix obviously wrong or easily fixed issues, not to make massive changes that will block a launch.
netmau5 16y ago
My algorithms professor engrained an idea in me that has stuck throughout my career: first you make it work, then you make it better. When it comes to code, we want an almost mathematically-provable correctness, but the real world doesn't care. The real world cares about getting something that solves their problem; ugliness, code smells, and technical dept are irrelevant to them. So I wouldn't write off the managers and their fancy business needs as just some conspiracy keeping good coders down. I think this need for pragmatism is something that separates a computer scientist from an engineer. It goes both ways though. Sometimes the shit is just terrible. When the cost of any change is introducing a new bug, you've got to take a stand and I think your insight is spot on here. The developer is in the best position to know when the cost of change has gotten to high. I don't bother asking permission, but I've never had to ask forgiveness either. The manager is my customer: he just cares that what comes out of me works, and because I stop to clean up, it does.
tomrod 16y ago
Did anyone else get a huge Web of Trust warning from this site?
- cdevroe 16y ago
  You got a warning from my site? It is just a Wordpress site. Nothing too special going on that I know of. Let me know if you still get it and, if you know, how I can make sure it doesn't happen for everyone.
  - tomrod 16y ago
    I'm very confused as to why my previous comment got downvoted. HN confuses me occasionally. Is it because I use WOT? Or because I brought attention to an issue with the site? Or "playas b hatin"? Also cdevroe, here is the WOT rating--my guess is someone didn't like a post or two: http://www.mywot.com/en/scorecard/cdevroe.com http://www.mywot.com/en/scorecard/cdevroe.com
cdevroe 16y ago
I thought by reading and responding to the discussion here on Hacker News that my karma would go up, not down. :( I'm left with no choice; I LOVE KITTENS! AND BACON!
throwaway0323 16y ago
I'm sorry to see that the owner of promosthatrock.com has let the site they set up at colindevroe.com fade away (presumably the domain expired). It included a full archive of his email exchange(s) with Colin Devroe, chronicling the frustrating experience of paying a developer thousands of dollars and then getting the runaround for months and ultimately getting nothing for their money. If you have the patience to use the wayback machine, give it a look. Perhaps the customer Colin ripped off will see fit to comment here as well. [I'm a longtime HN user with a handle connected to my real name - I don't want to get into it with Colin, but I know him (he took me for a couple grand also) and it bothers me enough to see him on the HN homepage giving advice to a community I respect that I'm posting this]
- jplewicke 16y ago
  This seems to be the archive in question: http://replay.waybackmachine.org/20090227065224/http://colindevroe.com/ http://replay.waybackmachine.org/20090227065224/http://colin...
- cdevroe 16y ago
  It stinks that you're deciding to remain anonymous. If I "took you for a couple grand" I am very sorry about that but I can not defend myself there without knowing who you are. That being said, the promosthatrock situation was over 7 years ago. I definitely made a mistake there and do not deny it. Again, if I wronged you then I am sorry.
ecaron 16y ago
This article is kind of the equivalent of saying if one aspirin is good, ten must be great. The better logic for follow, when cleaning code, is the concept of technical debt (http://gettingreal.37signals.com/ch10_Manage_Debt.php http://gettingreal.37signals.com/ch10_Manage_Debt.php or http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html http://www.codinghorror.com/blog/2009/02/paying-down-your-te...). Essentially the concept is that quality code is an investment, and hacked code is a loan. Too many loans and you'll file bankrupty, too much time on quality and you'll not be able to build fast enough - balance is key. This idea is easy for everyone, from noob to pro to manager, to understand and establishes a common lingo. As a manager, if I found a fresh code monkey doing nothing but assuming they had the aptitude to pay down my standing code depts, I'd promptly show him the door for grossly undervaluing the abilities of his peers.
- Stormbringer 16y ago
  It isn't quality that stops you from building fast enough, it is yak shaving in the guise of quality. Programming is a weird thing, unlike almost everything else higher quality almost always translates to lower costs and faster delivery. To explain this counter-intuitive phenomenon, partly this is due to the exponentially increasing costs of fixing bugs. E.g. fixing a bug at design time = $1, fixing it at coding = $10, fixing it during testing = $100, fixing it once it has been deployed = $1000. ---- Also, the phrase "code monkey" is no longer politically correct. The correct phrase is "software simians" :D
  - ecaron 16y ago
    Can anyone in the web-based software realm back up that scaling costs mythos? I get it in the hardware realm, and to a lesser extent in the distributable software realm... But having worked with everyone from Salesforce.com to Facebook to Amazon, I've never seen any indication of exponential costs from coding to testing to deployment - at worst I would say it is linear.
    - Stormbringer 16y ago
      See also: http://www.superwebdeveloper.com/2009/11/25/the-incredible-rate-of-diminishing-returns-of-fixing-software-bugs/ http://www.superwebdeveloper.com/2009/11/25/the-incredible-r... If I recall from my Software Engineering courses this is based on research that IBM did, back when they still did research into this sort of thing. There is nothing magical about the "web-based software realm" that separates it from other sorts of software and development and allows it to bypass the issues that cause the cost of fixing a bug to sky-rocket like this the later in the process you leave it.
zavulon 16y ago
While I agree with the concept 100% - doing this could land you in trouble if you're billing for your hours. My approach is different (I run a consulting company): when we take over existing code base, I always talk about it upfront with the client: "we're going to take 10% of the time to clean up the code and do necessary refactorings". I then explain to them about technical debt and broken windows theory. Works about 95% of the time - and funny thing is, clients that don't agree with it, end up not working out anyway ...
- Stormbringer 16y ago
  Sounds like you found a good filter there. I object though, on general principles, about having to explain in detail to the client that you are going to do this. If I did have to give an explanation, I would give a simpler analogy - I would say that it is like bringing a car to a mechanic and telling him to fix it. He opens the engine bay and sees that the engine is totally encrusted in mud. As part of his job, he will clean the mud off, otherwise he cannot see the engine properly, and that makes it impossible to see what is broken.
- nikster 16y ago
  I bill for hours and I'll definitely go and refactor something - but only if I need to touch the code anyway in order to implement a new feature or fix a bug. I'll fix _every_ bug the right way, the first time; that may involve refactoring underlying design weaknesses that caused the bug in the first place. I also make sure that this or a similar bug don't happen, which also may cause refactoring. No one's ever complained... I guess that's because it's actually very time efficient in the medium and long term, and usually also in the short term.
InclinedPlane 16y ago
Standard practice should be to refactor as necessary as part of any major code change and to always leave a code base cleaner than you found it. With that you only need a few targeted dedicated code clean-up projects.
famousactress 16y ago
You shouldn't ask permission for it because on most of the time you shouldn't be doing it. It's like going to the grocery store hungry, without a shopping list. I'm a big believer in: 1. You don't modify code without intent to change it's behavior. You're there to fix a bug, or add a feature. 2. You leave the code you better than you found it. In fact, you elevate it to your/the-team's standards du jour. 3. That's the cost of doing business. There are no multiple estimates. It's not "Well, an hour to just fix it with a hack but it really deserves a day". That's a day. Deciding on the team's values and coding standards is a group-decision. Deciding on when to apply them isn't.
- astrofinch 16y ago
  "You don't modify code without intent to change it's behavior. You're there to fix a bug, or add a feature." This makes a lot of sense. If you clean up code on anything other than a just-in-time basis, you risk fixing up something that will never need to be modified before it goes out of use. Choosing coding standards makes a lot of sense too. If you're coding a MVP, the probability of code going out of use is higher and your standard should be lower. Your team's comfort level with modifying dirty code (how much does it demoralize them? does modifying dirty code fit with their style?) is another consideration. I think it could make sense to vary the desired code quality depending on the personality of its primary maintainer and how likely it is to get thrown out. A corollary is that if different coders on your team have different preferred levels of code quality, you should assign them to different parts of the project on that basis. I think there is a fair amount of room to apply microeconomics-type thinking here, along with behavioral economics-type thinking about what biases (e.g. hyperbolic discounting) might cause one to choose the wrong level of code quality. And there's also the opportunity for professional development as coders become more comfortable programming at different spots on their personal output speed/code quality potential possibility curves.
  - famousactress 16y ago
    Thanks. Regarding 'dirty code' though, you've reminded me of another point I believe in. 4. All code is temporary. I said du jour for a reason. It's all wonderful for a little while, but there's no such thing as "Okay, that's been refactored now", in an lasting sense. We're building and maintaining sand castles. Either the world around the code changes, or our opinions about it do. "dirty" code doesn't exist to me, at least not in some conveniently boolean state. The half-life of a piece of code depends on a number of variables, but there's no such thing as code that doesn't start decaying the moment if leaves your keyboard. So yeah, it's all dirty, pretty much.
tjmc 16y ago
Great idea until your code clean up creates a bug that isn't in the original 'ugly' version and suddenly you've gone from not asking permission to begging forgiveness. Depending on what you're working on that might be too great a risk.
joshuaxls 16y ago
The real issue is that you shouldn't have much code to clean up in the first place. If you occasionally need to hack something out to ship it before its effect is lost — go for it. Clean it up the next time you touch it. If you're constantly writing code under pressure like this, you have a management problem. Your boss probably doesn't code. Sucks for you. If someone constantly ships poor code, you have a talent problem. Mediocre talent can kill a startup. Get rid of the bad apple ASAP.
- jodrellblank 16y ago
  It's not just poor code which does it, it's code that has become tangled due to subsequent extensions and interactions. Also, hopefully after a few months of project and codebase specific work, better ways to do what you did will start coming to mind - that's not the same as being a poor coder in the judgmental sense.
michaelfeathers 16y ago
This is a paraphrase of the advice that Martin Fowler gave in the book 'Refactoring: Improving the Design of Existing Code'. Kind of a shame no one mentioned that, but then it's been ten years.
pilif 16y ago
As long as you are the only person usually working on the affected parts, sure. Just go ahead. But if multiple people are working with this component or are calling it (in case you want to fix a broken interface), I think some discussion with your fellow team members would be in order as they will have to adapt to whatever you produce. I agree on the general sentiment of not telling the boss though: It's hard to make non-programmers understand the burden that is ugly code. They think in features and whether something is "visible for the customer" (if it isn't, then it might as well not exist). Such an attitude can lead you to having to make a decision when implementing a feature: "Oh - this code here is really shitty. I could now a) clean this up and cleanly add the feature or b) just hack the feature in somehow, maybe breaking encapsulation a bit more" Bosses and people concerned about their free time think b), I tend to think a). The problem with b) is that you get to your goal much more quickly (which the feature-oriented people like as it makes you seem more productive), but you are incurring dept. Now the bad code just got worse until at one point, something really breaks badly and then you WILL have to pay the price for cleaning up. This might very well be at a time where you are pressed by some deadline which means a lot of after-hours work for you. Then again, in a team, the might or might not be you that has to clean up (you certainly hope it isn't you). So doing it the quick route isn't just irresponsible to the project, it's also irresponsible to your team mates because they might be the unlucky ones the bad code breaks over. So if possible, try to take those extra hours to do it the clean way. The product as a whole will get better and your team mates will not be pissed if they have to clean up your mess.
alextingle 16y ago
I think this depends on how experienced you are. If you are only a few years out of University, then perhaps you should go and find the original author and ask them why the code is the way it is, before you dive in to "fix" things. On the other hand, if you've got decades of experience then you probably know what you're doing - don't waste time, just get on with it.
esschul 16y ago
How long the application is supposed to live, should be relevant here. Some stuff can be a piece of crap, even if it goes against some sensibility of a developer, if it isn't suppose to live long and can give you something back. Some times it should be up to the people that know how long it'll live. It's first when you make the money to pay for the refactoring, you should do it. But hey, make it perfect from the get go ;) I know, temporary stuff has a tendency to become permanent. But if you see this trend, then you and your manager should be grown-up enough to have the discussion of rewriting it for something more longterm. (It all depends on what sort of project it is). Long term projects should never voluntarily allow technical debt. It's just bad for business.
ezyang 16y ago
If you do clean up code, please put it in a separate commit, not mixed in with semantic changes. Thanks!
asymptotic 16y ago
I'm surprised noone pointed out this post from Sriram Krishnan, a product manager at Microsoft: Stuff I've Learned at Microsoft http://www.sriramkrishnan.com/blog/2009/12/stuff-ive-learned-at-microsoft.html http://www.sriramkrishnan.com/blog/2009/12/stuff-ive-learned... "Ask for forgiveness, not for permission ... Any sufficiently large institution has something to lose...Corporate systems are optimized for saying no. Maintain the status quo. No risk of failure and a spectacular blowout...This is exactly why you are better off going ahead and doing something without asking first. If you don’t ask, no one can tell you to not do it." I'd argue that the specifc principle "never ask permission to clean up code" can be generalised to "never ask permission", especially for software houses that have grown large and sclerotic. But YMMV; in a previous job I once told my manager I had an exciting idea for an automated test platform that I'd be willing to implement and test in my free time. His response was "And when you're finished, who's going to maintain it? I'd need to hire someone at least as skilled as you to keep it running. Please don't make it."
trustfundbaby 16y ago
Be very careful starting down this road though ... especially if you don't have tests in place or are not intimately familiar with the codebase or you might find that your 4 hour sugar high turns into a nightmarish week of trying to fix random bugs from your refactoring effort.
aidenn0 16y ago
I disagree with this article for several reasons: 1) Cleaning up code adds 0 value to the customer today. It may add value for the customer down the road, but see #3 2) Most engineers underestimate the time & effort to clean up code without altering it's behavior, and any alteration of its behavior is almost certain to introduce regressions and/or bugs 3) If you knew for certain that your code was still going to be used and hacked on 5-10 years from now, then it would probably be a net positive, but you can't predict that. If you think you can predict that, you're wrong.
jkrieger 16y ago
On 02-05-2004 We paid Colin D. Devroe $7,949.96 and we never received www.promosthatrock.com from him. We sued him and before we got him in court he went bankrupt. He never made good to pay us back. I wouldn’t recommend that anyone should trust him. We will have a newer version of www.promosthatrock.com up next week.
jkrieger 16y ago
On 02-05-2004 We paid Colin D. Devroe $7,949.96 and we never received www.promosthatrock.com from him. We sued him and before we got him in court he went bankrupt. He never made good to pay us back. I wouldn’t recommend that anyone should trust him. We will have a newer version of www.promosthatrock.com up next week.

160 points by jakedahn 16y ago

sdizdar 16y ago

Simple rule of development: You should always leave code in better shape than you find it.

shaggyfrog 16y ago
Sounds like a hacker's spin on Dan Savage's campsite rule. https://secure.wikimedia.org/wikipedia/en/wiki/Savage_Love#.22Campsite_rule.22 https://secure.wikimedia.org/wikipedia/en/wiki/Savage_Love#....

cdevroe 16y ago

Thanks for submitting this jakedahn! If anyone has any questions, I'm around to answer them.

boyter 16y ago

This is something that took me 2 years or so to learn. One day I realised nobody was really looking at my timecards in depth so I started allocating extra time to things and using the extra time to fix the things I thought needed fixing. Once I started delivering on this I showed my manager who agreed that it was a good use of time. I was given free reign to fix anything I felt would add maximum value, provided the bug fixes continued to be delivered without any major compromise. Since that time I have refactored quite a few of our codebases; added unit tests, fixed some build processes, improved performance and generally feel happier at work for getting things done that are important to me. Dont get stuck in constant bug fix mode would be my suggestion. If you cant get approval to fix things then change jobs because bug fix after bug fix is depressing and will bring you down.

cdevroe 16y ago
This is awesome.
- stanleydrew 16y ago
  That's what the up arrow is for.
  - famousactress 16y ago
    Sure, but considering this is the author of the article we're commenting on, I think an exception is reasonable here. I'm interested in which comments the author's aligned with. It's a discussion, after all.. one that this person started. I'm not saying vote up.. but we could lay off the down arrow.
    - stanleydrew 16y ago
      Fair enough. I admit I hadn't noticed it was the original author making the comment.
nikster 16y ago
Yep - I learned it in my first job after college. We had a hacked-together app that was 99% complete. It then remained 99% complete for the next 2 years as we fixed bug after bug after new-bug-that-was-introduced-by-the-last-bugfix. The codebase was unstable from the very beginning. It did eventually ship when we had added enough duct tape, but it never turned into a solid app. Towards the end of year 1 I already knew that most of this simply needed to be re-written and done differently, but I was overruled by more senior folks who were responsible for this mess. It was always "we can't do this now, because we need to ship as fast as possible".

consultutah 16y ago

A good boss will say, "Sure, just make certain that you have adequate unit tests and code coverage before you start cleaning it up."

ojbyrne 16y ago

At my current job, I basically started cleaning up code in my spare time, just because I was leaving. But just deciding, oh wait, I'll just ignore my boss, and whatever culture is in place, on company time, is basically saying "I'm inexperienced." Someone here recently talked about a factoring algorithm that some entry level programmer just decided had to be "cleaned up." He had to be lectured about the bits he failed to understand.

onan_barbarian 16y ago

From the article: “Can I take some time to clean up this code? It is horrendous.” The answer should always be yes to this question. No, it shouldn't. This entirely depends on the long-term prospects and importance of the code. Assuming that your boss is doing his job, he might understand the trade-offs between having you doing 'code gardening' in subsystem A vs. building new functionality in subsystem B. He may even understand them better than you. Mileage varies, of course, depending on Pointy-Hairedness.

orblivion 16y ago
I agree, this seems to be based on the feeling some of us have that code has to be "done right", forgetting that the code isn't there for its own sake (at least in a job setting). The bottom line is really what matters in the end, and your boss is closer to that than you are. On the other hand, coding efficiently in the long term will likely sometimes be good for the bottom line, and you are closer to your code's efficiency than your boss. So one should make sure to understand why the boss wants to make a certain call.
- nikster 16y ago
  I guess you could say: Make it good. Just don't make it _too good_. Not all code needs to be super general, extensible, and re-usable. However, all code needs to be simple and elegantly designed, and unit tested. It needs to not smell.
cdevroe 16y ago
I think the perspective I was taking in my post was that many bosses do not fully understand the inner-workings of the codebase for their own product and they also don't need to maintain it. So developers truly are the best person to help weigh the need for maintenance. Of course, there are bosses that fully understand all of this and if you're lucky enough to work for one - awesome.
- Stormbringer 16y ago
  Fundamentally it is a deeper problem. If you have to put your hand up in order to be allowed to go to the loo, you are not in an environment that respects human dignity. If you have to ask permission in order to do the right thing then you are in an environment that is ethically deficient. Moreover, despite everybody claiming to value success, it is likely that your definition of success is significantly different from the PMs definition of success. Their definition of success is likely to be something like "all activities marked as completed and on time", whereas your definition of success is likely to be something like "the bloody thing actually works properly". This is why testers have such a sucky job, because they always come under pressure from the PMs to give the final sign off on something that they know isn't working properly or 'good enough'. Testers that do their job properly and stand up to the PMs are in danger of losing their jobs. This is why testers need an 'advocate' that has at least as much political clout as the PMs (if not more so - if the PM is putting pressure on the testers to sign off on a crappy product, it isn't the testers who should get sacked...)

Dove 16y ago

never ask for permission for things you know are vital to your work I agree to an extent. It can be easy to fool yourself about what constitutes good code -- in the sense of making a product better or work on it easier. Sometimes bad code is better left as is. Even working totally unconstrained, I prefer not to refactor something unless I have a pressing reason in mind. My rule of thumb is this: as a programmer and an employee, I am professionally bound to produce quality software efficiently. If I know I can complete an assignment faster (or in equal time, but leaving behind a better code base) by rewriting something, building a tool, fixing something architectural . . . I will silently do it. No point in asking permission. It's in my charter. On the other hand, if I want to take a lot of time to rearchitect something -- an order of magnitude more than it would take to just do whatever it was that brought me there -- at that point, it's a strategic decision and management deserves to know about it. The way I see it, management has no right to require me to produce an unprofessional product in my day to day work. And I have no right to force management to use engineering considerations only in strategic decisions.

cdevroe 16y ago
Excellent points to add to this discussion. One must always weigh the time it would take clean things up. I think the main point I was trying to make with my post was; a lot of times it would take less time to just fix things than it would be to ask for permission to do so.
- Stormbringer 16y ago
  The corrollary of this is that it almost always takes longer to explain to a Project Manager why something isn't done yet/can't be done/shouldn't be done that way (etc) than it would do just to finish it or do it another way or do it properly (as the case may be).
theoj 16y ago
Then again, refactoring without permission could be a really bad idea. You need to ask yourself a few questions before you proceed. Do you have thorough unit tests for the code that you are trying to refactor? If not, be aware that there is no way to know for sure that your refactoring won't break the functionality of the code. Suppose it breaks the code. Have you thought about the operational impact to clients and the financial costs? Let's say the costs are low. How big and political is your organization? What kind of trouble will you find yourself in? As the hysteria rises, will you be fed to the dogs over this? How bureaucratic is your company and how many people do you need to interact with to fix a functionality breakage? The more people you will need to interact with, the more damage you will do to yourself and your reputation. Others will resent working in panic mode to clean up after you (now widely known as the "rogue" programmer).

jconley 16y ago

This is highly subjective. There is often much more at stake than clean code. On one end if you are shipping source code to an SDK of some sort, the clean code is extremely important, as it is documentation for your users. But, if it's an ancillary system on an internal project, well, sorry, but it probably isn't worth the time cost and risk of introducing new bugs by refactoring. Talk to your boss about it. If they can't articulate the reasons why it's not a good idea to clean up that code, then you should get a different job. Also (self promotion), see: http://www.jdconley.com/blog/archive/2009/01/26/put-down-the-abstract-factory-and-get-something-done.aspx http://www.jdconley.com/blog/archive/2009/01/26/put-down-the...

groaner 16y ago

Why is this the typical reaction? Because bosses don’t have to read, edit and support the code. I dunno about that -- mine actually watches SCM check-ins and flips out if there's some unauthorized code cleanup happening (it "adds risk", supposedly). And yes, I've also been asked to remove unit tests because they were "making things break" (really just causing builds to fail if a regression was introduced).

syncsynchalt 16y ago
Time to move on?
- groaner 16y ago
  I've mentally checked out of this place for quite a while already.
billybob 16y ago
Does your boss understand the concept of tests? Removing unit tests because they're "making things break" is like removing your smoke alarm because it's "making annoying noises." To stretch the analogy, it's only a matter of time before the building burns down. If you can't come to a common understanding about this, you need to leave the building ASAP. Find another job.

nostrademons 16y ago

The reasoning behind not cleaning up your code is that if you wait long enough, the problem will often go away - literally! Technology moves fast enough that your feature is usually obsolete within a year or so; if you're not on the critical path that everyone is building upon, chances are your project will just be canceled and all the time spent polishing your code will be wasted. Better to get stuff out there so you have a better chance of being on that critical path, and dealing with the inevitable messes and complaints of "this is shit code!" later. This is the "cascade of ADHD teenagers" development methodology, which is much maligned by professional programmers, but actually seems to work quite well. Google, FaceBook, and Twitter all use it to varying extents, and the entire valley startup ecosystem is based around it.

mistermann 16y ago
In the "enterprise" environment, at least the ones I've worked in, this is definitely not the case. But it certainly should be!
- wr1472 16y ago
  If you look at some of the big investment banks and hedge funds, they won't bother refactoring; they'll just throwaway and re-write. Their architecture is designed to be really modular and very loosely coupled. So you there is little value lost in throwing away and re-writing (ie. You won't throw stuff away thats working fine with the studd you want to re-write).
astrofinch 16y ago
Hm, my understanding from poorly-recalled internet surfing was that Google had a very strong culture of code reviews. But I suppose as a former (current?) Google employee you know better.
- nostrademons 16y ago
  Google has a strong culture of code reviews, but that's not mutually exclusive to accepting an expedient but ugly solution and moving on. Most code reviewers are sensitive to pressure to launch; in rare occasions, you'll see something held up while a bunch of architectural decisions are redone, but usually the point of a code review is to fix obviously wrong or easily fixed issues, not to make massive changes that will block a launch.

netmau5 16y ago

My algorithms professor engrained an idea in me that has stuck throughout my career: first you make it work, then you make it better. When it comes to code, we want an almost mathematically-provable correctness, but the real world doesn't care. The real world cares about getting something that solves their problem; ugliness, code smells, and technical dept are irrelevant to them. So I wouldn't write off the managers and their fancy business needs as just some conspiracy keeping good coders down. I think this need for pragmatism is something that separates a computer scientist from an engineer. It goes both ways though. Sometimes the shit is just terrible. When the cost of any change is introducing a new bug, you've got to take a stand and I think your insight is spot on here. The developer is in the best position to know when the cost of change has gotten to high. I don't bother asking permission, but I've never had to ask forgiveness either. The manager is my customer: he just cares that what comes out of me works, and because I stop to clean up, it does.

tomrod 16y ago

Did anyone else get a huge Web of Trust warning from this site?

cdevroe 16y ago
You got a warning from my site? It is just a Wordpress site. Nothing too special going on that I know of. Let me know if you still get it and, if you know, how I can make sure it doesn't happen for everyone.
- tomrod 16y ago
  I'm very confused as to why my previous comment got downvoted. HN confuses me occasionally. Is it because I use WOT? Or because I brought attention to an issue with the site? Or "playas b hatin"? Also cdevroe, here is the WOT rating--my guess is someone didn't like a post or two: http://www.mywot.com/en/scorecard/cdevroe.com http://www.mywot.com/en/scorecard/cdevroe.com

cdevroe 16y ago

I thought by reading and responding to the discussion here on Hacker News that my karma would go up, not down. :( I'm left with no choice; I LOVE KITTENS! AND BACON!

throwaway0323 16y ago

I'm sorry to see that the owner of promosthatrock.com has let the site they set up at colindevroe.com fade away (presumably the domain expired). It included a full archive of his email exchange(s) with Colin Devroe, chronicling the frustrating experience of paying a developer thousands of dollars and then getting the runaround for months and ultimately getting nothing for their money. If you have the patience to use the wayback machine, give it a look. Perhaps the customer Colin ripped off will see fit to comment here as well. [I'm a longtime HN user with a handle connected to my real name - I don't want to get into it with Colin, but I know him (he took me for a couple grand also) and it bothers me enough to see him on the HN homepage giving advice to a community I respect that I'm posting this]

jplewicke 16y ago
This seems to be the archive in question: http://replay.waybackmachine.org/20090227065224/http://colindevroe.com/ http://replay.waybackmachine.org/20090227065224/http://colin...
cdevroe 16y ago
It stinks that you're deciding to remain anonymous. If I "took you for a couple grand" I am very sorry about that but I can not defend myself there without knowing who you are. That being said, the promosthatrock situation was over 7 years ago. I definitely made a mistake there and do not deny it. Again, if I wronged you then I am sorry.

ecaron 16y ago

This article is kind of the equivalent of saying if one aspirin is good, ten must be great. The better logic for follow, when cleaning code, is the concept of technical debt (http://gettingreal.37signals.com/ch10_Manage_Debt.php http://gettingreal.37signals.com/ch10_Manage_Debt.php or http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html http://www.codinghorror.com/blog/2009/02/paying-down-your-te...). Essentially the concept is that quality code is an investment, and hacked code is a loan. Too many loans and you'll file bankrupty, too much time on quality and you'll not be able to build fast enough - balance is key. This idea is easy for everyone, from noob to pro to manager, to understand and establishes a common lingo. As a manager, if I found a fresh code monkey doing nothing but assuming they had the aptitude to pay down my standing code depts, I'd promptly show him the door for grossly undervaluing the abilities of his peers.

Stormbringer 16y ago
It isn't quality that stops you from building fast enough, it is yak shaving in the guise of quality. Programming is a weird thing, unlike almost everything else higher quality almost always translates to lower costs and faster delivery. To explain this counter-intuitive phenomenon, partly this is due to the exponentially increasing costs of fixing bugs. E.g. fixing a bug at design time = $1, fixing it at coding = $10, fixing it during testing = $100, fixing it once it has been deployed = $1000. ---- Also, the phrase "code monkey" is no longer politically correct. The correct phrase is "software simians" :D
- ecaron 16y ago
  Can anyone in the web-based software realm back up that scaling costs mythos? I get it in the hardware realm, and to a lesser extent in the distributable software realm... But having worked with everyone from Salesforce.com to Facebook to Amazon, I've never seen any indication of exponential costs from coding to testing to deployment - at worst I would say it is linear.
  - Stormbringer 16y ago
    See also: http://www.superwebdeveloper.com/2009/11/25/the-incredible-rate-of-diminishing-returns-of-fixing-software-bugs/ http://www.superwebdeveloper.com/2009/11/25/the-incredible-r... If I recall from my Software Engineering courses this is based on research that IBM did, back when they still did research into this sort of thing. There is nothing magical about the "web-based software realm" that separates it from other sorts of software and development and allows it to bypass the issues that cause the cost of fixing a bug to sky-rocket like this the later in the process you leave it.

zavulon 16y ago

While I agree with the concept 100% - doing this could land you in trouble if you're billing for your hours. My approach is different (I run a consulting company): when we take over existing code base, I always talk about it upfront with the client: "we're going to take 10% of the time to clean up the code and do necessary refactorings". I then explain to them about technical debt and broken windows theory. Works about 95% of the time - and funny thing is, clients that don't agree with it, end up not working out anyway ...

Stormbringer 16y ago
Sounds like you found a good filter there. I object though, on general principles, about having to explain in detail to the client that you are going to do this. If I did have to give an explanation, I would give a simpler analogy - I would say that it is like bringing a car to a mechanic and telling him to fix it. He opens the engine bay and sees that the engine is totally encrusted in mud. As part of his job, he will clean the mud off, otherwise he cannot see the engine properly, and that makes it impossible to see what is broken.
nikster 16y ago
I bill for hours and I'll definitely go and refactor something - but only if I need to touch the code anyway in order to implement a new feature or fix a bug. I'll fix _every_ bug the right way, the first time; that may involve refactoring underlying design weaknesses that caused the bug in the first place. I also make sure that this or a similar bug don't happen, which also may cause refactoring. No one's ever complained... I guess that's because it's actually very time efficient in the medium and long term, and usually also in the short term.

InclinedPlane 16y ago

Standard practice should be to refactor as necessary as part of any major code change and to always leave a code base cleaner than you found it. With that you only need a few targeted dedicated code clean-up projects.

famousactress 16y ago

You shouldn't ask permission for it because on most of the time you shouldn't be doing it. It's like going to the grocery store hungry, without a shopping list. I'm a big believer in: 1. You don't modify code without intent to change it's behavior. You're there to fix a bug, or add a feature. 2. You leave the code you better than you found it. In fact, you elevate it to your/the-team's standards du jour. 3. That's the cost of doing business. There are no multiple estimates. It's not "Well, an hour to just fix it with a hack but it really deserves a day". That's a day. Deciding on the team's values and coding standards is a group-decision. Deciding on when to apply them isn't.

astrofinch 16y ago
"You don't modify code without intent to change it's behavior. You're there to fix a bug, or add a feature." This makes a lot of sense. If you clean up code on anything other than a just-in-time basis, you risk fixing up something that will never need to be modified before it goes out of use. Choosing coding standards makes a lot of sense too. If you're coding a MVP, the probability of code going out of use is higher and your standard should be lower. Your team's comfort level with modifying dirty code (how much does it demoralize them? does modifying dirty code fit with their style?) is another consideration. I think it could make sense to vary the desired code quality depending on the personality of its primary maintainer and how likely it is to get thrown out. A corollary is that if different coders on your team have different preferred levels of code quality, you should assign them to different parts of the project on that basis. I think there is a fair amount of room to apply microeconomics-type thinking here, along with behavioral economics-type thinking about what biases (e.g. hyperbolic discounting) might cause one to choose the wrong level of code quality. And there's also the opportunity for professional development as coders become more comfortable programming at different spots on their personal output speed/code quality potential possibility curves.
- famousactress 16y ago
  Thanks. Regarding 'dirty code' though, you've reminded me of another point I believe in. 4. All code is temporary. I said du jour for a reason. It's all wonderful for a little while, but there's no such thing as "Okay, that's been refactored now", in an lasting sense. We're building and maintaining sand castles. Either the world around the code changes, or our opinions about it do. "dirty" code doesn't exist to me, at least not in some conveniently boolean state. The half-life of a piece of code depends on a number of variables, but there's no such thing as code that doesn't start decaying the moment if leaves your keyboard. So yeah, it's all dirty, pretty much.

tjmc 16y ago

Great idea until your code clean up creates a bug that isn't in the original 'ugly' version and suddenly you've gone from not asking permission to begging forgiveness. Depending on what you're working on that might be too great a risk.

joshuaxls 16y ago

The real issue is that you shouldn't have much code to clean up in the first place. If you occasionally need to hack something out to ship it before its effect is lost — go for it. Clean it up the next time you touch it. If you're constantly writing code under pressure like this, you have a management problem. Your boss probably doesn't code. Sucks for you. If someone constantly ships poor code, you have a talent problem. Mediocre talent can kill a startup. Get rid of the bad apple ASAP.

jodrellblank 16y ago
It's not just poor code which does it, it's code that has become tangled due to subsequent extensions and interactions. Also, hopefully after a few months of project and codebase specific work, better ways to do what you did will start coming to mind - that's not the same as being a poor coder in the judgmental sense.

michaelfeathers 16y ago

This is a paraphrase of the advice that Martin Fowler gave in the book 'Refactoring: Improving the Design of Existing Code'. Kind of a shame no one mentioned that, but then it's been ten years.

pilif 16y ago

As long as you are the only person usually working on the affected parts, sure. Just go ahead. But if multiple people are working with this component or are calling it (in case you want to fix a broken interface), I think some discussion with your fellow team members would be in order as they will have to adapt to whatever you produce. I agree on the general sentiment of not telling the boss though: It's hard to make non-programmers understand the burden that is ugly code. They think in features and whether something is "visible for the customer" (if it isn't, then it might as well not exist). Such an attitude can lead you to having to make a decision when implementing a feature: "Oh - this code here is really shitty. I could now a) clean this up and cleanly add the feature or b) just hack the feature in somehow, maybe breaking encapsulation a bit more" Bosses and people concerned about their free time think b), I tend to think a). The problem with b) is that you get to your goal much more quickly (which the feature-oriented people like as it makes you seem more productive), but you are incurring dept. Now the bad code just got worse until at one point, something really breaks badly and then you WILL have to pay the price for cleaning up. This might very well be at a time where you are pressed by some deadline which means a lot of after-hours work for you. Then again, in a team, the might or might not be you that has to clean up (you certainly hope it isn't you). So doing it the quick route isn't just irresponsible to the project, it's also irresponsible to your team mates because they might be the unlucky ones the bad code breaks over. So if possible, try to take those extra hours to do it the clean way. The product as a whole will get better and your team mates will not be pissed if they have to clean up your mess.

alextingle 16y ago

I think this depends on how experienced you are. If you are only a few years out of University, then perhaps you should go and find the original author and ask them why the code is the way it is, before you dive in to "fix" things. On the other hand, if you've got decades of experience then you probably know what you're doing - don't waste time, just get on with it.

esschul 16y ago

How long the application is supposed to live, should be relevant here. Some stuff can be a piece of crap, even if it goes against some sensibility of a developer, if it isn't suppose to live long and can give you something back. Some times it should be up to the people that know how long it'll live. It's first when you make the money to pay for the refactoring, you should do it. But hey, make it perfect from the get go ;) I know, temporary stuff has a tendency to become permanent. But if you see this trend, then you and your manager should be grown-up enough to have the discussion of rewriting it for something more longterm. (It all depends on what sort of project it is). Long term projects should never voluntarily allow technical debt. It's just bad for business.

ezyang 16y ago

If you do clean up code, please put it in a separate commit, not mixed in with semantic changes. Thanks!

asymptotic 16y ago

I'm surprised noone pointed out this post from Sriram Krishnan, a product manager at Microsoft: Stuff I've Learned at Microsoft http://www.sriramkrishnan.com/blog/2009/12/stuff-ive-learned-at-microsoft.html http://www.sriramkrishnan.com/blog/2009/12/stuff-ive-learned... "Ask for forgiveness, not for permission ... Any sufficiently large institution has something to lose...Corporate systems are optimized for saying no. Maintain the status quo. No risk of failure and a spectacular blowout...This is exactly why you are better off going ahead and doing something without asking first. If you don’t ask, no one can tell you to not do it." I'd argue that the specifc principle "never ask permission to clean up code" can be generalised to "never ask permission", especially for software houses that have grown large and sclerotic. But YMMV; in a previous job I once told my manager I had an exciting idea for an automated test platform that I'd be willing to implement and test in my free time. His response was "And when you're finished, who's going to maintain it? I'd need to hire someone at least as skilled as you to keep it running. Please don't make it."

trustfundbaby 16y ago

Be very careful starting down this road though ... especially if you don't have tests in place or are not intimately familiar with the codebase or you might find that your 4 hour sugar high turns into a nightmarish week of trying to fix random bugs from your refactoring effort.

aidenn0 16y ago

I disagree with this article for several reasons: 1) Cleaning up code adds 0 value to the customer today. It may add value for the customer down the road, but see #3 2) Most engineers underestimate the time & effort to clean up code without altering it's behavior, and any alteration of its behavior is almost certain to introduce regressions and/or bugs 3) If you knew for certain that your code was still going to be used and hacked on 5-10 years from now, then it would probably be a net positive, but you can't predict that. If you think you can predict that, you're wrong.

jkrieger 16y ago

On 02-05-2004 We paid Colin D. Devroe $7,949.96 and we never received www.promosthatrock.com from him. We sued him and before we got him in court he went bankrupt. He never made good to pay us back. I wouldn’t recommend that anyone should trust him. We will have a newer version of www.promosthatrock.com up next week.

jkrieger 16y ago