The Developer’s Worst Excuse

December 5th, 2007

In my opinion, the worst developer’s excuse for bad code is: «I didn’t had much time, so I did everything the fastest way possible…». The problem is that this excuse is always present. Developers always have tight schedules, and sometimes they also have several tasks to do at the same time. The day-to-day stress frequently moves this excuse from being just an excuse to be something more like a development mindset.

And usually this fast development methodology translates to:

  • A lot of copy paste
  • No objects for the base project concepts, instead intrinsic types are used
  • No unit tests or refactoring

I really don’t think that the lack of time is a good justification for bad code quality. In fact, I think that with proper analysis and good architecture, the development will be faster. The fast development methodology may be quicker on the short run, but everyone knows that maintaining this kind of code is very error prone and quite complex. And sometimes some simple modification will be very delayed just because things weren’t done right the first time.

When you have bad code, you’re sticked to it. It’ll never improve, unless you totally rewrite it. With no unit tests, no one will take the chance of refactor code that’s already working, and you’ll have the «can’t touch this» effect.

Related Posts

23 Responses to “The Developer’s Worst Excuse”

  1. Nuno Silva Says:

    That is true. Is really an excuse, because where we work, the time you have to do an project is more than enough to architect a good solution.

    But the developers prefer the easy way: copy paste (equals spaghetti code).

  2. JP Antunes Says:

    I totally agree with you here.

    I’ve learned that the old saying “If you don’t have time to do it right, when will you have the time to do it over?” is spot on for software development.

  3. Vlad Says:

    To do well, takes less time in the long run.

  4. raveman Says:

    it must be nice to have no deadlines, i should try that too.

  5. Nuno Silva Says:

    A deadline is also an excuse for bad coding…

    It’s not because you do bad code, the project will be completed faster. It’s the opposite.

  6. Sashidhar Kokku Says:

    I could not agree more. However, a deadline to meet always for a piece of code relies on the notion that a similar piece has been done before. And the management thinks that since we did it then, it should not take too long to repeat the same. However, they dont realize that there are potential changes/tweaks that need to be made to this new piece of code.
    It is the developers responsibility to stand up for him/her-self and tell his/her boss the potential issues that could come up if a stupid deadline is placed on the developer’s head. That would enable to developer to think properly before taking up any task and do a good job of whatever he/she lays their hand on. The sad state of developers now is that everyone is worried about their job, and hence don’t want to stand up and talk whatever they think is right/wrong.

  7. pedro Says:

    We always make 2 side-by-side projects: one for show (to the boss - nice and beautiful graphics but bad and fast coding ), and the other one dedicated (readable code and easy to maintain). It just keeps your boss happy WHILE keeping your “real” code healthy…

  8. Bruno Antunes Says:

    This is a bunch of BS. As a coder, I totally agree (obviously, how can you NOT agress with this?), but alas the world is managed by idiots who do not have such a notion of finesse…

  9. Nick Brown Says:

    There are two ways to measure the amount of time it takes to do something. One is how much time it takes you, a particular developer, to do a particular task and report it as complete. The other is the net amount of time it adds on to the project as a whole being completed. You are right on the fact that taking your time helps the later measure, but the former is what most programmers are evaluated on by management. Yes, your crappy code might cost the project a few more months because of all the bugs it introduces and the difficulty in maintaining it. But if it means you took a week less to complete your assigned tasks, it will make you look good. In effect we see a Tragedy of the Commons type of game.

  10. Cordwainer Duck Says:

    You’re half right. A tight schedule does not justify bad coding, *provided that schedule is reasonable*. Reality check: there are entirely too many shops in which management commits to a delivery in X months before even the requirements are laid down, and staff will by god deliver in X months, or else. If a proper delivery happens to require Y months, you’re going to cut corners whether you like it or not. These shops also tend to be places where, if you challenge the schedule as Sashidhar Kokku advocates, you’ll instantly be branded “not a team player” and marginalized or removed in short order. (I have experienced this, and witnessed it first-hand only two years ago.) Never underestimate the disruptive power of bad management.

  11. David Walsh Says:

    I agree completely with the author, but Bruno’s point is the one that matters. I can’t tell a customer to wait another week so that I can do something “right.” I can’t make my boss schedule more time for me to do something.

    Business is business. Management and customers are ignorant to how the coding process works, so don’t count on them to.

  12. doylecentral Says:

    This implies you have time for a code review? To catch all this bad code. It’s the managements fault and the developers. Also, maybe sign of a weak developer or jr. Someone should be working with that developer.

  13. Jai Says:

    Well Yes…

    There are certain times when the deadline is forced upon you and you have nothing much of a say. All it matters to the company is not an excellent architecture but something that works given the time.

    The attitude of the organization is to get the thing working and there is no code review etc. What works is fine…

    I would prefer to code the best as of my knowledge but sometimes it is just not possible given the deadline.

  14. whatsup Says:

    Code review catches bad code? 90% is does not. Most of the time: indentation, code styles, more comments are all you get from code reviewers. About unrealistic schedule forces down your throat? yup. I’ve been there, worked 90+ hours/week to keep up. Got paid for it so no complain there. Yes, challenge the schedule and if management is not listen then it is time to work on your resume. This kind of project will be doom sooner or later so jump first before the whole team get lay-off(except the management).

  15. prashant Says:

    Hi,

    Good post and totally agree with you.

    Thanks
    Prashant Jalasutram
    http://prashantjalasutram.blogspot.com/

  16. bmpc Says:

    Well I think the question is:
    do you work in a company or project where they value code quality?

    If the company doesn’t value code quality, the managers won’t be worried about that and they wont prepare things for people who actually want to do things properly.

    Anyway, a code hack is a code hack, but, sometimes, you need them. When everything is a hack, and you don’t like it, you need a new job.

  17. Drew Says:

    Well.. maybe I’m a stick in the mud but funny when I read a post about work quality and then see this:

    “day-today”

    It’s “day-to-day”. If that was code it wouldn’t compile. Let me guess you wrote this quickly and “didn’t have time” to double check it. :)

    Just poking some fun but truthfully if you’re going play the role of perfectionist.. it comes with the territory.

  18. Drew Says:

    Oh, otherwise I also totally agree :)

  19. Pedro Santos Says:

    Hello, Drew. You’re right, it was a typo. Thank you. I did the double checking, but I just missed it. Yes, just my fault. :)

  20. jimako Says:

    Errr. This is a little simplistic. In the real world, it MIGHT be necessary to compromise quality to meet a deadline. There’s a trade show you need to demonstrate a release at, and there is simply NO way to write all the code and automated tests to the level of quality you want — NEED — for the long-term health and maintenance of the system. What do you do? Do you miss the show? It might well be that your company is then not around long enough to benefit from all the quality you are building in! In the real world, you lower the quality — and incur the technical debt — in order to meet the deadline.

    Then you pay back the debt, with interest.

    In a well-managed project, you do this consciously, fully aware of the interest charge and only when the outcome warrants the debt.

    In projects that are NOT well managed (probably most of them, unfortunately), this is done without realising the cost, in order to meet arbitrary deadlines that have no intrinsic value at all, all the while oblivious to the interest cost that is being incurred. THAT’S the real issue here.

  21. phloidster Says:

    OK, everybody, now get back to work! Don’t you know we have a DEADLINE!!!!!!!!

  22. The Links « rewrite Says:

    [...] The Developer’s Worst Excuse [...]

  23. Николай Конев Says:

    Мое ИМХО, эта тема довольно сложная для новичка :)