Using a framework will harm the maintenance of your software • Hacker News Board

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

#451

Post by tootie » Thu, Oct 13, 2022, 1:58 PM UTC

"In other words: enforced standardising the tech, doesn't pay off."

That's a completely different thesis from frameworks are bad. My org uses frameworks extensively and we reevaluate which are fit to purpose at every new project. Rigid enforcement of rules without thoughtful analysis is just a straw man and I've never seen an org that does that.

I'd also just disagree with the rest of the argument. Frameworks provide both speed to market and shared vernacular that makes it easier to onboard team members and find support communities online. I have a small team and some software that is 10+ years old. The maintenance team has turned over 300% since inception. Without a framework we'd be completely lost.

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

#452

Post by NoGravitas » Thu, Oct 13, 2022, 1:59 PM UTC

planede wrote: post #325

piokoch wrote: post #265

Earlier quoted context omitted.

Where do you draw the line between using and not using framework. Programming language is a framework over machine language. Java garbage collector is a wrapper around manual memory management. Java Servlets is a pretty thin wrapper over HTTP request/response, is this a framework already? How about Java JAX-RS, it is built on top of Java Servlets and built to handle mostly REST type requests. Same with database conne…

For me the most important defining characteristic of a framework is inversion of control. With a framework high level control flow is dictated by the framework itself. It follows from this that using two different frameworks can be challenging. An abstraction layer over a database is not necessarily a framework, it can be just a library. I'm not familiar enough with specific ORMs to comment on those. A programming la…

By this definition, though, which does seem to be the one used by the article, both Flask and Sinatra are frameworks. Which I don't necessarily disagree with, but there are tons of people here in the comments arguing the opposite.

For that matter, it seems to me that CGI would be a framework in this sense - the high level control flow is that you are called by the web server, run, take input from environment variables, output an HTTP response, and exit. Not fundamentally different from "Django views take a request object as an argument, and return a response object, and are called by the framework". Just a matter of degree.

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

#453

Post by NoGravitas » Thu, Oct 13, 2022, 2:02 PM UTC

valenterry wrote: post #154

tbrownaw wrote: post #98

Earlier quoted context omitted.

A framework is what happens when you write a ton of similar apps and factor out the common parts. The quote here is no more literally true than the original lisp quote, but (just like the original) that doesn't stop it from being true in spirit.

If that were true, what would be the difference between a library and a framework? Is a library not also factoring out common parts? Or is a framework just a bunch of libraries? No, this definition doesn't describe what people understand as frameworks.

Not every library is a framework, but some libraries are. For example, gp's description describes exactly how Django came into being.

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

#454

Post by berkes » Thu, Oct 13, 2022, 2:02 PM UTC

ozim wrote: post #337

I love these technical topics because I can open up popcorn bag and read how people with statistical significance of 1 person experience throw their opinions and claim they have it all figured out. In my 14-15 years of experience in software industry I learned that having framework helps mostly with that - having bunch of "know it alls" rounded up to use the same approach instead of having "I know better discussions"…

Architectural patterns and design patterns can just as well help against "bikeshedding".

More than a framework. I avoided this topic in my article because it already is far too long :). But a framework such as Angular or Rails does three things here, all of which aren't really properties of the framework:

1. Dictate where to put files, and how to name stuff. 2. Dictate what architectural pattern you must use. Rails? MVC or GTFO. 3. Dictate what surrounding tech to use. RDBS, REST, template languages etc: you don't have a say, use them, or GTFO.

First, I don't think this is good, not because I know better, but because use-cases demand different setups. Sometimes Event-sourcing is crucial to a domain. Sometimes message-bus, sometimes microservices, sometimes monolyth. It really depends. Having the freedom to choose the best constraints and trade-offs for a project is IMO a crucial skill for long-term success.

But even if such bikeshedding is bad and "we use Rails for everything, from websites to bots to embedded software" is the proper thing. Nothing in those thre points come from a framework directly:

1. where to put what, how to name things? - ubiquitous language, a thesaurus a simple loader or even the language (rust "enforces" file naming conventions as a language). It's a good thing to have, but can be achieved without marrying to a framework with all its trade-offs. 2. What architecture to use? This should be the first thing. Maybe second is to then choose a framework that uses or allows this pattern. Not the other way around. So you'll need to do this anyway: frameworks or not. 3. Again, highly dependent on the use-case. The requirements should dictate the tech to be used, not the other way around. And the tech used then dictates whether a certain framework is feasible at all.

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

#455

Post by pythonaut_16 » Thu, Oct 13, 2022, 2:05 PM UTC

lotam wrote: post #379

ensignavenger wrote: post #70

Earlier quoted context omitted.

The author uses Django as an example of a framework... but Django doesn't really fit the definition used. Django does not dictate the flow of your code. It provides some libraries and there are common patterns, but Django is more or less just a set of Python modules you can import and use as you want (A bit of configuration is done for you if you follow common layouts, but you don't have to and can manually do the co…

I do agree with that, problem is all the other django-related packages that come with it, especially Django Rest Framework (framework is in the name here). I like some parts of it, e.g. Authentication, permissions, but IMO we often have to bend our code so it fits DRF views, and above all their serializers (which I despise). Obviously we could drop this part of DRF, but it would mean to drop DRF entirely, and I'm not…

What do you despise about their serializers? What would make them better or what would be a better approach for you?

(Genuinely curious as someone who's working on a similar idea in a different language)

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

#456

Post by pythonaut_16 » Thu, Oct 13, 2022, 2:06 PM UTC

srcreigh wrote: post #144

ensignavenger wrote: post #70

Earlier quoted context omitted.

The author uses Django as an example of a framework... but Django doesn't really fit the definition used. Django does not dictate the flow of your code. It provides some libraries and there are common patterns, but Django is more or less just a set of Python modules you can import and use as you want (A bit of configuration is done for you if you follow common layouts, but you don't have to and can manually do the co…

The Serializer class is the worst frameworky piece I know of. These are basically classes which force you to use overridden methods to link HTTP with DB operations. Requires tons of hacks to work around all the time. And just cuz it’s optional doesn’t mean it’s not frameworky. A solid platform just wouldn’t offer any frameworky elements.

Could you elaborate on this pain point? How do you think serialization should work?

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

#457

Post by lasereyes136 » Thu, Oct 13, 2022, 2:09 PM UTC

Everything or almost everything stated in the article is true. That said, it doesn't matter. All software and software ecosystems are ephemeral and you can't know what you might need or want in the future, especially years down the road. All software lives in a constantly changing world so attempts to manage maintenance needs in the future can be a fools errand.

Yes, decouple your business logic from your frameworks and libraries as much as possible. Don't expect that to make your software more maintainable.

Yes, be aware the using a framework or any technology is coupling, but also be aware that you can't decouple from everything. Make the best decisions you can with the information you have now and have test automation to check for regressions.

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

#458

Post by berkes » Thu, Oct 13, 2022, 2:14 PM UTC

jarek83 wrote: post #256

stevebmark wrote: post #205

Rails will harm the maintenance of your software* *Is really the accurate summation of the article. And yes, this is well known. Every article about a company upgrading Rails is "it took us several years and only three people died." And we know better than to use MVC nowadays. No offense to Rubyists, but in the Ruby ecosystem, I have seen a disturbing lack of absorbing information from other programming ecosystems. T…

I agree on how this article is mis-titled. It's clear that the author just hates Rails. Now - I use RoR and other ecosystems and I really miss Ruby or RoR features in those other ones.

I'm the author and I certainly don't hate Rails.

I use it for several projects still and will continue using it when the use-case is apt.

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

#459

Post by strogonoff » Thu, Oct 13, 2022, 2:28 PM UTC

marcus_holmes wrote: post #418

inopinatus wrote: post #76

Earlier quoted context omitted.

> 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 la…

But this is fine. The framework that the organisation develops for itself is designed to solve the problems that the organisation has. As TFA says, one of the main problems with frameworks is that the maintainers of the framework don't share your organisation's goals, and therefore will have different problems to solve.

While one can think of every problem as a snowflake situation never encountered by anyone before, outside of its core business domain an organization (particularly a non-technical one) rarely faces truly unique challenges. Most of the time one can also decompose the solution into a number of well-known problems that had been solved before.

For example, in an overall solution for some snowflake business challenge you may see components such as an order taking system, a customer support center, a CRM, an ERP—and on another level patterns like a statically rendered site, an SPA, a “classic” content-driven site, and so on. In my opinion, being blind to these opportunities and intent on putting the entire solution together without any delegation of control flow smells of lazy architectural thinking and/or job security. The exact decomposition would depend on business specifics, foreseeable future evolution of the business, team capabilities and other factors, but as a result you’d be able to radically lighten the implementation and indeed maintenance burden with a strategic use of frameworks or even lightly customized CMS.

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

#460

Post by spion » Thu, Oct 13, 2022, 2:28 PM UTC

dandellion wrote: post #364

spion wrote: post #340

Earlier quoted context omitted.

Building a library or a framework comes with implied obligation to write extensive documentation. I wish more software engineers understood this.

I'm confident most software engineers I've worked with understood this. Usually the problem wasn't understanding that but rather meeting the deadlines and finding the resources to write that documentation. The only time I've seen documentation done really well, the company had a dedicated technical writer whose main job was making sure they had good documentation. Engineers would write the first draft and hand it off…

I meant it "part of the job" the same way unit tests are.

I see this more often when the project is open source. For some reason we feel like when its not, we don't need to pay attention to the documentation. Nothing could be further from the truth.