5 ms·

Point #8 sounds great: reuse OSS, don't reinvent the wheel. However, this only applies to software that is maintained, now and in the future. Relying on obscure

by edejong 10y ago

Point #8 sounds great: reuse OSS, don't reinvent the wheel. However, this only applies to software that is maintained, now and in the future. Relying on obscure code-bases without knowledge on its inner workings is going to bite you down the line. Examples? Grunt, Bower, Hibernate, Apache Commons. How long did it take the Apache Commons project to properly add generics to its libraries? How is backward compatibility and developer availability holding back projects down the line? Additionally, in order to use a library, you need to have a good knowledge of the problem it tries to tackle. By overly relying on open source software, you might blunt the competitive advantages of your business. It's an example of exorbitantly relying on abstraction.

dom0 10y ago
I like to think of this as a dependency cost. Adding a library may "relieve" implementation cost, but adds a dependency cost (ie. finding+evaluating dependencies, integrating and maintaining the dependency, testing the dependency and so on). This cost varies a lot, for example a library to left pad a string may be easily replaced, but if you choose a library to implement some on-disk format, then that can cement things in. If the library becomes unsupported one very well may end up maintaining it alone, for example. In the more general case more issues are attached: choosing a deployment stack, a documentation or translation tool etc. can result in decisions that are essentially set in stone. These also tend to be composed from multiple tools, leaving more wiggle room. Deployment for example might be done with AWS and Ansible on the higher levels, but use in-house tooling for figuring out the details. Similar arguments apply to code de-duplication and DRY: de-duplicating code isn't free, and not always the right thing to do. See also: http://blog.liw.fi/posts/dependency-cost/ http://blog.liw.fi/posts/dependency-cost/
- collyw 10y ago
  This varies a lot. Python generally has good libraries. JavaScript (in my experience) generally has far more fragile libraries and its a lot faster moving, so the dependency cost is more likely to bite you. Usually there are a few libraries doing the same things, so go for the mature ones.
- bsder 10y ago
  > if you choose a library to implement some on-disk format, then that can cement things in. If the library becomes unsupported one very well may end up maintaining it alone, for example. But, presumably, you used that specific format because you needed it. So, it makes sense that you take it over if it gets abandoned. If the problem is that you didn't need that specific format, then you should rip it out completely when (and only when) that library becomes unsupported.
taeric 10y ago
Grunt is already considered an obscure codebase? It is barely four years old!? Or, are you just saying that if you have a complicated problem you will probably need to know specifics of how these tools work? I can buy that. I do question how many people are truly doing something complicated where these tools wouldn't be sufficient.
- edejong 10y ago
  Have a quick look at the code graphs of Grunt: https://github.com/gruntjs/grunt/graphs/contributors https://github.com/gruntjs/grunt/graphs/contributors Also, consider how the main contributor (cowboy) last commited in May 2015. This is just a cursory github-health-scan (tm), but it tells me two things: - Don't expect any large changes in the grunt code-base in the coming years - The code-base is probably not easily modified (either caused by low code quality or of the risk of breaking builds).
  - ktRolster 10y ago
    Don't expect any large changes in the grunt code-base in the coming years A lot of people consider that a good thing.
    - edejong 10y ago
      TeX is probably a great example where the codebase converged on 'perfection'. A fixed set of features, practically bug-free, superb quality. I could mention some flaws of TeX, and observe how many are related to input, output and environment: - archaic syntax. Even though it has an interesting design philosophy, it does not adhere to the syntax (input) most programmers are used to (you know if you ever tried to write TeX) - does not take advantage of modern system architectures. Needs to process a TeX file multiple times. - does not allow animation (this was not a requirement, nor a possibility back in the 70's) - not much interactivity (yes, URLs are possible, but it's mostly a hack). Web wasn't available back then. - output format (DVI) limits possibilities So, even though I like TeX and its attention to detail, it was already dated when I started using it in 2000. In our landscape, adaptability is an important trait of libraries.
Roboprog 10y ago
Yeah, I enjoyed the "Invented Here Syndrome" article that was posted here a few days ago, for just those sort of reasons.
Roboprog 10y ago
Along that lines, it's also funny when somebody does an "armchair quarterback" of an older codebase. A company I used to work for was closing its local office, and moving the work we did closer to the home office. One of the lead/architect types asked my friend who was still there at the time "Why didn't you use something like Spring Batch for this?". He accurately responded "Because it didn't exist in 2005." That said, I'm glad something like Spring Batch (at least for Java) is around now. I've had to implement a partial version of something like that 3 times in the last 20 years :-) (Both a C version and a Java version for turning client file dumps into mass mailing print output; a Java version for doing ETL type jobs for in/out bound client integration feeds) That said, I've seen under-engineered batch jobs that mix incremental input and output in a giant spaghetti loop, rather than taking the time to do a bit of partitioning (e.g. - ye ol IPO, Input-Processing-Output), so that you can do things like selectively run certain input units, or recover from bad data in individual input units.
flukus 10y ago
Depending on the library, picking up the maintenance yourself can be less costly than reinventing the wheel.
clifanatic 10y ago
> Examples? Grunt, Bower, Hibernate, Apache Commons. Oh, luxury, I tell you - Grunt, Bower, Hibernate and Commons are the most obscure, unmaintained third-party "solutions" that you have to deal with? I'm over here dealing with vanity projects like "Dozer" and "XmlBeans".
- edejong 10y ago
  Well, I tried to find projects which are well known but still going into obscurity, which is kind of a contradictory requirement.

by edejong 10y ago

dom0 10y ago

I like to think of this as a dependency cost. Adding a library may "relieve" implementation cost, but adds a dependency cost (ie. finding+evaluating dependencies, integrating and maintaining the dependency, testing the dependency and so on). This cost varies a lot, for example a library to left pad a string may be easily replaced, but if you choose a library to implement some on-disk format, then that can cement things in. If the library becomes unsupported one very well may end up maintaining it alone, for example. In the more general case more issues are attached: choosing a deployment stack, a documentation or translation tool etc. can result in decisions that are essentially set in stone. These also tend to be composed from multiple tools, leaving more wiggle room. Deployment for example might be done with AWS and Ansible on the higher levels, but use in-house tooling for figuring out the details. Similar arguments apply to code de-duplication and DRY: de-duplicating code isn't free, and not always the right thing to do. See also: http://blog.liw.fi/posts/dependency-cost/ http://blog.liw.fi/posts/dependency-cost/

collyw 10y ago
This varies a lot. Python generally has good libraries. JavaScript (in my experience) generally has far more fragile libraries and its a lot faster moving, so the dependency cost is more likely to bite you. Usually there are a few libraries doing the same things, so go for the mature ones.
bsder 10y ago
> if you choose a library to implement some on-disk format, then that can cement things in. If the library becomes unsupported one very well may end up maintaining it alone, for example. But, presumably, you used that specific format because you needed it. So, it makes sense that you take it over if it gets abandoned. If the problem is that you didn't need that specific format, then you should rip it out completely when (and only when) that library becomes unsupported.

taeric 10y ago

Grunt is already considered an obscure codebase? It is barely four years old!? Or, are you just saying that if you have a complicated problem you will probably need to know specifics of how these tools work? I can buy that. I do question how many people are truly doing something complicated where these tools wouldn't be sufficient.

edejong 10y ago
Have a quick look at the code graphs of Grunt: https://github.com/gruntjs/grunt/graphs/contributors https://github.com/gruntjs/grunt/graphs/contributors Also, consider how the main contributor (cowboy) last commited in May 2015. This is just a cursory github-health-scan (tm), but it tells me two things: - Don't expect any large changes in the grunt code-base in the coming years - The code-base is probably not easily modified (either caused by low code quality or of the risk of breaking builds).
- ktRolster 10y ago
  Don't expect any large changes in the grunt code-base in the coming years A lot of people consider that a good thing.
  - edejong 10y ago
    TeX is probably a great example where the codebase converged on 'perfection'. A fixed set of features, practically bug-free, superb quality. I could mention some flaws of TeX, and observe how many are related to input, output and environment: - archaic syntax. Even though it has an interesting design philosophy, it does not adhere to the syntax (input) most programmers are used to (you know if you ever tried to write TeX) - does not take advantage of modern system architectures. Needs to process a TeX file multiple times. - does not allow animation (this was not a requirement, nor a possibility back in the 70's) - not much interactivity (yes, URLs are possible, but it's mostly a hack). Web wasn't available back then. - output format (DVI) limits possibilities So, even though I like TeX and its attention to detail, it was already dated when I started using it in 2000. In our landscape, adaptability is an important trait of libraries.

Roboprog 10y ago

Yeah, I enjoyed the "Invented Here Syndrome" article that was posted here a few days ago, for just those sort of reasons.

Roboprog 10y ago

Along that lines, it's also funny when somebody does an "armchair quarterback" of an older codebase. A company I used to work for was closing its local office, and moving the work we did closer to the home office. One of the lead/architect types asked my friend who was still there at the time "Why didn't you use something like Spring Batch for this?". He accurately responded "Because it didn't exist in 2005." That said, I'm glad something like Spring Batch (at least for Java) is around now. I've had to implement a partial version of something like that 3 times in the last 20 years :-) (Both a C version and a Java version for turning client file dumps into mass mailing print output; a Java version for doing ETL type jobs for in/out bound client integration feeds) That said, I've seen under-engineered batch jobs that mix incremental input and output in a giant spaghetti loop, rather than taking the time to do a bit of partitioning (e.g. - ye ol IPO, Input-Processing-Output), so that you can do things like selectively run certain input units, or recover from bad data in individual input units.

flukus 10y ago

Depending on the library, picking up the maintenance yourself can be less costly than reinventing the wheel.

clifanatic 10y ago

> Examples? Grunt, Bower, Hibernate, Apache Commons. Oh, luxury, I tell you - Grunt, Bower, Hibernate and Commons are the most obscure, unmaintained third-party "solutions" that you have to deal with? I'm over here dealing with vanity projects like "Dozer" and "XmlBeans".

edejong 10y ago
Well, I tried to find projects which are well known but still going into obscurity, which is kind of a contradictory requirement.