How to actually ship software that actually works(medium.com)
medium.com
How to actually ship software that actually works
https://medium.com/@thomasfuchs/how-to-actually-ship-software-that-actually-works-cf269f6578f7
1 comments
Hey, I'm Thomas, the author of the article. I do agree with your observations pretty much entirely.
I'm mostly talking about the "throw a component, library or jQuery plugin at everything" sort of mentality. That just yields and unmaintainable buggy mess—unfortunately I've encountered this all too often in the wild. (While I was a consultant, I could make a good living from cleaning up these messes, so I won't complain too much!)
It all boils down to, however, a willingness to actually think about the things you're doing, and trying to do good solid work. IMO not enough people do that, or even aspire to do that, which makes me a bit sad about "my" profession.
I'm mostly talking about the "throw a component, library or jQuery plugin at everything" sort of mentality. That just yields and unmaintainable buggy mess—unfortunately I've encountered this all too often in the wild. (While I was a consultant, I could make a good living from cleaning up these messes, so I won't complain too much!)
It all boils down to, however, a willingness to actually think about the things you're doing, and trying to do good solid work. IMO not enough people do that, or even aspire to do that, which makes me a bit sad about "my" profession.
- You don't have to write the code (obviously)
- Popular packages are likely to be free of the more obvious bugs since many people have already used it.
- If you have a common problem, someone probably has a ready made solution on StackOverflow
- You can hire people who already know the library/framework so training time is reduced.
- You can often avoid learning anything about how the library works and only pay attention to the API (saving learning time). Probably more importantly, there are some things you should not write yourself because you are almost guaranteed to get it wrong the first few times(dates and timezones, encryption, etc, etc).
But there are advantages to writing your own too:
- Because you only have to solve your problem and not the problems of 2 million other users, your solution can often be an order of magnitude smaller. Less code, less bugs, more flexibility.
- The solution can be tailored to your problem exactly. Often you need to work around design decisions made in the original library (this is especially true of frameworks). These work arounds tend to breed other work arounds as each one creates undesirable code. Sometimes the use of a library that is close, but not quite what you want results in so much disruption to your design that you would have written less code had you not used the library.
- You don't have to deal with political problems with people you have never met. Often maintainers make strange decisions which they refuse change, leaving you out in the cold. You often have nothing but a passing relationship (at best) with the maintainer, so it is often next to impossible (and incredibly time consuming) to negotiate design choices, bug fixes, etc going forward. This is especially true if package X depends on package Y, but the maintainer of package Y has significant personality disorders. Trying to track down all the dependencies of package X and identifying possible risks can be quite difficult.
- Being forced to know how everything works can often bring significant benefits down the road. This is especially true for security issues.
Clearly I don't avoid libraries and frameworks entirely. That's cutting off your nose to spite your face. However, when evaluating libraries, I usually favour writing my own unless there is a popular, well supported library that does exactly what I want and very little more. Or if it is one of those things that you should not write yourself because you will certainly get it wrong.