Most regrettable design or programming decision you made? [closed]

Question

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.

Answer 1

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...

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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. :-(

Answer 7

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

Answer 8

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.

Answer 9

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

Answer 10

what else is worser than this

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

Answer 11

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.

Answer 12

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.