Hacker News Reader

Comment by static_typed | Hacker News Reader

Frameworks sound great until you inherit a franken-app built using one. You might be able to understand bits if they religiously followed the dogmatic usage of the framework but more likely they just wanted to get stuff built and not wanting to learn someone else's idea of the perfect wheel maker framework and so ended up still building something unique, baroque, and possibly impenetrable.

Frameworks in the most case feel like straightjackets, so I understand why developers feel the need to abandon some of the magic and build bits that are actually simple robust and supportable, but it can become hell for subsequent developers.

View on HN

My first framework was actually in Turbo Pascal (Turbo Vision).

Since then I have used:

- Turbo Vision - C++ as well

- Object Windows Library in Turbo Pascal and C++

- Microsoft Foundation Classes in C++

- An in-house framework done in TCL and C

- An in-house framework done in C

- An in-house framework done in a mixture of Perl, C++ and CORBA

- J2EE in Java

- An in-house framework in Java for web development

- ... (lost count of all remaining ones)

The desire for frameworks is something that runs deep with enterprise architects.

How many corporations tend to have architects that take a nice framework and always have to put their own layer on top of it as well.

I thought that OWL (at least the Pascal version) was pretty reasonable for what it did.

I can understand the frustration with Java, though. The first time I started reading through "web.xml", I thought it was a bit much. Then I read the EJB specs...

Struts, at least the older versions I've had to maintain, is a nightmare. RoR seemed to have a lot less BS to do the same thing.

Yeah, OWL was miles ahead of MFC.

> Frameworks sound great until you inherit a franken-app built using one.

And when you do, the ones to blame are the programmers who wrote the app, not the framework.

> Frameworks in the most case feel like straightjackets

You mean "bad frameworks" feel like straightjackets.

Using the right framework for the right reason is a productivity boost.

    Using the right framework for the right reason is a productivity boost.

I agree. The difficulty with this is in the long term. Things change: new opportunities, new technologies, new developers, new functionality. Even if you were 100% certain of your choice on day one, it's difficult to measure the precise point beyond which your framework is no longer the "right" framework. I'm interested in solutions to this problem.

but doesn't this happen anyway? Business requirements change, technologies change, the tool that you chose 5 years ago is probably not the best tool for the job today, regardless of whether it's a framework, a library or another piece of software in your stack.

A possible solution is to keep your business logic framework agnostic, and write thin wrappers to plug into the framework where required. In theory it should be possible to change frameworks without incurring a major rewrite. This is easier said than done of course.

I like your post. I agree with the fact that a framework does restrict your control and creativity. However, what you get in place of that is standardization. So if you have 10 people working on a project you don't want them all to be doing their own thing. You want a very standardized code base that is easy to understand by everyone. Easier to maintain, change, and, upgrade.

Reply on news.ycombinator.com