Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I would like to hear what kind of design decisions you took and how did they backfire. Because of a bad design decision, I ended up having to support that bad decision forever (I also had a part in it). This made me realize that one single design mistake can haunt you forever. I want to learn from the more experienced people what kind of blunders have they experienced and what did they learn from them.

I'm sure this will be a lot of help to other programmers by helping them to not repeat those decisions.

Thanks for sharing your experience.


locked by World Engineer Jun 6 '13 at 11:05

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as not constructive by World Engineer Jun 6 '13 at 11:05

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

spending too much time on SO!! ;) – Mitch Wheat Sep 24 '09 at 14:26
@George: seems like your first link is about over-engineering, which can be tangentially related to this thread, but its not a duplicate. The second and last links concern coding errors and management fumbles, neither of which are duplicates of this thread. – Juliet Sep 24 '09 at 14:33
This should probably be made into a community wiki (there's a box when you edit the post). – ilya n. Sep 24 '09 at 14:47
I wish there was a way to vote to counter the close. Downvote a close? – Kieveli Sep 24 '09 at 14:51
What is wrong with all the closed voters? So what if it's not a CW let the asker get some votes for coming up with the question. I'm genuinely interested with this topic. Don't let CW get in the way of good subjective question. Sheesh, SO is full of "CW THIS" screamers. – syaz Sep 24 '09 at 15:03

42 Answers 42

Rewriting working code. Hell the result works great, it's got less bugs and it's more maintainable.

But the customer could care less and it cost my days of dev time...

Nope, dont write crap code in the first place (: – Jacob Sep 25 '09 at 10:14
Any mention of the word "maintainable" is a process smell. – finnw Oct 1 '09 at 13:57

Trying to utilize the Nth element of a circular buffer [N-deep] between 2 processors. Now I never-ever use more than N-1 elements to keep it simple and reliable.

The issue: a circular buffer containing no more than N-1 elements can be realized completely threadsafe (pure producer/consumer). When I optimized it for N elements, the queue sometimes toggled from full-to-empty (data loss) or from empty-to-full (invalid data).

Trying to find this in a complex system (1 corruption on every 100Mbytes of data transfer) is harder than finding a needle in a haystack.


Using flash to build a site because the "designer" wanted a carrousel of photos (that was years ago, jQuery didn't exist). Later it turned out that the designed wanted to change everything once a week because he changed his mind about the design... What a maintenance nightmare.


At my last job, I wrote some largish projects using an in-house scripting language which didn't support classes, lists, and the only "include" mechanism was including one file in another.

In hindsight I could have written it in .net or python and half my extensibility issues would have vanished.

What sort of madhouse has a in-house scripting language :) – whatnick Sep 24 '09 at 18:44
@whatnick, probably most software companies do. – finnw Oct 1 '09 at 14:03

I once designed the business tier of a client server application so that all calls would be asynchronous. I thought it would make it easier to manage scarce resources on the server side (it was 1997 and there were major bandwidth constraints). Turned out it didn't make much difference in how we managed the server but made the client hellishly complicated.

Needless to say there was a very quick refactoring about 4 months into the project. And I learned that simple architectures that play to the strength of your tools are always the best.


Tight coupling of components that, with hindsight, had very little to do with each other. Said components have since been copy-pasta'd into oblivion by other devs wanting to use only a small part of the functionality. :-(


Listening to Joel and trying to extend a piece of software instead of rewriting it.


Failure to fully determine specs before starting a project on a client's server. I said PHP (meaning >= 5.2), they gave me PHP 4, I said, "I need a database," (when they finally replied), they said, "Ok, you create the table, and we'll put it in our database..." (I also failed to mention the desire for Apache and not IIs). It ballooned out of proportion, it cause several sleepless nights, and it is one of the worst piece of dung I've ever built. The only benefit I received was that I gained much better understanding of PHP 4, something I did not want to begin with.

If I could go back and do it again... I wouldn't.


Using OO and polymorphism when a procedural approach would have worked better.


what else is worser than this

commented out the problematic lines, and it turned to be the login call. :(

Do you remember that huge bug in Debian's SSL, on and a half year ago? ... – Arthur Reutenauer Oct 9 '09 at 19:15

At my previous job, I was responsible for building an automated-testing framework. Background: We already had a "prototype" which was pretty good and had many tests written for it. It was written in TCL.

For the new project, I was supposed to adapt the prototype to fit a new project. I really disliked TCL, and had just learned Python, so I was clamoring to apply that new knowledge somewhere. So, of course, I decided to re-write the prototype in Python. Since we wanted to do lots of really cool new things (support hierarchical tests better, have all sorts of extra mechanisms to easily create new tests), I justified my decision by saying that writing all this new stuff in TCL would be a nightmare.

In the end, most of the new features (which were way too difficult anyway) were never used. We ended up reimplementing the entire prototype from scratch for almost no reward.

The best part? About a year and a half later, we had to drudge up the old prototype to run some tests on the old project (foreseeable that this would happen). I was worried we'd have to adapt it to some of our new tools (one of the reasons I opted to reimplement in Python). Turns out it took about 2 hours of work.


Overusing the Singleton pattern.

This is something I did a lot earlier on in my career. Before learning much about TDD and unit testing especially, I made pretty much anything that logically only exists in one place a Singleton. In many cases it didn't turn out too bad, as long as that code base never had to be retrofitted with unit tests - but that's a huge infliction of potential technical debt.

Also, this style of coding often led to some of these Singletons becoming God Objects of sorts. Often as a kind of utility class which does almost everything related to that area of the application.