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

31–40 of 550 posts

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

#31

Post by TillE »

This is like saying game engines can be clunky and get in your way (absolutely true), therefore you should just glue a bunch of libraries together.

In practice, that almost never works out well. You want to carefully pick the right tools for the job, but those tools will be enormously helpful when dealing with any kind of complex task, even if you can recite a litany of annoyances.

Of course if you don't have a complex task at hand, go nuts, find a sleek solution that truly fits your needs.

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

#33

Post by hsn915 »

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…

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

This is simply false.

On the other hand, every sufficiently complex framework-dependant application is way too complex for what it does, and would be a lot simpler if it was not using said framework.

> My last and--to me the most significant--observation is this: You want to pay the majority of your attention to the code that has the greatest impact on your desired outcomes.

One of your greatest desires should be to have strong propietry technology that you control. Otherwise you are not different from anyone, and anyone can duplicate your work in two months by just using the same framework.

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

#34

Post by kayodelycaon »

djbusby wrote: post #16
cgh wrote: post #5

From the author’s About page: “I mostly work with Ruby on Rails. A professional, Open Source platform which powers enormous (e.g. Twitter.com) and tiny applications.”

Wait, Twitter is still RoR?

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

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

#35

Post by forgotmypw17 »

tomcam wrote: post #28
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…

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.

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

#36

Post by couchand »

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…

The author carefully distiguishes precisely what type of framework they mean. The definition includes multiple parts, but the part that really stands out to me is that a framework dictates the overall flow of control.

The suggestion in TFA is to ensure that you consume your dependencies in a decoupled fashion, a move toward utilizing libraries rather than following a framework.

I've spent lots of development time in highly-constrained environments that often feel more like a framework than a true platform. When given the opportunity, I'm inclined to follow the author's suggestion to keep dependencies decoupled. Even supposedly fundamental dependencies will eventually need to be swapped out, even if just for a v2. But your domain core should be making monotonic progress towards the distillation of your key concepts and relationships.

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

#37

Post by hocuspocus »

woranl wrote: post #12

Frameworks come and go. What is trendy today will be deemed obsolete a few years later. By the time when the community no longer interested in said framework, it will feel like the rug got pulled leaving many projects stranded.

13 years into my professional career I'm still seeing Spring everywhere.

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

#38

Post by _qyyd »

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…

Do you think that formal specifications might alleviate logical bugs to an extent?

Yes, it appears that companies won't budget that at all. Many seem to ship fast, fix later. It is also on the customer, really.

Some people expecting software developers to deliver high quality software (with near 100 % code coverage and exceptional performance), but paying them less and less, is not fair. No wonder, some devs are incentivized to skip unit tests or error handling. Because some employer or some customer won't pay for it.

This is the status quo that makes me pessimistic. It appears that software development is gluing things together and make it somehow work.

This ain't fun for me.

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

#40

Post by matthewmacleod »

hsn915 wrote: post #33
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…

> Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. This is simply false. On the other hand, every sufficiently complex framework-dependant application is way too complex for what it does, and would be a lot simpler if it was not using said framework. > My last and--to me the most significant--observation is this: Yo…

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 spending as little time as possible doing all the bits that your competitors didn't have to do because they picked an off-the-shelf solution that did most of it to a "good enough" level.

Post reply on HN