Frameworks and Frankenstein | Hacker News Reader

Frameworks and Frankenstein

thecodist.com

30 pointsFollowSteph312 comments

"Sometimes it might be abandoned and now you have to maintain it yourself when OS versions change or other needs appear."

As opposed to rolling your own everything, where you have to... maintain it yourself when OS versions change or other needs appear.

The cognitive cost of maintaining software you designed and wrote is typically much lower than maintaining software which was cleverly written by someone else.

This is particularly true when the actual amount of functionality of some library being used is a tiny fraction of what it has. I've rewritten a few applications that appeared to be designed with "use as many libraries as possible" as a goal, and it usually turns out that many of them could be replaced with not more than a few dozen lines of code. Simple is good. The less code in your application, the less there is to go wrong --- it seems a lot of developers don't realise that library/framework code can also be a source of bugs since it gets executed too, and when something goes wrong in that code they didn't write, are not willing to trace into it to figure out where the problem is.

I'm not advocating doing everything from scratch (by that definition you would probably need to manufacture your own hardware...) but there's clearly a difference between depending on some libraries/frameworks that are stable and well-used (e.g. OS, libc, JVM) and pulling in every library you can find that offers a piece of the functionality you want.

An app that a group of mine bought license to shared that philosophy. The source by the third party hardly works, and it the latest update wouldn't even compile because there were over 65536 (2^16) functions or symbols.

But isn't it almost always written by someone else? Except in very specific instances is there ever an application whose full life is touched only by a single developer. People change jobs, move on to other projects, etc.

I don't think that's true in a well-meshed team environment. If there's substantial continuity of team members, there's a house style and a shared set of approaches that make the code "our code", even if you're looking at parts that happened to be written by people who had left. It's especially the case in pair programming shops, where there's a lot more opportunity for transmission of the history and intent that went into the code.

That holds true only if the code is repetitive, for example big site with a lot of similar pages. If the code is not repetitive, e.g. composed of modules that do very different things or implement non-trivial algorithms, then knowledge of one part does not necessary translate into another.

And if it it is big enough, then everyone knows only small subset of it all, whether you pair program or not.

> The cognitive cost of maintaining software you designed and wrote is typically much lower than maintaining software which was cleverly written by someone else.

If we really took that it's logical conclusion, we'd realize that most software lives too long.

The fallacy with this logic is that software developer turnover is high. So in many cases someone other than you will be maintaining software you wrote. At least when using open source there is often some sort of community of developers that you can turn to whether through Github, Stack Overflow, Google Groups, etc... if you get stuck and have no history with the code.

Substitute coworkers for IRC/Github, and documentation for Stack Overflow and framework pages, and I see you as being in the same place in either case. When those fail, you're stuck with RTFC.

When you're stuck reading the code, if the code was written in a style assumed by your company and by people whose code you've read before, it will have the advantage of being written in a familiar style.

I will grant you, however, if it's a bit of code that nobody has touched for years, open source software will have an edge.

Correlary. The cognitive load of maintaining the previous developer's "framework" is much higher than maintaining something based on open source documented APIs.

Most professionals in this field act as developers and not necessarily engineers. Meaning, their expertise lies in assembling a system out of app servers, frameworks, etc and are not accustomed to building any individual piece from scratch. And in nearly all cases this is what they are hired to do, use well known technologies to solve a problem.

It is up to the architect of any system to choose these technologies wisely. I tend to favor extensibility and degree of coupling in my design decision which can lead to an over engineered complex solution. However, I rarely regret doing so. The time upfront pays off when changes are requested.

Reply on news.ycombinator.com