<i>never ask for permission for things you know are vital to your work</i><p>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 <i>reason</i> in mind.<p>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.<p>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.<p>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.
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.<p>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.<p>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.
The reasoning behind <i>not</i> 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.<p>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.
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).<p>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.<p>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.<p>[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]
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.<p>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.<p>Mileage varies, of course, depending on Pointy-Hairedness.
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.<p>I'm a big believer in:<p>1. You don't modify code without intent to change it's behavior. You're there to fix a bug, or add a feature.<p>2. You leave the code you better than you found it. In fact, you elevate it to your/the-team's standards du jour.<p>3. That's the cost of doing business. There are no multiple estimates. It's not <i>"Well, an hour to just fix it with a hack but it really deserves a day"</i>. 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.
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.<p>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.
This article is kind of the equivalent of saying if one aspirin is good, ten must be great.<p>The better logic for follow, when cleaning code, is the concept of technical debt (<a href="http://gettingreal.37signals.com/ch10_Manage_Debt.php" rel="nofollow">http://gettingreal.37signals.com/ch10_Manage_Debt.php</a> or <a href="http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html" rel="nofollow">http://www.codinghorror.com/blog/2009/02/paying-down-your-te...</a>). 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.<p>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.
As long as you are the only person usually working on the affected parts, sure. Just go ahead.<p>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.<p>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).<p>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"<p>Bosses and people concerned about their free time think b), I tend to think a).<p>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.<p>Then again, in a team, the might or might not be you that has to clean up (you certainly hope it isn't you).<p>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.<p>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.
<i>Why is this the typical reaction? Because bosses don’t have to read, edit and support the code.</i><p>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).<p>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).
I disagree with this article for several reasons:<p>1) Cleaning up code adds 0 value to the customer today. It may add value for the customer down the road, but see #3<p>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<p>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.
While I agree with the concept 100% - doing this could land you in trouble if you're billing for your hours.<p>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 ...
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.
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: <a href="http://www.jdconley.com/blog/archive/2009/01/26/put-down-the-abstract-factory-and-get-something-done.aspx" rel="nofollow">http://www.jdconley.com/blog/archive/2009/01/26/put-down-the...</a>
The real issue is that you shouldn't have much code to clean up in the first place.<p>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.<p>If you're constantly writing code under pressure like this, you have a management problem. Your boss probably doesn't code. Sucks for you.<p>If someone constantly ships poor code, you have a talent problem. Mediocre talent can kill a startup. Get rid of the bad apple ASAP.
I'm surprised noone pointed out this post from Sriram Krishnan, a product manager at Microsoft:<p>Stuff I've Learned at Microsoft
<a href="http://www.sriramkrishnan.com/blog/2009/12/stuff-ive-learned-at-microsoft.html" rel="nofollow">http://www.sriramkrishnan.com/blog/2009/12/stuff-ive-learned...</a><p>"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."<p>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."
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."<p>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.
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 <i>why</i> the code is the way it is, before you dive in to "fix" things.<p>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.
Be <i>very</i> careful starting down this road though ... <i>especially</i> 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.
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.<p>But hey, make it perfect from the get go ;)<p>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).<p>Long term projects should never voluntarily allow technical debt. It's just bad for business.
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.
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.
I thought by reading and responding to the discussion here on Hacker News that my karma would go up, not down. :(<p>I'm left with no choice; I LOVE KITTENS! AND BACON!