Reasons for code bloat

Maintaining the code in projects that have been in the hands of several people before you is almost always a pain. Trying to make sense of the front-end code used by a CMS is, in my experience, always a huge time-waster. Cleaning up HTML, CSS, or JavaScript created by people who don’t know HTML, CSS, or JavaScript is another non-favourite pastime of mine.

The reason all those things are no fun is very often code bloat. We’ve all seen it, and we’ve all been guilty of creating it.

What causes code bloat though? I haven’t thought a whole lot about that, but Chris Heilmann apparently has, since he held a presentation on the subject at the Web Standards Group London Meetup on May 16, 2007.

In the presentation, which by the way is so funny I laughed until my stomach hurt, Chris brings up the following reasons for BECS - Bloated Embarrassing Code Solutions:

  1. Wrong perception of time needed to accustom ourselves to a project
  2. Maintenance without using the right tools
  3. Bad or non-existent documentation
  4. People do not read or look before they start
  5. Lack of awareness
  6. Failure to specialize
  7. Lack of a front-end build process

Links to the slides, speaker notes, and a podcast can be found in Chris’ post Seven Reasons for Code Bloat - My presentation for the WSG London Meetup.

Posted on June 4, 2007 in (X)HTML, CSS, Coding, JavaScript


  1. June 4, 2007 by Chris Boudy

    Roger, funny that you bring this up. I am currently writing an article on good coding practices with HTML and CSS.

    Bloated code is at the top of the list!

  2. June 5, 2007 by dbrimlow


    Most of my bloat comes from timing constraints. I work fulltime and have a supervisor (who luckily happens to be my sister). When I finish a draft of a page, she calls me and starts changing placements, colors, sizes. I have to make these changes live - while on the phone, until approved.

    There are times (like TODAY) where I will roll out a whole css I had used on another project that solved an issue pestering me on the current issue.

    I end up with links to 3 stylesheets and a few embedded modifications of it.

    I do try to get back to it and clean it all up when things are slower … but I have some mighty HUGE web pages out there that could be reduced by 80%!

    I KNOW if I was working free-lance I would have it more together. I make sure my side job projects have beautifully lean and placed code … er … well, some of them … when the client isn’t pestering me about something … or when … Oh forget it!

  3. Very interesting presentation.

    I’ve found that 9 times out of 10, code bloat (and most project development issues) come back to failure to investigate potential pitfalls enough before the onset of production, if at all.

  4. Your Google ads are succinct.

  5. Very funny stuff.

    I find refactoring is almost non-existent in the web development world. I’m not sure why, but it is a very well know method to reduce code bloat in other software development areas. You don’t see many books teaching developers how to utilize refactoring in web development, either.

  6. Some code bloat is inevitable, but other times it is entirely avoidable. My life would be a lot easier if people had any idea how to write best practice maintainable CSS and XHTML — let alone valid code. Some of the things I’ve seen would make The Daily WTF seem tame.

    Specialisation is vital. Front-end developers, i.e. people who concentrate on writing XHTML and CSS, are vital. It’s a bit of a joke to expect back-end developers or graphic designers to know all of the ins and outs of valid, semantic and accessible markup. The field is just too complex nowadays for people not to specialise.

  7. June 5, 2007 by Roger Johansson (Author comment)


    Your Google ads are succinct.

    LOL. Yes, they seem to react to the word “bloat”.

  8. June 5, 2007 by Erik Töyrä

    I’m just talking from my own experience of web development now. It’s a fact that every developer, both client side and server side developers, has his/her own way of writing their code. Thats why it’s so important to sit down and take the time to find some coding conventions that all can agree on. Write down how you as a group of developers should name the tags, variables, functions and how to document your code etc. Me and my colleagues have a three page long agreement on the above things that we can apply to Delphi, PHP, JavaScript, XHTML etc. It’s a simple solution but it saves us a lot of work. Offcourse this mostly applies to when working in-house and not having to deal with code from clients etc.

    Luckily I’m one of those who seldom have to deal with bloated code from clients anymore. I used to be one of those poor bastards. I say never ever again! :)

  9. Funny you should post about this now. I just finished refactoring the last of 44 files absolutely covered in tag-soup.

    Instead of normal <hN>-elements he’d used an entire <table> together with a couple of <font>s and <b>s for headings… and that’s just a fraction of the mess i was in.

  10. I think a very important reason should be added - using developers that are not really interested in the project. The symptoms might be one or several of the reason you list. Often the real reason is uninterested developers that do not dedicate themselves to the task. It is important that project managers, and managers in general, understand that they need to have the right people in the right places.

  11. June 6, 2007 by Chris bakker

    i’ve seen the presentation, but why he is using:

    *{margin:0;padding:0;} (slide 58)

  12. to add few other reasons 1.non tech guys trying to change some content. 2.developers think that HTML and JS are very simple and never try to enhance their skills

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.