This includes architecture decisions, platform choices or any situation where a such a bad choice led to negative consequences.
Tell me more
×
Programmers Stack Exchange is a question and answer site for
professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
closed as not constructive by Anna Lear♦ Mar 7 '12 at 2:56
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 specific 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, see the FAQ for guidance.
|
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. |
|||
|
|
|
Using Visual Sourcesafe |
|||
|
|
|
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. |
|||
|
|
|
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 |
|||
|
|
|
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. |
|||
|
|
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. |
|||
|
|
|
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 |
|||
|
|
|
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. |
|||||||||||||||||||||
|
|
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. |
|||
|
