Live data from Hacker News

Using a framework will harm the maintenance of your software

berk.es

341–350 of 550 posts

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

#341

Earlier quoted context omitted.

> Of which you are the creator and expert, and have complete control and insight, and can change it in any way you want any time. It is in 100% alignment with your goals at all time. And then you change a job and you take 80% knowledge with you and your now-past project is in deep trouble.

If knowledge is on a single person alone, then your ex-company has bigger issues than framework or no framework. Not to mention that the interesting parts of your app should be the domain logic and workarounds and solutions used in it for business issues and historical layers of bussiness logic choices. And that a single person can take with them whether there's a framework or not.

> If knowledge is on a single person alone, then your ex-company has bigger issues than framework or no framework.

You are both right and also describing every single company I've seen. I haven't worked in a straight up software company, though. Maybe they have things better.

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

#342

Earlier quoted context omitted.

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

Probably a different problem domain, but I like simple BSON message objects over AMQP into rabbitMQ to enforce a producer/consumer linear job queue from a distributed platform... where transactional ordering can on occasion be more important than the latency hit.

Most OTP projects can benefit from a RabbitMQ/kafka message channel, as some jobs may end up visiting several languages, CPU and GPU architectures. =)

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

#343

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…

By this definition everything is a framework. You're never the one calling code, it's always the BIOS, the bootloader, the kernel program loader, etc. I don't want to go all ad-reductio, but this is one of the points I have against the anti-framework people: the code you write is actually a pretty small percentage of the total code that makes up your system/application. Good engineering is working to make sure that code is differentiating code, not irrelevant code like garbage collection, HTTP header parsing, etc.

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

#344
post #28

Earlier quoted context omitted.

Agree completely. I’d like to add a couple of things. 6. Frameworks often handle the last 20% of a project that no one wants to do, such as handling compatibility or accessibility issues. 7. There’s a good chance that the framework has already had to deal with edge cases that you would otherwise learn the hard way

My experience is the exact opposite. Frameworks have a very narrow compatibility and accessibility range, and to get the other (often more than) 20% requires extra hackery which has to be bolted onto the framework in ways that were not foreseen by the framework writers.

I've come to believe the difference between framework-lovers and framework-skeptics is that one (larger) group is generally following a well-trodden path and doing only things the framework authors anticipated. Viewing a framework as a common architecture extracted from the experience of writing lots of software, this makes total sense. Most software looks like X, so a framework like X will look like most software.

Those who have problems with frameworks are solving problems that are to some extent novel. Maybe only 10% novel, but that's still enough to feel like the framework is a straitjacket - because everything else is a solved problem and that 10% is the hard bit and the framework just makes it even harder.

Perhaps some of those people could re-examine their problem and achieve it in a different way using the framework, but others couldn't. But to say "if you're not using a framework you're doing it wrong" perhaps exposes a lack of experience with unusual problems, and "all software ends up containing a custom framework" is confusing frameworks with architecture.

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

#345
post #232

Earlier quoted context omitted.

Same for it's Java-based cousin, Spring :-)

Say what? That unholy mess of annotations, unusable outside of the Spring "walled garden" where you have to search the internet on how to do the most basic thing (with annotations)? Spring(Boot) is the perfect example --to me-- of a framework that dictates, and does not allow to be get out of your way when all you want is "just libraries".

I have to disagree with that. I have developed software without frameworks before, and have come to love a good framework. Spring Boot is a performance multiplier. It may look scary at first because it has so many (optional) modules that supports everything from basic injection to cloud infrastructure.

You don't need to use everything just because it is available. Even basic web services are not enabled by default, and is something you need to explicitly add as a dependency. If you don't want to use Hibernate, just import a different dependency instead.

It lets me focus on business logic, while handling the interface outside the "garden" for me. In my experience, the use of annotations is confined outside the business logic. If that's not the case, the code is organized badly and will cause issues regardless of framework.

Example (could be improved of course)

  @RestController
  @RequestMapping("/dogs")
  public class DogController {
     private final DogRegister dogRegister;

     public DogController(DogRegister dogRegister) {
       this.dogRegister = dogRegister;
     }

     @PostMapping
     public void registerDog(@RequestBody Dog dog) {
       dogRegister.registerDog(dog);
     }
  }
If I decided to change it to a message based approach, I could do that without changing any business logic, by replacing the controller with a queue listener. Also note how IOC will automatically inject the business logic component.

  @Service
  public class DogListener {
    private final DogRegister dogRegister;

    public DogListener(DogRegister dogRegister) {
      this.dogRegister = dogRegister;
    }

    @JmsListener("dogs")
    public void registerDog(Dog dog) {
      dogRegister.registerDog(dog);
    }
  }
In my view this is a framework that gets out of your way. I did not have to change the business logic (dog service). Spring takes care of the interface outside the program. If I wanted to switch to a different standard than JMS, I would most likely in many cases just need to change to a different annotation.

If the code is organized badly, the business logic would have been included in the controller and be harder to change. But isn't that the case of bad structure in general?

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

#346
post #223

Earlier quoted context omitted.

> 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)

Except none of these steps are dictated by the C standard library (some may be dictated by some libc's)

EDIT: To expand on this: You can call the code from stuff other than a shell; I'm assuming you mean "C runtime" by CRT, and some libc's may have issues without them, though usually only access to argc/argv and atexit(), and you can certainly write C without linking with the initialisation code; and while you'll of course usually enter via main() you don't have to. You decide the control flow.

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

#347
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…

Software is a layer cake and in my opinion from 20 years software development experience I firmly believe that the top 1-2 layers of your business application should not rely on some framework if you want to create a great product, stand out amongst competitors and have a technological advantage in terms of innovation and maintenance. Whatever happens at the top 1-2 layers is what your business cares about the most and what defines your business and you want to have 100% control to fine tune it. I've worked in many companies and on many projects and this made a difference every time.

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

#348
post #311

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.

"Spring Boot" has inherited some of the good ideas from Dropwizard.

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

#349
post #285

Earlier quoted context omitted.

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.

Until something is broken, and you need to step through 40 levels of stack (certainly no exaggeration) to try to figure out where something is happening, and where that exception is swallowed. Most often it's not the framework that is broken, but you still need to understand enough of the framework to figure out what is wrong where.

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

#350
I agree that there is a problem here, but I think its a slightly different one.

Frameworks and libraries both save you time and require you to invest some time. The main question is whether the savings will be bigger than the investment, and that question can be hard to answer.

In most cases we tend to err on the side of framework optimism - we presume a framework or library will always save time (don't reinvent the wheel, NIH syndrome, etc). Sometimes when we do this, its because we realize the deep rabbit hole of building something like the framework or library we're using. Other times, its because we don't know whether the hole is deep or not - we don't have the expertise to evaluate.

I think the second case is where most of the danger lies. Which is why, paradoxically, its a good idea for a software engineer to reimplement a few pieces of general purpose software in a more specific manner every once in a while and live with them for a longer time.

Unfortunately, this is not always possible; often the next best thing is to contribute to an existing open source project and ask (in the kindest way possible) why certain things were implemented in a certain way and/or learn from its commit and issue history. Learning doesn't mean you have to agree with the authors - in fact often even authors will lament certain design decisions that painted them into a corner or increased complexity unnecessarily.

Doing the above will make it easier to evaluate wheather a framework (or library) will save time or drain time. Without it, erring on the side of caution seems like the safer option, which is why we keep recommending it. However, sometimes the drain can be significantly bigger than the savings - if you're spending most of your time fighting the framework that's a signal that something is wrong and we should have a way of listening to that signal and responding strategically.

The downside of frameworks that I think the article is correct about: general-purpose software is really hard to get right. Every author has a specific set of experiences and needs which depend on their specific situation. It may be worth spending some time researching the kind of software built with that framework (or library) to see if there is any obvious bias that would make it not fit your problem domain or your specific context.

Post reply on HN