This is sort of the opposite of https://softwareengineering.stackexchange.com/questions/121571/is-there-an-open-source-project-that-can-be-an-example-of-well-written-code.

I am teaching software engineering to undergraduates and I would like a blob of object oriented code that demonstrates tight coupling, bad abstraction, low encapsulation, poor maintainability, the works. Anyone have a good example? Something that is digestible (as in, able to skim in an hour or less) would be great. Thanks in advance.

  • 2
    I don't know of a complete project, but you can probably find snippets at thedailywtf.com Commented Jan 10, 2012 at 21:03
  • 1
    You work at a school and you're asking us where to find poorly engineered code?! The caliber of student projects must have improved considerably since I was in school :-) Commented Jan 10, 2012 at 21:05
  • @FrustratedWithFormsDesigner: yes, they tend to be on the very small and obviously wrong side. the subtle problems of very tightly coupled code are a bit different. thanks for your interest in this question.
    – Alex Lo
    Commented Jan 10, 2012 at 21:07
  • @KarlBielefeldt: yes student project have problems but are somewhat small in scope. i want to present a project where blowing it up and starting over again is obviously difficult. thanks for your interest in this question.
    – Alex Lo
    Commented Jan 10, 2012 at 21:09
  • How big are you looking for? It's hard for me to reconcile big enough not to blow up and start over, small enough to be digestable. Also, what languages would you want.
    – psr
    Commented Jan 10, 2012 at 22:23

5 Answers 5


You might Google for "refactoring". Often there's a before-and-after picture or even a step-by-step process that can supply you with a "bad code" starting point.

If that doesn't work, why not teach them how to write bad code? It might be an interesting exercise in contrarian thinking. Post the "rules of bad code" on the blackboard/whiteboard:

1) Try to bury misspellings in method names
2) Use extremely short, long, or meaningless variable names
3) Try to reuse variable names or similar variable names in different scopes
4) Write lengthy comments that either don't match the code or are meaningless (getSalesTax - a method which gets the sales tax)
5) Put as much functionality into a single line as possible

Others are welcome to add the missing 95 rules to this answer.


While still a student project, I shamefully submit part of my capstone project. It is open source software written in Java.

It is large enough that you probably wouldn't want to scrap it and start again.

It features some absolutely horrible constructs, but should have enough structure to make some key sections palatable.

Disclaimer: We only had 3 out of 5 team members and were self-teaching ourselves Java as part of the project to make it more of a challenge.

I will be available for questions/answers or anything else if you end up looking at it.


Truly dismal code doesn't often last long enough for people to notice. You might want to check out inactive or pre-alpha projects on sourceforge for a start.

Also, Clean Code by Robert Martin has a lot of before and after examples taking those sorts of concepts one at a time. Not exactly one canonical example, but that's one book I wish every new hire had read in college.


You might want to specify the language you're searching for a project in. About a year ago I wrote a client and server for four-dimensional go in C++ with Qt. It is about 4,000 lines of code if I remember correctly, and should work on both Windows and Linux.

The code abuses exceptions, tight coupling (I think there's even bad friendship somewhere in there), RTTI, uses a ridiculously bad network protocol (which is entirely undocumented), and has at least two classes that do way too much (Server and Client). Oh, and it lacks any kind of unit tests. It took me about three weeks to write if I remember correctly, so it may be too small.

Feel free to contact me with questions/complaints if you choose to use it.

I think an interesting way of generating such projects would be to take existing student projects and then demand that students add features to them in a timespan that is not quite long enough. After a few of those, which probably get tacked on quickly, you could teach them to refactor and then request another feature at the end (in a similar time slot) to further demonstrate the benefits of what they've learnt/done.

  • What is bad friendship? Commented Jan 10, 2012 at 23:50
  • 2
    @Morawski - Giving a class friends in order to avoid design a proper public interface for it, as opposed to for extending such an interface.
    – Komi Golov
    Commented Jan 11, 2012 at 8:25

Pretty easy, think of a project, have the person/group code it up in a day or two and then walk them through why it is bad design. People learn a lot better than it is relevant to what they know (in this case, their own code).

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