
Why you should never ask permission to clean up code. - jakedahn
http://cdevroe.com/notes/code-maintenance-dont-ask/
======
Dove
_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.

~~~
theoj
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).

~~~
astrofinch
These considerations apply to a much lesser extent if you're at a shop that
uses version control.

~~~
StrawberryFrog
Are there really still shops that don't? It's not like it costs money.

~~~
T-hawk
Oh heck yeah. We at HN are immersed in tech. Our experience is with companies
whose core domain is tech and take things like source control for granted. But
what about your local gym or sports franchise or restaurant chain or
newspaper? There are millions of companies that don't have any kind of
technical director or direction. Where some manager thought it would be a good
idea to have a web site, and hired a programmer who's measured on how fast he
can throw it together. What's a testing server? Heck, what's a server?

------
boyter
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
This is awesome.

~~~
stanleydrew
That's what the up arrow is for.

~~~
famousactress
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
Fair enough. I admit I hadn't noticed it was the original author making the
comment.

------
nostrademons
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.

~~~
pyre

      > Technology moves fast enough that your feature is
      > usually obsolete within a year or so
    

That depends on your industry. My company has some core infrastructure running
on code written in the 90's when characters were scarce (8-character variable
names) and actual loops were even scarcer (goto's instead).

Feature-sets like "processes transactions" never go away just because
technology moves forward. Some of that almost feels like you've had "too much
of the Kool-aid."

~~~
nostrademons
My company barely existed in the 90s - it was some research project at
Stanford.

And feature sets like "processes transactions" absolutely do go away because
technology (and its applications) moves forwards. This was a large part of the
success of MySQL: relational databases started getting used in applications
where transactional integrity really wasn't that important, and they were
better off working around it (or just showing inconsistent data to the user)
rather than paying the price for transactions.

Or look at this recent discussion surrounding Google Megastore:

[http://glinden.blogspot.com/2011/02/comparing-google-
megasto...](http://glinden.blogspot.com/2011/02/comparing-google-
megastore.html)

Megastore suffers a large latency penalty for ACID semantics. In many
applications, it's better _not_ to take that latency hit and instead settle
for eventual consistency instead.

~~~
pyre
I meant transactions as in actual exchanges of money, not as in the computer
science / database term.

~~~
nostrademons
Financial apps are a different story. I interned on Pay.gov in college, and
then spent the first 2 years of my career at a financial software startup. The
standards are _much_ different when you're handling money (or avionics, or
medical devices, or anything that's "mission critical"). And even in the
finance world, the standards vary a lot depending on whether you're doing
analytics or transaction processing.

But while that software will never go away, it becomes a smaller part of the
whole software industry. Much of the interesting growth is in areas of
software that have nothing to do with money, other than being able to make it.
It's silly to apply the same standards to software that processes $10M/sec (as
one program I once wrote did) as to software that lets you throw virtual sheep
at each other.

~~~
pyre
I also think that it's silly to assume that all software follows the same
rules as software that allows you to throw virtual sheep at each other.

------
throwaway0323
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]

~~~
cdevroe
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.

------
onan_barbarian
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.

~~~
cdevroe
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.

~~~
onan_barbarian
The other point here is that the new code is new code.

The old code may have been old, but maybe it has been running for a long time
without problems. Maybe some of the ugliness of the old code has to do with
handling bugs and corner cases that the programmer has forgotten about.

The boss may not have to maintain the codebase and maintain the code, but
he/she may have to take the heat for things when someone goes and breaks code
that was ALREADY WORKING with their rewrite.

"Why did you let this idiot break our product?" will be the question that the
boss will be asked, in this question, and when they say "Well, I didn't know
that he was making changes for no reason" someone is on an express path to
getting fired.

~~~
perlgeek
> Maybe some of the ugliness of the old code has to do with handling bugs and
> corner cases that the programmer has forgotten about.

That's why I add comments to counter-intuitive pieces of code, often with a
ticket number or a short explanation what goes wrong otherwise.

------
famousactress
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
"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
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.

~~~
astrofinch
But code can be _dirtier_ if its implementation was poorly thought out, half
of it was modified to reflect new assumptions while the other half was worked
around and left intact, etc.

------
netmau5
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.

------
ecaron
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> or
[http://www.codinghorror.com/blog/2009/02/paying-down-your-
te...](http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-
debt.html)). 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
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
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
See also:

[http://www.superwebdeveloper.com/2009/11/25/the-
incredible-r...](http://www.superwebdeveloper.com/2009/11/25/the-incredible-
rate-of-diminishing-returns-of-fixing-software-bugs/)

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.

~~~
nostrademons
"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."

Sure there is - _people writing easily deployed consumer software don't write
code like this_. It's crazy to spend months designing software, based on
things you _think_ you know, when you could just build and release it and have
far more information in far less time. Anyone who writes software where the
deployment cycle is measured in minutes to hours (that's anyone on the web, or
desktop or mobile apps with auto-updaters) relies on an iterative process of
code -> release -> gather data from real users -> refine the product ->
repeat.

People who don't do this get creamed in the marketplace, because their
competition _does_ , and their competition gets far more information to build
a better product through it.

Most of the stuff taught in Software Engineering courses is complete bullshit
when applied to the types of problems that actual practitioners face. This is
because the field of software engineering is far broader than most people can
imagine, and certainly more than you can teach in an undergrad education. A
development cycle like you site is pretty much the norm if you're writing
embedded microcontrollers for avionics (actually, the cost increases are
probably even steeper). Very few people are writing embedded microcontrollers
for avionics. For the majority of us, who're working on software developed and
deployed over the web, the cost curve you cite is ridiculous.

~~~
nikster
Meh.

The best web developers I know are also the fastest I know; they write unit
tests like crazy. They write good code.

I guess you're assuming that writing good code takes longer, which is the
basic fallacy in software engineering. Writing good code is way faster, almost
from the get-go. You reap the benefits on _day two_, literally.

I am not sure what they taught you in SE - I found most of what I learned to
be true in the field, however, I also found it shocking how little this
seemingly common knowledge is used out there.

I directly benefit from the incompetence of most software engineers out there,
but I much prefer to work with good people.

~~~
randallsquared
_The best web developers I know are also the fastest I know; they write unit
tests like crazy. They write good code.

I guess you're assuming that writing good code takes longer, which is the
basic fallacy in software engineering._

You keep saying this as if you believe that writing unit tests automatically
means you've written good code. You can possibly have good code without unit
tests. You can, more importantly, have awful code _with_ unit tests.

For me, a major axis of "good" for code is maintainability. Therefore, writing
good code means spending some time considering names rather than just using
the first ones that pop into your head as you type. It means thinking about
whether these superficially similar pieces of code are really related enough
for code reuse to be beneficial, or whether it's only incidental similarity
and really should exist in both places independently in your codebase. It's
about writing small pieces of functionality yourself when otherwise you'd drop
in a library that dwarfs your written code -- sure, dropping in the library is
fast and easy, but if something goes wrong, you're now debugging 100K lines of
someone else's code instead of the 1K lines of in-house code it would have
taken to do just what you needed...

Writing good code in this way often takes considerably longer than just
cranking out something that works for now, and the largest factor is not time
to write unit tests, but time to _think_ about what you're doing rather than
coding at the speed you can type.

~~~
Stormbringer
"You keep saying this as if you believe that writing unit tests automatically
means you've written good code"

Actually he didn't state there was a causal link between writing unit tests
and writing good code. In fact, if you look closely, you see that there is a
full stop in between those two statements, they are in different sentences!

I'd happily believe that someone who writes good code can also write good unit
tests.

I'd also strongly assert the negative of that. Someone who writes bad code
_cannot possibly_ write good unit tests, because unit tests _are_ code.

Everything else you say I agree with 110%. Good names for code entities: yes,
indeed. Taking some time up front and _thinking_ about the design and how it
will fit together... yes, a thousand times yes.

However, the last bit about it taking longer to do this than just cranking
something out I (and I think the person to whom you are replying) would
disagree with _except in the most trivial cases_.

If what you are doing can be done by banging out a perl one-liner, by all
means do that and move on. Except that of coruse if you _ever_ need to debug
it or maintain it there is a higher cost involved. For all code, _as soon as
you start debugging it_ you start reaping the rewards of doing it properly.
For _non-trivial_ code, those costs will rapidly outweigh the initial savings
of just banging something out.

~~~
randallsquared
_Actually he didn't state there was a causal link between writing unit tests
and writing good code. In fact, if you look closely, you see that there is a
full stop in between those two statements, they are in different sentences!_

Well, idiomatically, the second sentence is a kind of restatement of the
first. My comment was really a reply to all nikster's similar comments in this
page; he's talking about unit tests, and those he's talking to are mentioning
good code, so it seems as though he believes that good code is essentially the
same as "have unit tests", which is what I took issue with. :)

 _For all code, as soon as you start debugging it you start reaping the
rewards of doing it properly. For non-trivial code, those costs will rapidly
outweigh the initial savings of just banging something out._

I actually don't disagree with this at all. It's just that I don't think the
costs will necessarily be in hours spent, though sometimes they will be.
Sometimes the cost will be that you have to find someone at least as smart as
the original coder, and that might be hard. It might be so hard that hiring
someone to completely rewrite the system from scratch might be cheaper.

So, I'm not saying that people shouldn't take the time to write good code. I'm
saying that it's possible to write working code at the speed of typing for
some people on some projects, and this can be kept up for long enough for the
savings to completely outweigh the other costs if the number of bugs is small
enough. I wouldn't recommend depending on this being possible for a given team
and project, but I've seen it done -- I've done it myself. The result wasn't
what I'd call good code, but it worked and it was done in time to be sold for
enough to keep the wolf from the door; if I'd spent half my coding time
writing tests on that one, I would simply have failed to deliver.

------
pilif
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.

------
groaner
_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
Time to move on?

~~~
groaner
I've mentally checked out of this place for quite a while already.

------
aidenn0
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.

------
zavulon
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 ...

~~~
nikster
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.

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

------
tjmc
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.

------
jconley
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...](http://www.jdconley.com/blog/archive/2009/01/26/put-down-the-
abstract-factory-and-get-something-done.aspx)

------
joshuaxls
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
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.

------
asymptotic
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...](http://www.sriramkrishnan.com/blog/2009/12/stuff-ive-learned-at-
microsoft.html)

"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."

------
ojbyrne
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.

------
alextingle
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.

------
trustfundbaby
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.

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

------
esschul
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.

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

~~~
shaggyfrog
Sounds like a hacker's spin on Dan Savage's campsite rule.

[https://secure.wikimedia.org/wikipedia/en/wiki/Savage_Love#....](https://secure.wikimedia.org/wikipedia/en/wiki/Savage_Love#.22Campsite_rule.22)

------
InclinedPlane
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.

------
michaelfeathers
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.

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

~~~
cdevroe
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
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>

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

------
cdevroe
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!

