10

This includes architecture decisions, platform choices or any situation where a such a bad choice led to negative consequences.

Improve this question

10 Answers 10

Reset to default
22

Years ago, I was the lead developer on a database centered application that started throwing errors. I tracked it down to the fact there were duplicate values in a database field that shouldn't have allowed them.

I was beating myself up about forgetting to set a unique constraint on the database when I had pushed it to production because it was just so obvious that this field needed one. I commiserated to one of my fellow developers who corrected me...

Other Developer: "Oh you didn't forget, there was a unique constraint on that field. I just removed it."

Me: "Why did you remove it?"

Other Developer: "I did that a few weeks back. I was getting data files from the customer and they wouldn't import because the unique constraint was blocking the new data. So I removed the constraint so that I could finish importing it."

Me: "Did you stop to consider that maybe there was a problem if we were getting new data that overlapped with existing data and think about mentioning it to someone before importing it?"

Other Developer: (blank stare)

Me: Facepalm.

Improve this answer
1
  • That just hurts.
    – user2528
    Nov 22, 2010 at 6:54
8

Using Visual Sourcesafe

Improve this answer
1
7

Not sure if this counts as a technology decision, but I was responsible for a CMS-like document-managing website written in PHP for four years. Throughout these years, I attempted multiple times to get people (managers, users, feature-requestors) to perhaps, possibly, like, maybe, consider the possibility of sitting together and thinking about the requirements and the future direction of the thing. It never happened. It was always “add this feature”, “add that feature”, and everyone was blissfully unaware of all the different ways in which everyone else used the website. By the time I left, it became a huge mess of interconnected but unrelated features, and I was the only one in the entire company who knew every feature. Now, nobody does. Mwahaha.

Improve this answer
1
  • Time to get a consultant on board!
    – Kirk Broadhurst
    Sep 23, 2010 at 22:19
5

Implementing SAP

Improve this answer
0
4

Rewriting a Telco grade voice mail system.

The previous system was running on Unix and around the late 90's Microsoft's COM technology came along. Many developers were working on this new NT based system. After a lot of effort its performance was still no where near that of the Unix system's and a big customer who bought this new system was pissed. Company had to be sold and some people had to leave the company.

It was ugly. All this happened about two years before Joel wrote his article: Things You Should Never Do, Part I

Improve this answer
3

Adopting an external library (in this case being Spring RCP) before it's first release version, based on a SVN snapshot. It's pretty much guaranteed that the project will end up more or less dead and you will find yourself tied to the corpse. Well, in our case it could have been worse. Still a big risk.

Improve this answer
1
  • Argh, you've just reminded me of another part of my past I'd rather forget. I inherited part of a project (the same project I mentioned in my answer) that was built on a snapshot of Spring RCP. I could never understand why. It didn't seem to add anything but hassle.
    – Dan Dyer
    Sep 24, 2010 at 1:19
3

One example I recall involved committing to a particular Java application server early on despite the fact that it did not yet have the features required for the project, just a roadmap for when they would be implemented. Naturally the vendor did not deliver as promptly as originally indicated, which should have been a big problem but in reality was just one of many cock-ups on the slow road to failure.

Most instances of this kind of problem that I have come across have involved committing to an unproven/immature technology, often because somebody influential on the technical side is a proponent of resumé-driven development.

Improve this answer
1

Three years ago, our BusDev department said they had to build their content mgmt system on Documentum because the Pharma companies they were trying to reach know the name and were comfortable with the technology. So we spent a lot of money to build it then shelved it 12 months later.

In Feb this year they announced the new system would be based on Sharepoint 2010. Want to guess why? Because, suddenly, THIS was the name known by Pharmas and one they were comfortable with!
We'll see what 2012 bring!

\\uSlackr

Improve this answer
0

Writing modern operating systems in C/C++. We've known since the Morris Worm (late 80s) that it's a completely unsuitable language for building networked software in, but that hasn't stopped anyone from doing it, which basically amounts to criminal negligence IMO.

Improve this answer
10
  • 5
    -1 Is it me, or is this about the 5th or 6th time you've posted about C being a mistake? The FUD is tiring. Just because you can't code C without making a security mistake doesn't mean other people can't. You can't hate a language based on what bad practices are possible.
    – alternative
    Sep 23, 2010 at 21:42
  • 2
    It is FUD to state that the fact that "C is a bad language" is objective common knowledge.
    – alternative
    Sep 23, 2010 at 21:46
  • 2
    @mathepic: Did I say anything as nebulous as that it's "a bad language"? I said it's not at all suitable for building programs, such as operating systems, which have security requirements. And that's both objective fact and common knowledge.
    – Mason Wheeler
    Sep 23, 2010 at 21:57
  • 6
    @mathepic: I’m with Mason on this. It is widely known and accepted that string handling in C causes buffer overflows and in a proper programming language it doesn’t. No matter how good you think you are at “reliably, consistently coding C securely” (pff), a language that unnecessarily increases the incidence of bugs is a bad language.
    – Timwi
    Sep 23, 2010 at 21:59
  • 3
    @Timwi: The original answer said "C/C++". In C++, string handling does not cause buffer overflows. Not that I'm a big fan of std::string, but it does work, and along with container class templates can eliminate a large class of potential errors.
    – David Thornley
    Sep 24, 2010 at 14:56
0

What I saw....

Back in the 1980s, there was a company called Prime that produced computers running a version of the Pick database and BASIC. The user department of the place I was working at the time that bought one was absolutely convinced that this would save them oodles of money, that they'd get the processing and results they wanted with one business analyst at one-quarter time. It wasn't long at all before there were four full-time programmer analysts and a backlog of work.

Big mistake in estimating what the technology would do for them.

Improve this answer
1
  • 1
    Good old Pick. I've always questioned having an OS/Database/Programming language named after themselves. (e.g. Dick Pick)
    – Bill
    Sep 24, 2010 at 0:33

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