Should I take the time to clean my code once it's working if it isn't clean? Cleaning can take a lot of time. My boss just need it working but I feel unhappy if my code isn't clean.
Asked
Active
Viewed 353 times
4
-
Only cxphong can answer that question. – Jon Raynor Dec 22 '16 at 16:29
-
4Yes, it's called [refactoring](https://en.wikipedia.org/wiki/Code_refactoring). – PM 77-1 Dec 22 '16 at 16:29
-
rather blatant duplicate of [How can I convince management to deal with technical debt?](http://softwareengineering.stackexchange.com/questions/43948/how-can-i-convince-management-to-deal-with-technical-debt) See also: [Does craftsmanship pay off?](http://softwareengineering.stackexchange.com/questions/82159/does-craftsmanship-pay-off) – gnat Dec 22 '16 at 16:40
-
If its a small scaled project, something which 5 - 10 people will use and you do not see the project growing in near future. Than you should not worry too much about clean code or clean design. You will end up over thinking about the right design and clean code. However if the project has a very likelihood to get bigger, than you should follow the right design practices. Remember code that works is still VALUE! – Haris Ghauri Dec 22 '16 at 18:22
5 Answers
4
The wisdom of investing time into code that is "beyond functional" - more than you strictly need to get something to do what you need it to do - depends on your particular environment.
One-Off Code
If you never intend to use code again, often in the form of throw-away prototypes, proof of concepts, etc, it might not make sense to go beyond the minimum it takes to get the job done. Dirty hacks can be a valuable time-saving method.
It's a Race!
In some businesses, especially startups, sometimes coming in second in "time to market" is just being the first loser. Blowing a funding round because you weren't willing to do absolutely everything to get the key milestone in the minimum time can sometimes mean you are just out of a job entirely. That code has become a "one-off", because it probably won't ever be used again.
Again, dirty hacks abound and you might very well need to throw out what you come up to hit the most immediate goal, if your company survives long enough to care about the 1-2 mark. You can either plan to refactor heavily, rebuild if what your new goal is just isn't compatible with what you have (which is rarely ever a good idea, but it can make sense if you really chose wrong on technology/platform, or you are making a big strategic pivot), or suffer through the mess and risk having technical debt overwhelm your ability to respond to market/customer need.
You Write It Once, Everyone Else Reads It 100 Times
Especially when you are in a stable organization or with large teams, code that is hard to understand, hard to read, and ultimately hard to maintain can be a highly costly liability. When the average application lives 5-10 years and will be worked on by dozens of people, saving 1-2 hours of your time instead of cleaning things up, improving naming, and documenting appropriately, can easily cost an order of magnitude of time waste across the codes lifetime.
Learning What Is Good Enough Is an Art, Skill, and Wild Ass Guess
You can always improve code. I don't know that I've ever seen code that is perfectly eloquent, and the time taken to produce it regularly would likely be so prohibitive that it would not make sense in any environment. For all the value of craft, most programmers are not hired as fine artists - more like commercial artists, where deadlines and costs matter. Every program you write is not a magnum opus, so you need to find a balance between "I could make this better" and "it's horrible, but it works".
The right trade off will vary by project, person, team, and possibly even by time of day/week/month/year. The more you practice clean coding, the easier it will be to produce it, too, so you just have to adjust your "cleaner/faster" dial to suite your situation.
BrianH
- 6,092
- 1
- 21
- 23
3
This is the core idea behind code reviews: to make code cleaner after it works, to keep it maintainable. But I guess in your company you don't even do code reviews, otherwise you would not have asked. So start with that.
However, I recommend heavily to avoid getting code too dirty in the first place. Next time you add something to an existing code base, try to follow the "boy scout principle": leave the place (code) behind in a better shape than you found it. Then this question becomes obsolete.
Doc Brown
- 199,015
- 33
- 367
- 565
-
1+1 for the Boy Scout rule. It's the only reasonable answer to a hopelessly vague question. – Robert Harvey Dec 22 '16 at 16:38
2
In my experience, if your code is not clean, you have no idea if it "works well" or not. Cleaning code as you go is part of making sure it works well, not merely cosmetic. It is very difficult to see mistakes in boundary conditions, duplicated code, rarely-exercised code, etc. in messy code. Messy code is more difficult to test. It's more difficult to debug. It's more difficult to change without causing regressions.
My only quibble is that you shouldn't wait until you're "done" to clean your code. Do it along the way, a function at a time, a class at a time.
Karl Bielefeldt
- 146,727
- 38
- 279
- 479
0
Yes
You can spend the time now to pay down the technical debt, or you can wait and spend a lot more time later fixing the inevitable bugs.
Dan Pichelman
- 13,773
- 8
- 42
- 73
-
Well, sure. But how many firms have you worked for that think like this? – Robert Harvey Dec 22 '16 at 16:32
-
-1
NO
Unless your company is invoicing for the work, don't do it.
Advanced user answer:
NO
You should have done it the first time around.
Ewan
- 70,664
- 5
- 76
- 161