Live data from Hacker News

Using a framework will harm the maintenance of your software

berk.es

71–80 of 550 posts

Re: Using a framework will harm the maintenance of your software

#71

Earlier quoted context omitted.

No. They haven’t been for a very long time. ~2008, iirc.

Rails really does not scale. In performance or development. It’s still a great option for small sites though.

Off the top of my head, I think Github and Gitlab are both based on Rails, as well as Shopify and Airbnb. So there are for sure some very large companies that use Rails successfully at scale. I can't speak to how difficult it was to develop or deploy, and it seems like Ruby as a whole has lost some popularity, but Rails has worked and continues to work for a lot of organizations.

Re: Using a framework will harm the maintenance of your software

#72
post #4

This article is about software frameworks, by the way. The capitalization made me think it was about the Framework laptop.

I thought the same exact thing, and had entered the article with a significant bias against the author based on the headline.

Re: Using a framework will harm the maintenance of your software

#73
post #17

1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…

> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework.

After 25 years of experience writing software I can honestly say I have encountered many people that agree with this, and perhaps all of them (every single one) have not actually experienced writing an application without a framework. This sentiment sounds correct in theory, but it isn't based on any experience from any one of the people making such a claim.

The reason why that is comes down to selection bias and cognitive conservatism. Once you become dependent upon a framework everything looks like a framework, even when it isn't. Therefore everything works as expected (like a framework) or it doesn't, which isn't buggy. So really this isn't a question of the software, but of the developer's capability to perceive (or not) that software.

This is why I refer to frameworks as an insane asylum as I described here to 27 up votes: https://news.ycombinator.com/item?id=32914694

Re: Using a framework will harm the maintenance of your software

#74
post #59
post #17

1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…

I agree with a sibling commenter after reading the article. The main point, as I see it between the lines, is not to refuse to use functionality (app side), but instead how this functionality should be packaged preferably (module side). Nothing prevents the one “in control” to give it up and expose a meaningful degree of it to a user, along with default mode convenience for those who want boxed version. Frameworks ac…

> Frameworks actually add to a deplorable side of the software industry. They encapsulate truly great efforts and wisdom into a package which cannot be unwrapped and used partially.

Do you have a concrete non-hypothetical example? Because I don't think I've seen this.

Re: Using a framework will harm the maintenance of your software

#75
While I don't necessarily agree with most of this article, it's very good. It really just illustrates why so many people get jaded with tech.

I believe you can absolutely build your own well-documented framework and be successful, but ultimately some little sh*t is probably going to come in either say, "Why aren't we using React? Let's rewrite in React!" or "I don't like how this is done so I'm just going to redo it some other way I like in this one place." From here you have your camp of people who say, "Just don't let that happen!" and then your other camp of people who say, "I need to hire people, and nobody wants our custom stuff on their resume so let's just use TodaysFlavour.js so we can hire whoever and make the investors happy". And that's, like, two scenarios of many.

I guess all I'm saying is that it's really hard to find value from articles like this one when the surface area of the context is pretty much unimaginably wide.

I like frameworks and two of my professional anecdotes are: I once worked for a company with an absolutely horrid culture yet their codebase was rails done "the rails way (tm)" and it was great! I got my bearings immediately and pretty much had no questions about where anything was (which was good because I didn't want to talk to my coworkers... don't worry, I didn't stay there long). I also worked at a much better company where one or two people were hell-bent on coming up with their own ideas while everyone else mostly didn't care and just wanted to get the work done. This is well-and-good but these people had already decided a previous defined way of doing things was no good so they changed that, and when they leave, I can bet that whoever replaces them will decide that their well-documented way of doing things was no good. I wish people would just follow the framework unless it doesn't make sense to (which you only actually know after you've tried to do it the framework's way).

Well, I've written way too much already for a comment... But I'll add that I think the biggest thing this article misses is its points around "speed of development". Speed of development is always important in the beginning. Once the idea has been proven to work market fit, then the generators this article talks about are no longer important.

Anyway ya, Imma shut up now. Overall, good article. I'm going to read it again tomorrow as I'm sure I missed a lot.

Re: Using a framework will harm the maintenance of your software

#76
post #17

1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…

> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. After 25 years of experience writing software I can honestly say I have encountered many people that agree with this, and perhaps all of them (every single one) have not actually experienced writing an application without a framework. This sentiment sounds correc…

> perhaps all of them (every single one) have not actually experienced writing an application without a framework

I actually have written software without a framework, so by this standard I feel qualified to comment.

Not all software has an implied framework within it. Most Unix command-line utilities do not, for example, with only a few exceptions, and discounting the C standard library as something worthy of the label “framework”. Nevertheless even they exist within an overall architecture that starts to look like one, if you squint, and realise the enormous power of piping stdout around.

However, many line-of-business applications do develop sufficient complexity, as the owner/operator adds new features to support their expanding operations, that the subsequent edifice either accretes random code into a horrifying fatberg of unmaintainability, or some wiser developer refactors substantial parts of the interface, business logic, persistence, and runtime configuration, effectively creating a framework within that application on which the logic and interface and so forth subsequently hang, and with a pinch of skill and luck, in a fashion that is more readily reasoned about and amended.

Whether that informally-specified framework might be considered worthy of extraction into a unit of software for itself is another matter, and largely a case of programmer hubris.

Re: Using a framework will harm the maintenance of your software

#77
post #50

Earlier quoted context omitted.

No, it's not "simply false". It's something that many of us have repeatedly observed happening and probably done ourselves at some point. There are of course exceptions, but it's not really fair to bluntly dismiss it. One of your greatest desires should be to have strong propietry technology that you control Yes – and you should be investing your time in making that "strong proprietary technology" more effective, and…

This notion that frameworks save you time is just ridicluous. Unless the framework is doing something really complicated and difficult (like, say, a 3D game engine such as the Unreal Engine), chances are it's costing you time and effort. What often ends up happening is you have to do a lot of useless work to get around the limitation of the framework you decided to use at the start. Since most people on HN are in the…

> This notion that frameworks save you time is just ridicluous. Unless the framework is doing something really complicated and difficult (like, say, a 3D game engine such as the Unreal Engine), chances are it's costing you time and effort.

... Have you ever written a simple web app? Pull values from a db and present them somehow? Having something that just gives me places to plug in the business logic makes this pretty trivial.

Re: Using a framework will harm the maintenance of your software

#78
post #4

This article is about software frameworks, by the way. The capitalization made me think it was about the Framework laptop.

Now I'm curious what sort of argument could be made about not using the Framework laptop.

Easy to upgrade, so developers keep testing on the latest hardware and forget about older devices? Not sure how well this fits with the title.

Re: Using a framework will harm the maintenance of your software

#79
post #52

I decided not to use a framework. I spent about a month going over the "TodoMVC.com" demos with the intent to choose one but after a few weeks of pondering which one I concluded I didn't want to invest in any of them. jQuery and Mustache.js do a lot and are easy to use. CouchDB and PouchDB are too and that gave me user authentication, a powerful server side DB, and offline-first/local-first features. I've never regre…

Wow a lot of those Todo MVC codebases are very out of date

Re: Using a framework will harm the maintenance of your software

#80
post #23
post #10

The post is promoting building applications in a loosely coupled but highly cohesive manner. It mentions using libraries when appropriate and not duplicating code. I agree with this but it requires a lead who's good at architecting such a codebase. That person also needs to stay with the company for a long time because they're essentially replacing the "framework" with bespoke human logic. I think many, maybe most, c…

> I think many, maybe most, companies that try to build loosely coupled and highly cohesive code bases end up failing and it ends up being a mess. Companies who try to build any type of codebase end up with a mess. Always. No exception. There is no reason to pretend software development's natural tendency to increase entropy is exclusive to a specific type of software architecture. In fact, some developers even go to…

> Companies who try to build any type of codebase end up with a mess. Always. No exception.

I love how demonstratively wrong this is

Post reply on HN