distributedlife

passionate about everything

Reinventing the Proverb Published by Ryan Boucher @ 10:55 pm

Anyone that knows me knows that I like to work on my own code. I seem to have this aversion to using other people’s frameworks and only just recently can I articulate why.

Anyone that wants to jump to conclusions can write off my own code obsession as someone that is overly protective of their code base, controlling or someone that just likes to write code regardless of the time lost when there exist frameworks that do the same thing.

I’m going to latch on to the last part of that sentence; frameworks that do the same thing. That to me is the key. The definition of ‘do the same thing’ is so loose it becomes irrelevant. Is it functionally the same?  Probably, what about non-functional requirements of performance, scalability, flexibility, security, robustness, language, etc, etc. Functionally; any framework that I want has almost always already been created. For a framework to operate with the same non-functional requirements I have in mind then the numbers are smaller, much smaller.

Has it even been tested? This one is a killer, there are many frameworks out there, but how many of them have been rigorously tested? Did the tests pass? Do they have a public bug tracking system so you can see what outstanding defects exist? Do they have a publically available list of test cases that are executed against each build? This applies to proprietary frameworks as well as open-source ones.

Does it cater for anyone wandering of the beaten path? I am usually working on non-trivial, non-standard applications, happily working away until I get to a point where I want to diverge from the narrow path defined by the framework. You either have to not-implement what you want to do, or use a work around, or throw the framework away. A proof of concept should stop this from occurring, but there is always the problem of the devil in the detail. I’ve passed my proof of concept, implemented most of the system before reaching the seemingly trivial feature Z and ended up mangling the framework to support it. It’s not a fun way to work.

What about how well does it perform? Performance is often an important in some industries and using a slow framework is not going to help anyone. Sometimes you can’t throw hardware at it. What are its memory requirements? You’d be surprised to see some of the more interesting memory usage patterns I’ve both written and had the misfortune to utilise. How does it scale? Does it use polling for the network communications layer that is fast until you have a hundred connections?

These are questions that need to be asked before you use a framework. There are more questions, but this isn’t a post on how to select a framework.

There is an old adage that also gets bandied about in the software development world. Don’t reinvent the wheel. I’m not saying that it doesn’t apply, but what I am finding is that it is being used erroneously. When I talk to my peers about a need for function X or function Y I get the typical, ‘who has done this already?’ if so, leverage their work, otherwise you are just reinventing the wheel.

I suggest a new proverb that is a better fit for software development. Don’t redefine the wheel. As a concept the wheel has not changed since its invention However, how we have implemented the wheel over the past several thousand years has changed significantly.

When it comes to frameworks, do the same thing. The important thing is that your framework matches your concept whilst being implemented the way you need it to be. Developers shouldn’t be discouraged from creating a framework is functionally the same as another framework if it meets specific non-functional requirements. Nobody tries to fit a wagon wheel onto a Formula 1 car because it meets the functional requirements.

This is all anecdotal and you may be thinking that this is nothing more than the unfortunate experiences of one individual. Proverbs are anecdotes too; it’s just that enough people have experienced the issue for someone to articulate it in a pithy way.

Note: When I said articulate I never mentioned concisely. If you’re reading this then you know I have a slight inclination for long winded ‘points’.

2nd Note: It is worth noting that forking an open-source project to meet specific non-functional requirements may be faster and more efficient from a development perspective than starting from scratch.

3rd Note: Don’t flame me for suggesting forking an open-source project. I don’t care.

My Mug Ryan Boucher is a Software Inquisitor and is passionate about it. You can find a whole raft of articles and anecdotes about software testing and other topics he gets excited about.
Tags