negative sculptor
remove the extraneous
approach peace of mind
For any requirement R, design and build the simplest thing that achieves R. Basic engineering consists of providing a solution that satisfies R; good engineering then consists in taking away as much as possible, such that R is still met. We never consider a project complete until it's been reviewed for any extraneous code, any possible points of simplification.
Hand-in-hand with this idea is to minimize the demands of R -- in other words, avoid feature-creep.
We are mired in an age of increasing complexity, where computational power is cheap. The bias is to add more and more layers, use higher-level languages, take advantage of higher-level frameworks, more conceptual abstractions. With billions of CPU operations per second available, developers can often get away with this.
The complexity of a solution includes the complexity of all components (libraries, SDKs, packages, OS support, CPU, third-party tools/systems, etc.) used to deliver the solution. One of the prevailing problems with modern software practice is the universal dependence on external frameworks. It's considered good practice to be relying on someone else's code, so that you focus on specifically what your application needs to do.
This can be good practice, of course; but it's more often abused. There is a cost to all dependence on external tools, and the problem begins to show itelf when a developer doesn't understand exactly how the complete system is working. Mysterious failures happen, with no sense as to the underlying cause (we've inherited too many projects with this type of problem). Furthermore, this leads to bloat -- dependencies rarely include only the functionality needed by your project. This increases the risk of integration and versioning conflicts for irrelevant reasons.
Our practice is to continually seek the simplest solution -- after accurately accounting for all forms of complexity, including dependencies. Simpler means more understandable, easier for others to build on, easier to maintain. Remove dependencies, remove unused code. Refactor. Cut, cut, cut. The best diffs are mostly red.
It's also a form of self-reliance. Own as much of the code and implementation as possible. Understand how things work, from the user interface down to the CPU microarchitecture. Then, when there are problems, you can study them, and understand them -- and fix them.