70

I'm only a junior developer but my job forces me to work with really terrible PHP code (think about the worst PHP code you've seen; then think about code twice as bad). I usually try to fix bugs and fight with the codebase to add new features. Sometimes I'm ordered to get things working ASAP which more often than not involves dirty hacks.

The product was previously open source and I am concerned that it might go open-source in the future. I would be ashamed if someone (especially potential employers) could find my name next some of the changesets. What can I do to protect my good name?

I am not sure if this is relevant but I'll add that neither my boss nor my colleagues want to admit that the code is bad, but I'm not sure I can blame them for that -- for many of them this is their first job.

Improve this question
23
  • 21
    How are you forced to write bad code? Why can't you stand up, stop putting your name to bad code, and explain the problem, the solution, the cost in terms of time, effort, and money, and the benefits of fixing the problems now to your superiors?
    – Thomas Owens ♦
    Jul 6, 2011 at 0:30
  • 17
    "encouraging quick and dirty hacks"? Encouraging? Which is worse. Your pride (and finding a new job) or sticking with this job. It may not be bad to stand up for what's right. What's stopping you? Threats of violence? Blackmail? Criminal proceedings? Seriously. What stops you from writing good code? Please be specific. And honest.
    – S.Lott
    Jul 6, 2011 at 0:41
  • 114
    If it's any consolation, even good code you write today will look bad to you in five years.
    – Kyralessa
    Jul 6, 2011 at 1:14
  • 7
    face it PHP encourages "quick and dirty" by not discouraging it and making it easy to d matter of fact I would say PHP excels at "qucik and dirty" better than any other language, except maybe Perl, once that momentum is established it is hard to stop especially if management is encouraging the behavior as well. In the end code that appears to function, regardless of practices is more valuable to the company than no code at all.
    – user7519
    Jul 6, 2011 at 1:18
  • 8
    Sorry but there are right and wrong ways to write code. The right way uses standard industry practices; the bad way hacks together shit and says it "works".
    – Wayne Molina
    Jul 6, 2011 at 12:20

10 Answers 10

Reset to default
132

Rome wasn't built in a day, but you can be a good 'Boy Scout'. Every time you touch the code, leave it better than it was before. It doesn't take an extraordinary amount of time to use sensible function names, good coding standards and put decent comments in when you work.

I think the danger is thinking it's all or nothing. Just because you can't spend the time you want to write elegant code, doesn't mean you have to totally give up and write garbage.

Improve this answer
8
  • 2
    +1. You don't have to sacrifice everything you believe in just to make it a quick fix.
    – tdammers
    Jul 6, 2011 at 6:04
  • 4
    +1: for all or nothing - very true.
    – Umber Ferrule
    Jul 6, 2011 at 8:42
  • 3
    The Boy Scout rule in the wrong hands can exactly be what causes the problem, because the definition of 'sensible function name' of his superiour could be 'bolChkLst' (hungarian notation to meet the styleguide, ChkLst instead of CheckList because 'shorter is better'). Here are some Boy Scout Rule implementations i encountered at different jobs i tried not to follow: 'Join functions, to have as few as possible', 'dont carry arguments through 3 calls, use globals instead', 'use inline SQL in views to make it quicker'
    – keppla
    Jul 6, 2011 at 11:06
  • 41
    +1 for Every time you touch the code, leave it better than it was before.
    – Qwerky
    Jul 6, 2011 at 13:00
  • 3
    +1. If you have lots of clear improvements committed, anyone who actually looks at your contribution won't think you're a crappy programmer. Potential employers who assume you're crappy because the project is crappy aren't people you want to work for.
    – Matthew Read
    Jul 6, 2011 at 15:13
60

Agree with S.Lott from comments* (for once :) No one is forcing you to write bad code. The thing is, junior dev. often (this site is also to blame for that) get lost in best practices, "beautiful code", ... whatever you wanna call it ... and they don't get much done; or they get it done but waste a lot of time. By telling them to write bad code (which is code which also works) it gets than "through that", just makes them deliver something. As time passes that results that a (now no longer :) junior dev very quickly comes up with a quick&dirty solution, but spends the rest of the time improving it. And as time passes, you learn more, and at some point you start delivering quick&dirty solutions which are actually good code.

But, if you went your way and tried writing perfect code from the start you most likely would've spent a lot of time, and done almost nothing.

So ... write bad code, ... lots of it ... code that barely works, and then ITERATE. Every iteration a tiny bit better!

No one wrote the perfect solution the first time.

*this, were it shorter would've been a comment.

Improve this answer
7
  • 1
    +1 I strongly agree with this answer. I'd upvote you twice.
    – Vitor Py
    Jul 6, 2011 at 1:16
  • 3
    I agree. This is a great way of cutting through "analysis paralysis," which can take hold as you try to reach the "perfect" solution to a problem. I wrote something similar on StackOverflow .
    – Kyralessa
    Jul 6, 2011 at 1:17
  • 4
    +1. I have read this on programmers already (but don't know the source): two groups were tasked to create pottery within a given time frame. One to create an item of the best quality possible and one to create as many items as possible. In the end, the latter group provided items of better quality, because repetition is the path to mastery. Contemplation alone will get you nowhere. In the end, we all learn by doing and our fear of doing something wrong is what holds us back in trying, possibly failing, but definitely learning from our mistakes.
    – back2dos
    Jul 6, 2011 at 1:32
  • 1
    As a corollary, use a repository! Even if it's just a personal one you've set up on your own machine. After you start using them, you realize how liberating it is to make a bunch of changes, find out it didn't work, and roll back. My personal fav is fossil
    – Spencer Rathbun
    Jul 6, 2011 at 15:19
  • 1
    "So ... write bad code, ... lots of it ... code that barely works, and then ITERATE. Every iteration a tiny bit better!" What if you just never get to iterate because new projects keep piling on... and you start to realize that what you push out as alpha tends to stick around till the project dies. Which of course is sped along as a result of initially shitty code and lack of updating. I think it's these kinds of situations that lull many junior devs into thinking they need to write "beautiful code" from the get-go...
    – Serhiy
    Jul 8, 2011 at 15:49
40

Code comments are your friend here.

Whenever you feel like you have to write some cheap hack because of pressure, just say something like, "This code does X because of time constraints. Ideally, I would do Y instead. - Ashamed One, 5 July 2011"

Then if potential employers see it, they'll realize you prefer to write good code, but you're also willing to adjust your coding style to business needs. Most employers will see both of those as good things.

Improve this answer
6
  • 4
    Exactly. Comments and commit-messages too. I've never done it, but it would interesting to evaluate a developer based on nothing other than annotated changesets attributed to them in some vcs.
    – timdev
    Jul 6, 2011 at 3:52
  • well, you can tell something about someone whose commit comments are "fixed", "done", "blahblahblah" :)
    – gbjbaanb
    Jul 6, 2011 at 12:33
  • +1 I've done this several times and in case of peer developers it just works.
    – Jacek Prucia
    Jul 6, 2011 at 12:37
  • 7
    I generally delete comments like that whenever I run across them. A comment marked as TODO or FUTURE-ENHANCEMENT might deserve to stay, but apologies are just garbage.
    – Kristopher Johnson
    Jul 6, 2011 at 15:14
  • 1
    Agree with including an explanation as why a less than optimal solution was implemented (and what that solution might be) I do this from time to time. However I don't think it is anything to be ashamed of or apologize for. It just means there were more important things to do at the time you were working on that piece of code and that the given implementation was sufficient.
    – Justin Ohms
    Jul 6, 2011 at 15:37
10

It depends on how they force you.

In my experience,there are two possibilities:

You feel forced by a tight schedule, legacy code, etc.

In this case, as most of the other answers already say, it's up to you to 'optimize for coolness'. You may not have the time to rewrite the codebase to MVC, but as first step, for example, you can stop glueing your SQL by hand and instead write a nice execute_sql($query, $params), that lays the foundation for abstractions like fetch_customer($filter_params), etc. Remember, all the best practices are ultimately there that your boss gets a product earlier, so there is only a conflict in how much time to invest in the future vs in the now.

When you set the right context ('within 6 month, without getting extra time, i refactored the monolithic code to MVC') you should leave your name on the code, and try to be proud like a therapist, that teaches a stroke victim to say single words again.

You are explicitly ordered to implement it a way you deem unfit

The try to separate view from model does not survive the review, because 'it is too complicated, why dont you just do plain sql queries?'. Your execute_sql gets canned because 'a coder with discipline does not need that'.

This case sucks bad. In my experience, it usually comes with micromanagement and teamleaders who got promoted there for political reasons, not for their successes. The real problem is, that you are put in charge of something (the code) that you can't control (you have to do it their way). The best solution would be to solve the root cause (i.e, that you are treated as a grunt). The second best (and in my experience, the usual) solution is to quit.

The upside is, that in this scenario, your name isnt likely to get published anyway, because the team leader takes the credit for all success.

Improve this answer
8

I'm pretty confident your boss demands you deliver something fast, but not that you take any extra effort to make it deliberately bad. Which means that whenever you have a choice between really bad code and slightly less bad code, and both options would take you equally long to implement, you go for the slightly less bad option. That's the short-term solution, and it doesn't require any effort at all.

For the long term, talk to your boss. Explain how investing 15 minutes here can save hours there. Make sure you have convincing examples - not the type "if I did this and that here, my hope is that I would be able to do this other thing next year", but rather, "look, here I did this thing, and because of that, it took me three hours to find the problem there; if I had done it this and that way, the bug would have been apparent right away". A warning here: while elegant and maintainable code feels much better and more efficient, sometimes it isn't. There are situations where a sloppy quick-fix is perfectly justified: sometimes you are writing single-use code, sometimes you are keeping an outdated piece of junk alive, awaiting the real thing; sometimes, the benefit of a proper solution doesn't justify the effort (money-wise, which is all your boss is interested in).

If all else fails, go find another job.

Improve this answer
3

Nobody forces you to write bad code. You can turn this situation around and make it a positive. Pioneer change for policies and procedures. And you can't always be the "yes" man/woman either. If they say they need functionality x before the end of the day, tell them it is not feasible, but give justifications why indeed it is not. Where there is a problem, offer solutions. Not just a blind eye, or worse...adding to it.

Your dev shop isn't the first to have strict deadlines, while still having the desire to maintain well-engineered code.

Improve this answer
8
  • 4
    -1: In the US, if your boss says "Write fast crappy code", and you refuse to do it, they can fire you. Disobeying a direct instruction to do something that's legal is grounds for involuntary termination. So while that may not be "forcing" you, the alternatives to doing what your boss says may be much worse.
    – Bob Murphy
    Jul 6, 2011 at 1:19
  • It all depends on your approach. Ideally you would have a superior figure that would value your expertise and your judgement should be highly regarded. Often times the people dictating timelines aren't developers, and they should take into consideration what is possible and what isn't. Of course you could write "crappy" code under the covers, but the push back might be enough so that everybody is happy: good results from good code.
    – user29981
    Jul 6, 2011 at 1:21
  • 1
    Ideal superior figures you don't actually work for are great, but the person who signs your paycheck is the one you have to please. Having bill collectors call at all hours when you're out of work really, really sucks.
    – Bob Murphy
    Jul 6, 2011 at 1:28
  • 1
    There's more to it than raw self-interest. I've been a manager and entrepreneur, and I can assure you that if all the customer is paying for is quick-and-dirty, doing a good job that loses money will lead to people being laid off. I had to lay off an entire company once, and I never want to do it again. So while I'm definitely in favor of taking moral stands... writing crappy code usually isn't a moral issue, and at some point one must choose between personal preference and the practical issues of people having or not having jobs.
    – Bob Murphy
    Jul 6, 2011 at 4:06
  • 1
    I would almost never advocate a large-scale rewrite of a big system, but that doesn't mean that the code you write in the future has to be horrible.
    – PeterAllenWebb
    Jul 6, 2011 at 19:13
3

Any company needs to find a balance between writing brilliant code, with extensive documentation and unit tests and getting products to market in a reasonable budget and time space.

The best code in the world doesn't matter if it obsolete before it is released.

Being pragmatic is about trying to find that balance. Getting features fixed quickly may be commercially essential at the moment, it doesn't mean it always will be.

It takes a lot of experience (More than most coders ever have), to get this balance right. It is very easy to go for either extreme. Finding a middle way is more difficult.

I'm not saying your boss is right. As a coder there is a temptation to try to constantly create beautiful code which is not commercially viable. Being mindful of this temptation may help you to realize that some of these hacks aren't too bad.

Most code after enough time will contain hacks for specific situations which were too costly to refactor into a general framework.

Improve this answer
2

I'd like to add that you shouldnt just continue like you are doing it now, sayning nothing and just hacking and hacking.

You need to stand up and point at concrete code and tell them what sucks about it. Be specific and use code metrics to back up your claims. Nothing is more embarrassing than claim a code is bad when in fact its not, you just didnt understand what was being done.

I am sure there are many tools available free to use for php code analysis http://en.wikipedia.org/wiki/Code_analysis

Also, of course this http://en.wikipedia.org/wiki/Code_smell

Read it up, sum up what you can find in your application, and of course list alternatives. Its bad practice to just stand up and shout "I dont like how this is done" without presenting an alternative (preferably) better way to do it.

Quick hacks cost money. And dont see it as entirely negatively - You can learn a lot from this job now and can profit from the experiences you now make in your next.

hth

Improve this answer
0

Before anything else, you DO use source control of some kind, right ? If not, start from there. It will help you first and be adopted by the rest of the team quickly.

If you have source control, you should not put your name in the code, just put the name of your company. It is common in bad code to put a revision history in the comments at the top of files, this is better delegated to source control.

Now, regarding the code quality, you will not be able to change it as a big bang approach. Slowly, one by one, add new approaches to different issues. If you do it right, it will SAVE you some time and you'll use it to make the overall quality better.

To give you an example of mine, I once arrived in the middle of a project with a Perl/CGI application where all HTML was in the code. The whole app was in a single file with no clear structure. Nothing was versioned. I started by configuring a CVS repo (no SVN available at the time), put a web interface on it for the customer. At first, I was handling the commits from my colleagues myself. Then, I split all methods in different modules (files). At that point, the colleagues started adopting CVS. Then, I moved the HTML out of the code. Then, every time I had to do a change in some part of the code, I took a bit of time to refactor some of it. In the end, the development velocity had increased so much that the customer was extremely happy. They would request a cosmetic change and instead of us telling them "it will take 2 days", I changed it on-the-fly in the dev environment.

This approach however will only work if you master the overall code well enough. If you don't understand the big picture, if some parts of the application remain unintelligible, it will make your job really hard.

One last thing, a complete rewrite is sometimes the only solution but it is usually very hard to justify its cost to management.

Improve this answer
0

Since you are a junior developer, this is actually a good thing. Being tossed into the middle of a big ol' mess of code will teach you far more about what not to do than only working on perfectly 'clean' code would. Take advantage of the situation and learn how to refactor the bad code and slowly convert it into something more managable. And dont complain about it having to be ASAP. Thats the point - learn to refactor and clean up code while doing things under a tight deadline. After all, anyone can write perfect code if they have endless time available.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.