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

471–480 of 550 posts

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

#471

Post by taylodl »

throwaway0asd wrote: post #73
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. After 25 years of experience writing software I can honestly say I have encountered many people that agree with this, and perhaps all of them (every single one) have not actually experienced writing an application without a framework. This sentiment sounds correc…

I've been creating software for 40 years and I can tell you the statement "every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework." is 100% accurate. Back in the day we'd go and create our own frameworks that we could use on multiple projects. They were never as robust as the frameworks that exist today since we didn't have nearly the number of people using the framework and discovering issues. Not to mention the incredible amount of time we spent creating and maintaining these frameworks. Coming from that experience early on in my career to where we are today with people complaining about "too many frameworks" sounds like first world whining to me! :) I'll take too many frameworks over having to create everything from scratch any day.

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

#472

Post by camgunz »

coldtea wrote: post #407
camgunz wrote: post #343

Earlier quoted context omitted.

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

> 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 Which is neither here, nor there. We're talking about a specific kind of inversion of control and forced structure within the codebase. Else we could just go down an irrelevant rabbit hole, and it…

Well, my point is that because this applies to more or less everything, it's not a great determinant of library vs. framework.

Like, the way you use Django is by wiring up URLs to functions [0]. This is pretty similar to setting up a vector table for interrupt handlers. Is that a framework? What makes Django a framework and vector tables not a framework?

I'm not trying to be pedantic here, I just really couldn't tell you the difference, and as a result, I'm not sure the distinction is useful. It sounds more like a post-hoc rationalization of why you like or don't like something.

[0]: https://docs.djangoproject.com/en/4.1/intro/tutorial01/#writ...

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

#473

Post by Test0129 »

m00x wrote: post #213
Test0129 wrote: post #130

Earlier quoted context omitted.

I've been burned by so many frameworks I am hesitant to use one unless the advantage is abundantly clear. Even something as mundane as an ORM can cause massive problems down the line if you're not careful, or you forgot to anticipate the case you need something more complicated than braindead CRUD. Frameworks force you into a paradigm. Yes, to spin up quicker, get new engineers onboarded quicker, etc a framework will…

> You're bound to their bugs If you do it yourself, you're bound to your own bugs. When they have bugs, it's fixed by a team of highly skilled contributors. Not using frameworks is just an ego problem, or a lack of skills.

When I was briefly on a Go project when go was still relatively young we decided to use a framework. I can't remember what it was...GORM + something possibly.

Three months later we find a few game breaking bugs. Do the right thing and send a report and hope the author's fix things. Things didn't get fixed in time. Now over budget and over the time limit I have VPs of engineering breathing down my neck (as the lead at the time) for why things aren't getting done.

This is not an isolated case. You might not run into this problem using a mature framework (the problem then is being bound by the author's idea of a good architecture), but if you're needing something better and venture into other languages for your needs you will run into this at some point. "Highly skilled contributors" often work for free. Perhaps I'd agree with you if you meant some professional, paid, framework. But I have never had an experience where these "high skill open sourced contributors" fix bugs inside my sprint cadence. The implication that I have an ego and skill problem for not using a framework, but these so-called contributors are "high skilled" is insulting to not only me but the entire profession.

I'd imagine the nuance is in what kind of language you use. Lowest common denominator languages like Ruby, Javascript, etc (things that can be learned quickly in a code camp) tend to be dominated by framework-first-and-always people since frameworks can be parsed easily by seat warmers. Engineering management loves frameworks because it takes the thinking out of writing code. The maligned view of engineers as people who will "screw things up when they're left to their own devices" is so pervasive they've even got other engineers parroting it.

If you believe it's a "lack of skill" or "ego" problem to honestly not use a framework in some cases you should probably stop hiring idiots. An actual "high skill" engineer will evaluate the cost and probability of needing to break out of a framework.

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

#474

Post by strogonoff »

marcus_holmes wrote: post #466
strogonoff wrote: post #459

Earlier quoted context omitted.

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…

You identify common aspects and snowflake aspects, and in the end the separation as to which parts are snowflake (contain business specifics). That’s your job as software architect. Again, the locations of snowflake parts tend to be similar across businesses, and this is where good frameworks and CMS tend to offer extension points.

It’s a spectrum: a CMS may be more fiddly as to customization but more reliable if your needs and extension points fit, framework offers more freedom, and a bespoke combination of libraries generally forces you to implement and integration test more of control flow and imposes higher costs of maintaining proper documentation as to how everything fits together (to avoid the next engineer accidentally killing performance due to a misunderstanding of how it’s supposed to work).

On the other hand, CMS and frameworks can actually inform your decisions, as their engineers had faced tasks similar to yours time and time again.

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

#476

Post by Test0129 »

saiya-jin wrote: post #376
m00x wrote: post #213

Earlier quoted context omitted.

> You're bound to their bugs If you do it yourself, you're bound to your own bugs. When they have bugs, it's fixed by a team of highly skilled contributors. Not using frameworks is just an ego problem, or a lack of skills.

I completely agree, unless you are doing something unique, low level where ie latency is the king (which most of us don't), frameworks and libraries shine for 99% of the cases. Some brilliant folks are just bored by usual rather generic work, and their idea of 'fun' is to keep reinventing the wheel that specifically fits current problem. Actual benefits to business be damned, intellectual fun is more important. Once…

> Some brilliant folks are just bored by usual rather generic work, and their idea of 'fun' is to keep reinventing the wheel that specifically fits current problem. Actual benefits to business be damned, intellectual fun is more important. Once those folks leave (and they always leave eventually), its mayhem for the remainder of the team/company.

I could write a dissertation on this statement alone. But let's use two examples. Python and Node. Both are very "never do anything yourself" languages. Lots of libraries, even more frameworks. What's the result?

1. CVEs all over that place that effect nearly anything people touch.

2. Library creep. Pulling in one library or framework pulls in the entire planet.

3. Libraries and frameworks exist for absolute trivia. Node is famous for this, including stupid packages that literally just color text (and not in a meaningful way like a logger).

So in exchange for avoiding your alleged "autistic brilliance" you increase your attack surface 10 fold. I use libraries all the time, I am absolutely sure to limit their scope as much as possible. I won't use libraries for trivia, and I evaluate frameworks extremely carefully. It's kind of funny how often your opinion is parroted in startup forums but for some reason I keep making more money every year despite every signal pointing to me somehow being in the class of engineer that are, according to you, better off without a job.

Companies are run by idiots. The hubris you show is the same hubris a VP of engineering shows having last programmed 10 years ago. It shows a complete lack of nuance and understanding of the engineer.

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

#477

Post by Test0129 »

piokoch wrote: post #265
throwaway0asd wrote: post #73

Earlier quoted context omitted.

> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. After 25 years of experience writing software I can honestly say I have encountered many people that agree with this, and perhaps all of them (every single one) have not actually experienced writing an application without a framework. This sentiment sounds correc…

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…

Seat of pants definition is that a library is something with a single function. Add postgres support, logging (sort of a grey area sometimes), etc.

A framework is something that provides an ecosystem for you to develop in. Rather that using your own style/glue/etc a framework provides all of this for you. Another key aspect of a framework is how much it hides. It's not uncommon that a framework (like rails) hides almost everything from you down to exactly how it's launched. I suppose you could say the hallmark of a framework is it's closer to writing a giant configuration in a bespoke DSL than actual programming.

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

#478

Post by hinkley »

thom wrote: post #229
hinkley wrote: post #179

Earlier quoted context omitted.

One of my goals this winter is to clear my head of as much OOP dogma as I comfortably can, fill it with as much DevEx thinking as possible, and read Christopher Alexander, A Pattern Language, from that frame of reference. My very hot take is that we will start referring to everyone who bought first editions of the Design Patterns book as the Lost Generation, because we have completely misinterpreted Alexander's work,…

I’ve read the original and was underwhelmed from a software epiphany standpoint. Design patterns are just names for deliberate design decisions, so you can communicate them to others who can then deliberately make those decisions themselves. Half the industry still seems to think the GoF book is about C++ not having first class functions.

The problem is that they are milquetoast. They are “design decisions” in the same way that white space is technically code style but really distracts from the real elements of style like structure and meaning (don’t create three meanings for the same word, for example).

Architecture is much bigger than making sure the doors open the correct direction.

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

#479

Post by marcus_holmes »

strogonoff wrote: post #474
marcus_holmes wrote: post #466

Earlier quoted context omitted.

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…

You identify common aspects and snowflake aspects, and in the end the separation as to which parts are snowflake (contain business specifics). That’s your job as software architect. Again, the locations of snowflake parts tend to be similar across businesses, and this is where good frameworks and CMS tend to offer extension points. It’s a spectrum: a CMS may be more fiddly as to customization but more reliable if you…

I work in startups mostly, where requirements are not defined and the business learns as it goes; it's simply not possible to identify all the areas that are "snowflake" ahead of time.

It is sometimes possible to persuade the business that if they create the process in a way that matches the framework it will make life easier for everyone. But often that isn't possible, and often there are good reasons for that.

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

#480

Post by thomastjeffery »

account-5 wrote: post #444
jameshart wrote: post #442

Earlier quoted context omitted.

Any time a piece of software abstracts a repeatable pattern, that’s a ‘framework’. All a framework means is that there is a coherent, repeatable model for implementing the building blocks out of which the application is built. Even a simple command line program with hardly any functionality soon runs into the issue of having more than one command-line argument or environment-variable based configs. And a sensible, ma…

> Any time a piece of software abstracts a repeatable pattern, that’s a ‘framework’. With that definition all programming languages are frameworks. The first part of the article defines what the author means by a framework, which is different from libraries, and programming languages in general.

No, programming languages exist in a different domain. The domain of frameworks is explicitly in toolchains and environments.

It's similar to the difference between function and algorithm. The former is literally code, and the latter is conceptual.

Many programming languages are distributed with a cohesive framework. For example, Rust is distributed not only with rustc to compile binaries, but also with cargo to manage library dependencies. That doesn't prevent you from using rustc without cargo, though, or even making another rust compiler for GCC, and using GCC's framework.

Post reply on HN