Live data from Hacker News

Using a framework will harm the maintenance of your software

berk.es

411–420 of 550 posts

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

#411
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".

Spring nowadays supports the JDK-native annotations where the exist, and they have a lot of Spring-agnostic libraries under their umbrella.

But I'm inclined to agree on the case of Spring Boot... It's meant to be a "convention over configuration" kind of thing, so I guess by nature it ties you in pretty hard.

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

#412
post #232

Earlier quoted context omitted.

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".

Yeah Spring is obviously deliberately obfuscated, which makes perfect sense considering the business model.

Haha yeah I'm curious what Spring will become now that the big ones like IBM are milking the cloud-native cow with Quarkus instead of Spring...

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

#413

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'd propose a different dichotomy: those that have good experience using and developing complex systems, and those that don't. The former are more likely to fit with your dichotomy, while the latter are more likely to do what's best for their project.

Though nobody can predict the future and what seems like the right choice initially might not be later on.

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

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

Re point 1: yes. But it’s your bug ridden half framework and you don’t depend on external developers to make sane decisions. I’ve been using static site generators for my product site and app documentation and every time I set up a new dev machine e (or just update the generator) I’m in dependency hell because some plugins had breaking changes etc. that’s why I switched to my own bug ridden php implementation of the…

PHP is a bit of a special case here. I returned to PHP after 10+ years of hiatus and was surprised how easy it is to get shit done for the web, I had forgotten all about it.

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

#415
I would add that frameworks:

* promote helplessness by abstracting away fundamental but tedious tasks one ought to know how to do,

* erode the capacity for innovation by making it difficult to contemplate or impossible to implement solutions outside the framework's feature set,

* achieve an equilibrium I call 'mutually assured mediocrity' in which a programmer or organization necessarily vows to remain at the same low level of technology as their competitors.

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

#416
post #209

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…

Maybe you should master your tools before using them. You can use frameworks where they fit, and not where they don't. Knowing when to do which takes time and experience, but it is definitely do-able, and better. Frameworks allow you to update, and maintain your app for free, since others will do it for you. If you do it yourself, you have to do all the work and that's keeping you from adding value elsewhere. To not…

I think you misunderstand the value proposition. In order to spend less effort on maintenance, thus freeing yourself to add value elsewhere, you need increased automation. That automation may or may not include a framework but is absolutely not limited to frameworks.

I instead prefer test automation to frameworks for automation. They are both tech debt, but only one of those provides a layer of risk mitigation (regression detection or changes to business requirements). The other provides a substitute for training, experience, and soft skills which suppresses risk realization. Just because the danger is hidden to lower layers does not indicate the danger is gone or avoided. If this were true frameworks would eliminate the need for testing and quality assurance.

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

#417
post #52

I decided not to use a framework. I spent about a month going over the "TodoMVC.com" demos with the intent to choose one but after a few weeks of pondering which one I concluded I didn't want to invest in any of them. jQuery and Mustache.js do a lot and are easy to use. CouchDB and PouchDB are too and that gave me user authentication, a powerful server side DB, and offline-first/local-first features. I've never regre…

> CouchDB and PouchDB are too and that gave me user authentication, a powerful server side DB, and offline-first/local-first features

I use CouchDB / PouchDB as well, but I'm curious about user authentication: I had to implement a wrapper around it (in Node), because CouchDB auth is extremely limited. For example, I want users to sign up by email + password (not username) and I want them to be able to change their username. CouchDB itself basically has no concept of that. You make a user with a name and that's it. Can't change it without additional code.

How did you solve this?

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

#418

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…

> perhaps all of them (every single one) have not actually experienced writing an application without a framework I actually have written software without a framework, so by this standard I feel qualified to comment. 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 la…

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.

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

#419
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 written without a framework several times. Pretty soon realize I’m spending my time writing up a framework.

I’ve inherited non framework projects many times. They take way more time to get up to speed on.

Now I’ve seen framework projects where they clearly didn’t try and work with it. Those ones just make me sad.

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

#420

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…

In my current job, I have written a small framework. It's very limited in scope and hasn't changed much since the initial implementation, so it works fairly well. But, there is a big issue with getting other team members to understand how to use it. That alone is enough that we're replacing it soon. Another team member has developed frameworks for both infrastructure management and creating services exposed over http…

I am a big believer that the primary business benefit of frameworks is that they ease hiring (candidate selection). There are pros and cons to that.

Where I currently work they primarily rely on nontechnical qualities for candidate selection because they are more interested in choosing the right people than a tool user. Either way they will be investing time in training in some form and would rather that training focus on the business objectives than the technical objectives. Counter-intuitively I was entering the code earlier here than at previous employers even though I am writing in a language I have never touched before. This is likely because I entered this employment drowning in deliberate one-on-one training.

Post reply on HN