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

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

#461

Post by fleddr » Thu, Oct 13, 2022, 2:33 PM UTC

It's funny, this divide between the old world and new world.

The old world has a heavy emphasis on computer science itself, theoretical correctness, long term thinking. It has led to the role of the careful software architect, design patterns, UML, the like.

Everything about this old world is a fantasy, as it requires ideal conditions. You'll need low delivery pressure and a homogenous set of well-disciplined high-end engineers.

That's not how software is built these days. You need to ship multiple features per engineer per 2 weeks or so. There's no time to do it the right way. Worse, most programmers are bread programmers and couldn't even grasp deep computer science, most have never studied it. Even better educated engineers compromise due to time pressure. The role of software architect as it was before, barely exists anymore. It's just a senior developer winging it.

In this context, if anything, frameworks aren't opinionated enough. Many don't have "batteries included" leaving unlimited options to screw it up. And the team will screw it up.

Maintenance? The software cycle in some domains, especially web and apps, is so fast that we'll just start over every 3-5 years anyway.

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

#462

Post by throwaway290 » Thu, Oct 13, 2022, 2:44 PM UTC

goodpoint wrote: post #216

a4isms wrote: 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 Yet a nicely designed, simple, custom half-framework is cheaper to maintain than a bloated popular framework.

Unless your half-framework has equivalently good documentation as a popular framework (which hardly ever happens), this thesis break apart as soon as someone who didn't implement your in-house creation needs to maintain your project and fix your bugs.

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

#463

Post by throwaway290 » Thu, Oct 13, 2022, 2:48 PM UTC

onion2k wrote: post #382

lll-o-lll wrote: post #371

Earlier quoted context omitted.

Yeah but that sucks though. Imagine being a large company with a multi-million dollar annual spend that could be entirely free if only Postgres had been a bit more mature back when you started. So many of the decisions you make when needing to move quickly at the start of your growth curve, are the ones that slowly kill you after market saturation. Being able to swap out a db would be nice.

That's not true though. The answer isn't to use a database abstraction, but to architect your software to make changes straightforward. If you design your code properly (push database queries through a standard set of APIs that are reused everywhere, put queries in their own functions or classes, never put queries in components , etc) then moving to a different database is a relatively simple matter of updating your…

Exactly. It seemed to me as if the author originally thought with a framework they don't ever have to think about the architecture, but of course it's still possible to shoot yourself in the foot and end up with a tangled unrefactorable mess. The article channels misplaced disappointment.

Give it some thought and properly encapsulate your core business logic and you won't have that much trouble migrating to another framework or a custom solution if need be (especially easy if your current framework has good documentation, which Django definitely does).

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

#464

Post by pjmlp » Thu, Oct 13, 2022, 3:03 PM UTC

vidarh wrote: post #401

pjmlp wrote: post #390

Earlier quoted context omitted.

At which point it is no longer C, rather a programing language that vaguely resembles ISO C.

Of course it is still C. You've just opted not to use some of the functionality. Nothing stops you from e.g. providing your own startup code which then calls the appropriate initialisation code either. The point being that there's no enforced inversion of control in the sense used by the article, and so calling it a framework in the sense described by the article is meaningless. Even if we postulated the inversion of…

Not from the point of view of ISO C and the expected semantics of the abstract C machine.

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

#465

Post by sbf501 » Thu, Oct 13, 2022, 3:04 PM UTC

john61 wrote: post #128

sbf501 wrote: post #109

Earlier quoted context omitted.

I think this argument is about free vs. not-free frameworks. Frameworks that are supported by a company and actively developed are far superior to the state of NPM open source right now (thinking of Qt vs Electron and my 7 year battle with both). It is no fun when an open-source framework pushes a new major version, then deprecates the version you were on, or dependencies fail to find matching version, and you beg gi…

And it is no fun when the manager of the company developing your proprietary framework decides to tank it because of a change in strategy or the competitor buys the company and stops development. Since you have no source code you are forced to do what the commercial interest of foreigners dictate.

That is far, far less likely than a package being abandoned. What happened to your project? What "commercial interest of foreigners" went under that doomed you so?

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

#466

Post by marcus_holmes » Thu, Oct 13, 2022, 3:04 PM UTC

strogonoff wrote: post #459

marcus_holmes wrote: post #418

Earlier quoted context omitted.

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…

This simply isn't true for, well, every project I've been on. There is always some unique wrinkle in the requirements that means this project needs a different approach.

SAP is the classic example of this: SAP implements vanilla business processes (with lots of flexibility built in). Yet every single business implementing SAP needs extensive customisation and modification to make it fit their business processes. Some have spent millions or tens of millions trying to make SAP fit their business and failed.

In your terms; every business is a snowflake. You cannot create (for example) an order taking system that will fit all businesses. Or even "all businesses for whom order taking is not part of their core business domain". Only "those businesses who are willing and able to make their order-taking process fit your system".

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

#467

Post by sbf501 » Thu, Oct 13, 2022, 3:07 PM UTC

DrewADesign wrote: post #124

sbf501 wrote: post #109

Earlier quoted context omitted.

I think this argument is about free vs. not-free frameworks. Frameworks that are supported by a company and actively developed are far superior to the state of NPM open source right now (thinking of Qt vs Electron and my 7 year battle with both). It is no fun when an open-source framework pushes a new major version, then deprecates the version you were on, or dependencies fail to find matching version, and you beg gi…

I think some of your experiences can be explained by your citing NPM as representative of FOSS. Not that there's anything wrong with the astonishing breadth of functionality available in the NPM ecosystem, but stability isn't its strongest comparative suit. OTOH, Django, which was cited by the author, just doesn't have that kind of volatility in its base features.

True. I should have been more clear because NPM =/= FOSS.

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

#468

Post by a4isms » Thu, Oct 13, 2022, 3:20 PM UTC

kodah wrote: post #145

a4isms wrote: 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…

Some counterpoints and personal experience: > 3. If you have a small team that hires slowly, it's relatively straightforward to bring new devs up to speed on "the way we do things." if you are hiring rapidly and/or have a large team, the more bespoke things you have, the harder it is to maintain them. I disagree that framework or no-framework is the distinguishing characteristic. I do think that the quality of the co…

> Anecdotally, the only framework-based projects I've signed on to ended up incurring more onboarding time because I had to learn the framework, how the framework does things, and then how the team does things in the framework. All of this "how" is a step before "why", of which, every step eventually needs to be repeated over the course of my tenure in order to be successful.

This is one of the most interesting replies, thank you.

The pitch for a lot of tools—be they frameworks, libraries, languages, &c.—is that if they’re popular, you get to hire people who arrive already knowing the basics of how things are done.

The reality is that popularity waxes and wanes, so when people are evaluating a tool’s fitness for purpose, they sometimes have to read tea leaves to decide if it’ll pay off or not.

A company making several such wrong bets in a row often has a trail of poorly supported ancient technologies lurking around. They still work—Joel Spolsky famously said that code doesn’t rust—but it’s aggravating to onboard, there are few productivity advantages, and sometimes the same thing is done three different ways because the company made two “wrong” bets before making the bet they currently think is “right.”

Would things be better had they just done their own thing and stuck to it? Possibly, I tried above NOT to make a claim that a popular framework is either the right thing to do or the wrong thing to do.

But it is good to read your comment pointing out that sometimes, a popular framework isn’t popular enough to harvest the benefits for people onboarding.

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

#469

Post by vidarh » Thu, Oct 13, 2022, 3:33 PM UTC

pjmlp wrote: post #464

vidarh wrote: post #401

Earlier quoted context omitted.

Of course it is still C. You've just opted not to use some of the functionality. Nothing stops you from e.g. providing your own startup code which then calls the appropriate initialisation code either. The point being that there's no enforced inversion of control in the sense used by the article, and so calling it a framework in the sense described by the article is meaningless. Even if we postulated the inversion of…

Not from the point of view of ISO C and the expected semantics of the abstract C machine.

If you were to write a program that relies on those aspects of the abstract C machine and don't provide those aspects, then you might have an argument, in that in that case the observable behaviour would be different, but if you choose not to make use of that functionality, its presence is entirely irrelevant.

This is also massively shifting goal posts. You first wrote "At which point it is no longer C". By your argument here, e.g. the Linux kernel is not written predominantly in C. But nobody uses the term that way. If you were to speak specifically about ISO C, maybe, but the person I replied to initially did not limit it to ISO C.

As such this is also entirely irrelevant to the original argument.

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

#470

Post by AugustoCAS » Thu, Oct 13, 2022, 3:36 PM UTC

I didn't read the whole article, but I agree in principle.

My rule of thumb is:

* Prefer code vs a library if what I want to do is simple and/or if the complexity of the library overshadows whatever benefit I get from using it. * Prefer a library vs a framework if the library provides what I need.

A couple of examples when using:

* The use of the Spring Framework in the Java world to do DI, web apps and many other things. I think java is the only language where a framework has such a bad influence on developers (maybe Ruby and Rails follows it, after all Spring tried hard to copy Rails ease of use). In this example the framework makes a few things easier, by ading a metric ton of complexity. * The npm left-pad library (debacle).

This doesn't mean that one shouldn't use libraries or frameworks, just that they need to be justified. Development is boring and most developers just see shiny stuff and have to use it in production just to get some entretainment.