4 ms·

Frameworks and Frankenstein

30 points by FollowSteph3 12y ago

al2o3cr 12y ago
"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.
- falcolas 12y ago
  The cognitive cost of maintaining software you designed and wrote is typically much lower than maintaining software which was cleverly written by someone else.
  - userbinator 12y ago
    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.
    - cordite 12y ago
      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.
  - joekrill 12y ago
    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.
    - wpietri 12y ago
      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.
      - watwut 12y ago
        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.
  - michaelfeathers 12y ago
    > 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.
  - bigtunacan 12y ago
    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.
    - falcolas 12y ago
      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.
  - shanemhansen 12y ago
    Correlary. The cognitive load of maintaining the previous developer's "framework" is much higher than maintaining something based on open source documented APIs.
buckbova 12y ago
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.

30 points by FollowSteph3 12y ago

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

falcolas 12y ago
The cognitive cost of maintaining software you designed and wrote is typically much lower than maintaining software which was cleverly written by someone else.
- userbinator 12y ago
  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.
  - cordite 12y ago
    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.
- joekrill 12y ago
  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.
  - wpietri 12y ago
    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.
    - watwut 12y ago
      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.
- michaelfeathers 12y ago
  > 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.
- bigtunacan 12y ago
  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.
  - falcolas 12y ago
    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.
- shanemhansen 12y ago
  Correlary. The cognitive load of maintaining the previous developer's "framework" is much higher than maintaining something based on open source documented APIs.

buckbova 12y ago

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.