What architectures / improvements / patterns would you like to see burning in hell?

views:

154

answers:

+5 Q:

What architectures / improvements / patterns would you like to see burning in hell?

While developing software, developers always tend to curse about some language specifics, "improvements" that made language less understandable, buggy.

What obstacles / improvements have you met, that you'd be pleased no one ever invented / introduced?

My 2 cents:

I cursed for 3 days at delphi 2009. I had an internal compiler error, with no clue what I was doing wrong. It turned out I couldn't inherit a Generic class declared in another unit.

edit: moved to community wiki, as some of comments suggested

+2 A:

Big Design Up Front

Developer Art 2009-10-11 11:08:01

I agree with the "big", not the rest.

peterchen 2009-10-11 11:59:24

Do you mean Big Up Front Design (BUFD)?

Pascal Thivent 2009-10-11 12:04:11

Personally I think we might be better served by retiring the term BDUF. We Agile practitioners have alienated many skilled developers with this argument, and given the impression that there is **no** design in Agile (untrue). I believe talking about the Last Responsible Moment instead is one small step towards healing the gap. People take up arms when they feel criticized. Instead we can show them the benefits of Agile techniques.

TrueWill 2009-10-11 14:25:22

+4 A:

Singleton Pattern (also known as Global Variable in Disguise Pattern).

Alex B 2009-10-11 11:10:05

What is wrong with singleton?

codymanix 2009-10-11 11:12:10

The same things that are wrong with globals: they are far too easy to abuse.

Matthew Scharley 2009-10-11 11:26:47

@codymanix, read for example: http://code.google.com/p/google-singleton-detector/wiki/WhySingletonsAreControversial

Jesper 2009-10-11 11:27:45

+1. Beat me to it!

TrueWill 2009-10-11 13:59:28

+8 A:

Python. Because whitespace shouldn't be meaningful except where absolutely necessary. :-D *ducks*

C++. A nasty hack on top of C to allow OOP, resulting in horrific syntax and a lack of garbage collection, instead of the ground-up redesign needed for OOP like Java or C#. *ducks again*

MUMPS. The name says it all.

Perl5's OOP infrastructure - feels like a nasty hack on top of a language that wasn't originally intended to be OOP.

Jez 2009-10-11 11:10:35

+1 for C++. I refuse to duck; let the flaming commence...

Smalltown2000 2009-10-11 11:13:09

C++ maybe... but python's whitespace syntax enforces good syntax... which is good , right?

Aviral Dasgupta 2009-10-11 11:15:57

MUMPS... what an incredible invention... see: http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx

Jesper 2009-10-11 11:23:19

PHP also wasn't designed as an OOP language..nowadays everything must be OOP :)

Juraj Blahunka 2009-10-11 11:31:26

PHP is essentially like HTML, with C tacked on, with OOP stuck on it with nose snot.

Aviral Dasgupta 2009-10-11 11:34:24

To be honest I would like to see Java burning in Hell or at least they should create a complete remake of it (I know there is already one called C#).

codymanix 2009-10-11 11:11:34

Do you mean C# is a complete remake of Hell?

MusiGenesis 2009-10-11 11:50:59

*lol* you saved my day..

codymanix 2009-10-11 23:10:23

+3 A:

Big Ball of Mud architectures, although in that case it's more a lack of invention rather than a new one.

sipwiz 2009-10-11 11:12:58

+2 A:

Any and all "improvments" to BASIC. BASIC was a broken thing from the start. VB was an attempt to fix it but -- FAIL. Then VB.Net was made, so that by the time people realized the mess that they were in, they'd be knee deep in hell.

Aviral Dasgupta 2009-10-11 11:13:40

I agree with you up to VB.NET. While I would **much** rather program in C#, the main differences are just syntax. Even automated tools can transpose code between the .NET languages.

TrueWill 2009-10-11 14:08:37

I agree with TrueWill here. At its core, BASIC is just a way of declaring variables, specifying for loops and if blocks and case statements etc., organizing methods, accessing object properties and so on. Some people like "end" statements, some people like curly braces and semi-colons. In the end (or in the ";") it doesn't make much difference.

MusiGenesis 2009-10-11 16:29:47

+4 A:

n-Tiered design. The next time I inherit a "solution" that contains a functionally empty "BusinessObjects" project, I'm going to strangle someone. I'm amazed that this pattern is still so prevalent 15 years after I first encountered it. As I said in another answer, layering is great for lasagna, but it isn't automatically a good choice for all software.

http://thedailywtf.com/articles/the-mythical-business-layer.aspx

MusiGenesis 2009-10-11 11:50:03

I like the lasagna comparison :-D

Johannes Rudolph 2009-10-11 11:55:22

laughed a lot :-D

Juraj Blahunka 2009-10-11 11:59:50

So long as people aren't putting business logic in their GUI (note that I didn't say presentation layer!). Ever try maintaining an app that has all the code under button-click events on the form?

TrueWill 2009-10-11 14:05:05

Any code should be well-encapsulated in classes and/or functions (and not in button-click events, as you say), but this does not mean that it necessarily should be separated by layers *per se.* A simple example would be code that loads a DataTable from a database and sets it as the DataSource for a GridView. A common (anti-) pattern that I've seen is where the form instantiate a business object that itself instantiates a data object that loads the DataTable and returns it to the business object which itself returns it to the form. In this case, the business object is useless ...

MusiGenesis 2009-10-11 14:30:49

... (what I called "functionally empty" in my answer).

MusiGenesis 2009-10-11 14:31:21

ansaurus

tags:

views:

answers:

What architectures / improvements / patterns would you like to see burning in hell?

related questions