Comment by Cthulhu_ | Hacker News Reader

Comment by Cthulhu_ | Hacker News Reader

Parent Full thread

It's the same logic used when people decide to build their own framework, or advocate against not using a framework - by writing everything yourself, you'll understand everything. It boils down to "other people's code is hard to read", which can probably be extended to entire languages and other concepts as well.

It's in part laziness - reading and understanding someone else's code takes a lot of focused effort. But it's also a matter of gratification - writing code is far more satisfying (IMO) than reading and comprehending others'. Most developers I know - and probably myself included - are of the "I get paid to write code" mentality, and often not really being mindful of whether what they write now will still be understandable in 5 - 10 years time. Sure, they will follow best practices, clean coding and all that stuff, but what about (high-level) documentation? Revisiting the user stories from which the code was born? Writing good commit messages and pull request descriptions? These all seem secondary to the code itself, which I guess is true to a degree, but all that other stuff is important too.

Getting into a new project is hard. Starting from scratch and writing your own is easy. Writing code and other stuff so that others getting into your project is easier is hard (as is allowing others into your domain and code for that matter)

> It's in part laziness - reading and understanding someone else's code takes a lot of focused effort. But it's also a matter of gratification - writing code is far more satisfying (IMO) than reading and comprehending others'.

No, it is rather the problem that other people's source code changes all the time. If the other programmer can assure me that his source code is good enough that it can be used for 10-20 years without any problems (and will be maintained this long time) and the only changes that will happen are small bugfixes, I can easily be convinced to read into all the gory details of it (of course only if the source code is useful), since I know that the knowledge that I gain by diving into these details will help me for many years after.

The situation that we have is that every few months a new framework comes out and such a deep reading into is not worth it since in a few month something new will come and in few years the original framework will be forgotten, making all the investment into understanding it deeply worthless.

Something I never see mentioned, and something that's honestly the biggest barrier to me adopting an appropriately licensed third party library or framework, is code style. If you use several libraries with significantly different coding style, your own code becomes a horrible mishmash of random capitalisation, calling conventions, allocation/deallocation/ownership conventions, etc. and your ability to easily interpret your own code goes out the window.

What I usually end up doing is wrapping each third party library with a thin wrapper which uses my own conventions, to isolate the differences, but still, this is a pain. When you add this pain to the pain of finding a library that does what I want, and the pain of figuring out how to use it despite often poor documentation, and the pain of having to debug weird edge cases that the developer never encountered, you get a pretty sizable disincentive compared with just implementing your own.

Agree that maintainability is important, disagree that frameworks = maintainability. I'd rather maintain an application written 10 years ago from scratch, than an application written 10 years ago using a framework that was popular then.

When it's all said and done with, software needs to be consistent and meet the expectations of its users.

If it does that, the question of a framework or high level documentation or user stories don't matter. Those are tools used to help achieve the above govals, but if you can do so without the use of the tools then the tools aren't all that useful for that particular project.

I sometimes think people miss the forest for the trees. I make the same argument about tests and TDD, the goal isn't tests, the goal is stable, maintainable software. If you can do that without tests, then you don't need tests, and that's ok.

Reply on news.ycombinator.com