How to write software than will keep working for decades without problems | Hacker News Reader

How to write software than will keep working for decades without problems

unixsheikh.com

74 pointskaeruct21 comments

Someone once told me "If you're not using a framework, you're building one".

I thought a lot about the many implications of that sentence, one of which is relevant for this article. Understand that you _WILL_ always use a framework, whether it's an external one or your own. Knowing this, when choosing not to use an external framework, you must show consideration to the design of the one you're inevitably building, and chose to build it intently, rather than by accident.

I'm entirely in agreement with every sentiment of this article, not only does it make software that will last longer, but for some of us at least, makes for a much more fun, interesting and enjoyable development experience.

Writing a program from scratch actually feels like programming, it feels like doing the thing we're here to do, rather than laying the plumbing that ties together a multitude of third party, constantly-changing (if not just randomly disappearing from the internet) frameworks together.

I think the point that the article was making is that if you don't use a framework, even if you make your own, then you can select the libraries you are using by how supported they are.

The other point about building your own "framework" is that you can reduce the library count significantly. You don't need to include a library you only need one function from... Just reimplement that function in your own code.

I wrote a system in the 1980s in Turbo Pascal under MS-DOS to talk to a bunch of hardware, and keep a display updated. It did large water meter calibrations, for city size meters, 6" and up.

That software survived Y2k with no incident, the only reason I heard about it was in 2007 when one of the cards was replaced, it failed to restart.

It turns out they had the two cables swapped. As far as I know it's still going strong.

I followed most of the rules detailed in the article, it was simple, did the one thing (including a multitasking library I wrote), and just kept doing it.

> when you're dealing with a team of developers because then everyone will know that framework and understand the software

I can't name a framework I've ever worked with that anybody actually understood.

>Most frameworks nowadays has [sic] become so stupidly complex that they almost require more time to understand that the underlying programming language.

I mean they do mention that just after, and I agree. Often the frameworks take away a few hours of boilerplate work in the beginning in favor of weeks and months of learning and issues.

This is a low quality flamebait article.

> Very rarely is the added complexity of frameworks justified and the added risk of breaking stuff down the line makes it a NO GO for serious software deployments. Only toy software and very small applications can justify the usage of frameworks and the likes.

There are definitely downsides to using frameworks, but this statement directly flies in the face of evidence. There's a ton of commercially successful software using frameworks, just think of all the things that are powered by React, Ruby on Rails or Spring Boot.

I find the idea that I, sitting in my basement office, could hand-craft something nearly as powerful and maintainable as Spring Boot, as part of the project I'm actually working on, totally laughable.

And the idea that this bespoke framework would somehow be more maintainable in five years is just lunacy. Even if Spring falls out of fashion, you'll still be able to find people that have a decent knowledge of Spring in five or ten years, just like you could find people who knew COBOL in the 90s. But how are you supposed to hire for "some guy that can figure out WTF this dude was doing when he wrote his own ORM a decade ago?"

How many frameworks can you fit into one app?

The problem by not using a framework is that you're going to reinvent one. Will it be better than what's available depends on your talents but one thing is sure: you're going to have to maintain it and won't have as many eyes on it.

I guess your mileage may vary so it's a case by case decision.

You don't have to invent a new framework. You just need enough for one application. Think of the simple MVP that every framework is on their first release.

I'd say unless what you are doing is quite close to what thousands others do, there's a bunch of stuff in the framework thought for other projects, not yours...

"It's easy and quick to make junk! Quality requires time and deliberation."

This is the cause of most of the problems I have seen. Businesses want quick over quality. Sometimes this is the right business decision.

In the startup world, this is often the right decision because businesses don't even know if they're making a valuable product yet.

* Ship quick

* Validate

* Build for the long term

Except that it's often:

  1. Ship quick

  2. Return to step 1

Maybe it's:

    grind:
        ship_quick()
        if (is_market_leader()) {
            hire_maintainer()
        } else if (failed()) {
            abort()
        }
        goto grind

Write it in C and make sure it compiles on a POSIX system. Next question.

Evidence: most of you are running such software, the internet infra depends on it, etc...

I'd be comfortable with a halfway approach to this article.

- Ship and implement as much as you want when you need tight control. - But build on solid foundations which are already well established, so that you don't end up reinventing the frigging wheel.

I have a Flask app which is nearing 8 years old and it's going fine. Nowadays, I'm starting my backend python APIs with FastAPI, and feeling very comfortable.

I think the author misses the obvious:

Write your code as if you actually expect your code to be still working and maintainable after decades in the first place.

I wonder as to what types of functions the author speaks of on "Make custom functions, don't rely on the platform". The article mentions a "PHP 4.x. (application) which is now running on PHP 8.0". Does that mean that the author has avoided using portions of the PHP API? If so, is anyone able to think of something that the author could have done in this case?

One of my former -and very nice- employers would be happy to read this (that's exactly what he has been doing for ages :)

I think out-of-the-box PHP kind of is a framework, at least compared to what you get in most other languages.

Reply on news.ycombinator.com