Reusing Existing Components vs. Building your own Why "reinventing the wheel" is often much better than its reputation
I'm currently working on an ExtJS-based web front-end that uses different sorts of charts to visualize data. For those of you who haven't heard of ExtJS yet: It's a JavaScript library/framework that provides a large collection of UI elements (buttons, menus, tabs, layouting containers etc.) and associated „helper components“ to build desktop-style web applications using desktop-style programming paradigms. Think of a „Qt or WinForms for the browser“. It's not the coolest kid on the fast and ever changing block of web technologies anymore, but it still fills a specific niche and does its job quite well there.
Being an all-round carefree package, ExtJS also provides a wide variety of pretty and highly configurable „out of the box“ charting components – so far, so good. However, the aforementioned application has several parts where I think that none of the pre-made ExtJS charting components really fit the requirements: In one case, the user needs to be able to edit a piecewise linear function by adding, dragging and removing support points in a line chart visualization of the function. The second is a "timeline" chart, where the structure of the displayed data and the required modes of presentation and interaction are very different from the assumptions of the ExtJS charting API. Using ExtJS for this smells like an ugly hack right from the start. However, I am no ExtJS expert. I can not rule out that there are simple and clean solutions for these problems that I'm just not aware of – or that there are at least solutions that require some hacking, but would still be done faster than building my own from scratch.
In a case where I know that an existing component suits my requirements perfectly, with no need to dive into and modify its code, I'd of course simply use it without a second thought. The whole software development world is founded on this principle, and in most cases, libraries are successfully designed to maximize reusability. Not making use of this where it is easily possible would be plain stupid, except in situations where you really have a lot of time and want to build your own solution for the sole purpose of learning, and/or fun (these are perfectly valid reasons, but hardly justifiable in the professional realm).
However, there are also situations – like the ones described above – where it's not immediately clear whether reusing existing components or implementing your own solution is the smarter way to go. In such cases, the right decision heavily depends on „soft“ factors that involve very personal needs and perferences.
Creative Work vs. „Mechanical“ Work
I love programming challenges. I love to figure out great solutions for coding problems, I love to learn new things. However, I'm not talking about googleing and digging through documentation and unknown source code for hours or days and copy-paste tons of sample code into my program without any real intellectual effort. I'm talking about making real use of my brain to think about interesting problems and create things that I have not created before. The repeated alternation between mental challenge and the rewarding experience of success that makes up creative activity puts me into a mental state that psychologists call „flow“. The flow state is like a „high-performance autopilot“ for humans: When you're in flow, you're so deeply focused on your work that you do it without noticing any unpleasant effects of effort, almost automatically, with the highest quality and efficiency that you're capable of. You don't even notice the passing of time any more. I do not only love to work in this state – I need it in order to be productive in the way that I expect from myself.
At least for me, building programs by simply plugging together and configuring premade components with no real intellectual contribution of my own is a total flow killer. Even more so when it still requires a lot of reading and trial-and-error that is tedious and hardly gives any real and new insights. So, for me, one huge argument for building my own solutions is that it is often much more enjoyable than working with pre-made components – and also often much more productive, even if this might sound counter-intuitive at first.
Of course, reusing existing solutions and developing new do not completely rule out each other: By its very nature, every software development project requires some parts to be newly created. But for me, in order to stay motivated, it's important that I can spend more time with creative work than with rather „mechanical“ integration of existing functionality.
Learning by Doing vs. Learning by Looking
Another big factor that is closely related to the motivational aspects discussed in the previous section is the learning effect: For me, writing my own code is the best way to really understand how something works. And especially when I'm highly interested in a specific programming topic, I want to implement my own solutions from time to time in order to increase my knowledge of how things are done in that field. To stick with the introductory example of ExtJS charting: I'm interested in computer graphics and visualization, so I have a naturally high motivation to take chances that allow me to practice coding of charts. Even a complete „reinvention of the wheel“ (i.e. recreating something that already exists in exactly the same form) can make sense, since it helps you to acquire knowledge that you'll need to create more unique, specialized solutions in the future.
On the other hand, being able to read, understand, integrate and modify code that was written by other people is an important skill, too. Unfortunately, most programmers appear to have aversions against doing this. I plead guilty to this, too. Apparently, most of us developers prefer to either use third-party components only through their external APIs - without looking at or even touching the internals - or build our own solutions from scratch. The middle ground – modify and extent existing code to make it fit our purpose – is unpopular for reasons that are not immediately clear to me. Is it because we don't like to be forced to think along paths layed out by others? Is it because we don't like to see the complexity and unneeded extra features in other people's code and think that we don't want to „pollute“ or „overengineer“ our own program with that, but happily accept the same things as long as they are nicely hidden behind public APIs? In any case, the reasons are probably more emotional than rational.
For my ExtJS application, I eventually decided to implement my own solutions for those non-standard visualization components, using the HTML5 canvas element. In the case of the function editor, I at least strongly believe that by following the „do it yourself“ path, I solved the problem much faster than if I had tried to modify existing ExtJS charting code. In the case of the timeline, I am absolutely sure, without the slightest doubt. By now, there were so many custom features added to it that are not even remotely supported by the ExtJS charting API, that I can in no way imagine how I could have used it as a foundation without basically rewriting everything. Admittedly, this is still "only" a an assumption, a belief. The only way to really find out which way is faster and more future-proof would be to try both and then compare. Unfortunately, I don't have the time for this.