Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using a framework will harm the maintenance of your software

berk.es

Post reply on HN
Print view View original

311–320 of 550 posts

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

#311

Post by pas »

sz4kerto wrote: post #269

I think using a framework can help with the maintenance of the software. Let me use the one that is usually used as a negative example in hacker circles: Spring. Spring has a steep learning curve. Spring feels like too much magic. Spring makes simple things look complicated and hard to understand. Spring is large. On the other hand: I don't care about making extremely simple things more complicated. In the enterprise…

exactly. and of course it's not impossible to identify the good things in Spring, then look for a different framework that has those but has less of the bad ones. Dropwizard was looking good a few years ago.

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

#312

Post by pmontra »

hinkley wrote: post #168
mmis1000 wrote: post #150

Earlier quoted context omitted.

If library is deprecated. You replace the library. If framework is deprecated. You give up the project or rewrite 'everything' to use another framework because essentially your project is build on it. That's the difference. If you make abstract to make it suitable to port to another framework. Then you are writing yet another framework on the top of a framework. In my opinion, it's even worse.

In my experience, I lack the talent for truly graphic swearing that would be required to adequately communicate just how much worse it is. Wrapping frameworks is like throwing water on a grease fire. Or maybe like someone else throwing water on the grease fire while you're standing inside the splash radius. The only way to win is not to play, but the best way to minimize the damage if you can't avoid it entirely is t…

On this line of development a customer of mine has a lot of small/medium Rails applications with very little in models and controllers and almost all of it in service and command classes. They use commands for code that does only one big complicated thing and services for bags of simple methods about one resource.

They end up with code like

  class Command
    def initialize(a)
      @a = a
    end
    def run
      s = Service.new(@a)
      s.do_something
      s.do_something_else
    end
  end
  Command.new("a").run
which is funny when I think that in Elixir I would write Command.run("a") and there isn't a good reason for using OO in this case, except that Ruby is very object oriented. Anyway, their code is quite separated from Rails except for the calls to ActiveRecord, but that could be ActiveRecord without Rails.

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

#313

Post by willsmith72 »

Ma8ee wrote: post #285
Lio wrote: post #258

Earlier quoted context omitted.

That maybe true but what happens when people, including yourself, switch teams? At some point we all wade through someone else’s mess. Hell, even your own mess revisited after a period of time is unpleasant. The more you can do to make your software predictable and boring the less unpleasant it will be for everyone.

I actually got to a point where I don't mind my own code. Even code I wrote years ago feels natural to me when I revisit it. And about the switching teams part. I much rather take over code that is written for our specific use cases than trying to wrap my head around some huge generic framework.

But this is the point... You don't have to "wrap my head around some huge generic framework" for every project. If you choose the right framework, it's already used in teams, projects and businesses across the world, so hiring and upskilling are far far easier than they would for a custom framework.

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

#314

Post by planede »

another-dave wrote: post #294
throwaway284962 wrote: post #274

Earlier quoted context omitted.

I started using a framework for a task at work, was immediately tripped up by an obvious stupid bug in the config files, reported it and it was closed because "too many people already depend on this behaviour". So now I've in-sourced other companies legacy and taken on a huge liability in depending on the evolution of undefined number of other organisations and their code bases. And even worse when these frameworks a…

Build everything in-house or be beholden to some dude going backpacking is a false dichotomy. It'd be like saying I always make my own food from scratch — have you seen the state of the burger van down on the corner? You can't trust food made by others. All frameworks aren't created equal — as with any tooling, you choose something based on the features of the framework but also the longevity, reputation and ecosyste…

Yeah, but this has other trade-offs than the other two options of just using a 3rd party framework and inventing your own. Not saying that this is not viable though.

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

#315

Post by flohofwoe »

coldtea wrote: post #244
flohofwoe wrote: post #210

Earlier quoted context omitted.

> 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”. The C standard library is exactly that though, a framework for writing UNIX command line tools :) (for anything else it's much less useful)

A library is not a framework. You can write framework-free apps while using libraries (in fact, most do - not wanting to be burdened with a framework doesn't mean you have to write all functionality yourself). A framework is either about inversion of control (it calls your code, e.g. you write web request controller logic, and it sets up the infrastructure for calling your controllers), and/or a set of ways to struct…

Well to be pedantic, the CRT invokes a callback called 'main' with preprocessed (command line) parameters, in the 'main callback' you're expected to do something with the parameters that have been passed to you (for instance read data from stdin, process it and write back to stdout), and then return from the 'main callback' with a success or failure code.

Ok, I'm throwing together the CRT and standard lib here, but in the end both are parts of the "UNIX command line tools framework" which is supposed to provide a programming environment to easily extend the UNIX shell with your own commands.

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

#316

Post by Ma8ee »

thom wrote: post #237
kayodelycaon wrote: post #56

Earlier quoted context omitted.

Done Rails my entire career. It scales more than you think if you’re willing to throw some hardware at it and avoid turning your controllers and models into logic layer soup. What kills scaling is inexperienced developers doing what I just mentioned. Also, ActiveRecord is not your friend at scale. It’s wonderful in small amounts, but callbacks and memory overhead will kill you. You really need to learn SQL to avoid d…

To be fair, any framework scales if you throw hardware at it and stop using the slow bits.

The question is if there is anything meaningful left after you stoped using the slow bits.

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

#317

Post by willsmith72 »

iveqy wrote: post #298
jarek83 wrote: post #243

It seems that there are mostly 2 types of devs: - those that use tools, learn them and master in them, - those that always want to create their own tools, and will usually oppose adopting and learning existing ones. I belong to the first type. I love frameworks because they give publicly available documentation that plenty of people contribute to - so my project will have access to all of it even if I'm gone. Another…

I belong to the second type. I believe it's a great asset to have in business. Most often less code means shorter development time and cheaper maintenance. People knowing a framework will often use it for everything. Instead looking at the problem and find the easiest solution to it offers great time to marked. I've proudly deleted more code than I've written at work.

Agree on the importance of deleting code, but with "less code means shorter development time and cheaper maintenance", I don't think I've ever seen a program without a framework use "less code" than it would using one.

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

#318

Post by flohofwoe »

vidarh wrote: post #223
flohofwoe wrote: post #210

Earlier quoted context omitted.

> 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”. The C standard library is exactly that though, a framework for writing UNIX command line tools :) (for anything else it's much less useful)

> The C standard library is exactly that though, a framework for writing UNIX command line tools :) It doesn't fit the term as used in the article at all, though, in that it doesn't dictate the overall program's flow of control.

The overall program flow in this case is:

   shell => CRT => main(argc, argv) => exit code => shell
(to me, the CRT and C standard lib are not strictly separate, although that's debatable of course)

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

#320

Post by willsmith72 »

abracadabra_ wrote: post #302

Write small, well tested services in the easiest to use framework you can find. If the service becomes hard to maintain then replace it. This should be a simple job guided by the tests.

Not everything should be a small service
Post reply on HN