Just like anybody can reinvent the wheel, anybody can write another XML parser or a framework or any number of other ‘solved problems’. It’s so rarely worth re-solving a problem that you should probably not entertain the idea unless you know for sure why you need to re-solve it. That is, build on whatever is close enough to your needs until replacing it becomes the highest priority.
Looking at XML parsers, let’s say you’re doing something really simple like extracting a particular attribute. I maybe tempting to write something that flies through the input file looking specifically for you attribute. By writing your own, you’ll skip over lots of things a standard XML parser does internally and you’ll save clock cycles. I’ll even give you that in some cases, you might even be able to write a quick and dirty parser faster than integrating a standard library.
However, here’s where you lose out. First, the existing library is tested. It handles bad input gracefully. Other developers have seen used it before and are familiar with it. The library will be upgraded by its maintainers. The library is configurable. When you second use case for XML parsing comes up, the library probably handles it. If you write your own, you’ll end up having to do build features eventually. So just save some time and take advantage of what’s out there.
Integrating and building upon what already exists is skill in itself. If you know how to integrate/reuse code across various platforms and tech stacks, you become proficient in accelerating delivery of the final product. That is, take a developer that knows how to leverage Ruby on Rails and DynamoDB, or one who knows how to compare Spring and Google Guice. Compare them to somebody who learns of web frameworks and NoSQL and decides to build their own. Or one that learns of inversion of control and figures Spring and Guice are too complicated. Who’s going to build the product faster? Who will end up with a higher quality, more flexible product?
Plus if you zoom out a bit, it’s silly. Could you imagine what would happen if every time you wanted to write an web application you had to start with writing firmware and an operating system? We would get nowhere! Do what you can to focus on what new functionality you’re building. To do this, you should try to reuse all the software you can to avoid tackling solved problems.
When should you invest in a better framework? Probably after you’ve used the existing frameworks a bunch of times and found when/where and how often the existing frameworks foul you up or slow you down. A new framework is expensive to build and maintain. Are you going to get a return on that investment? Maybe. You’ll know for sure after you’ve developed a few apps in the existing world.
It takes a good engineer to reuse code to build something new, anybody can write it again!
1. Don’t re-solve solved problems.
2. Leveraging other folks’ code is a valuable skill.
3. Only attempt to provide a better solution when:
a. improving the existing solution is the next highest priority for your product
b. you have gained the experience of using exiting solutions and identified the parts that need improvements. Even then, think about improving the existing solution.
Rovio, creator of the game Angry Birds, used an open source physics engine called Box2D. At the Game Developers Conference (GCD), the author of this physics engine stood up and asked if the company would agree to credit the physics engine. Rovio agreed! What’s the bonus? Even a game company whose core mission was to build a physics-based game, used an open source piece of software. That is, they treated modeling physics as a solved problems and worked on game play, artwork, marketing, etc. before considering to write their own physics engine.