A lot of developers have a love for technology (although we’ve also met plenty who don’t). The latest phones, the coolest PC tech, the cars of the future - they probably have a passing interest in a lot of it, and where the industry they’re a part of is going next.

This can lead to an unfortunate tendency, which is to assume that everything that comes next is better than what we’ve had before. For something like a processor, where the previous fastest chip ran at X, and the newest one runs at X+1, this is easy to measure and appreciate the improvement.

But in a development environment, it’s rarely that straightforward. But if you assume newest is best, that won’t stop you jumping on whatever the hottest new framework is. Or immediately upgrading to the latest release of a tool you’ve been using. Or moving to a database that Facebook claims has revolutionised their development process.

Underwhelmed

The problem with the latest development tech is that it’s often underwhelming, under-baked, and underprepared for the real world that most of us live in. Partly that’s because a lot of tools are developed to resolve a specific problem the author experienced, and release to a wider public is a secondary concern. It was created to resolve a particular developer itch, not to solve all your problems.

Once you make a technology choice, like a library or framework you’re going to build your application on top of or around, it has to be considered a long-term commitment. Your development team are going to learn it, they’re going to make it fit into their world, they’re going to potentially communicate with its authors. Discovering that investment has gone to waste because it wasn’t what you hoped, doesn’t work properly or worst of all - has been abandoned - can be devastating to your momentum.

Cutting edge technology just hasn’t had a proper shakedown yet by a broad range of developers. Meaning you’re far more likely to be guinea pigs than trailblazers.

Picking tips

Some tips for evaluating libraries and toolkits from Github:

1. When was the last commit?
2. When was the last release?
3. How many issues are sitting open? Are issues being answered?
4. How many “stars” and “forks” does it have? The higher the better.
5. When was the first commit? Projects that have been going for longer, tend to stick around due to their own momentum.
6. What license is it under? With the correct license, you might at least be able to keep it going yourself should all other support fail.
7. How good is the documentation?

You’ll notice none of those tips are “is it cool” or “did it come out recently”.

Of course you still have to determine if the item does what you need it to do. If it’s the only choice, then none of those other items matter. It’s also possible that some other metric, like performance or time of implementation may completely sway you towards one choice or another.

But that’s pragmatism in action, and we’re big fans of that at TeamWeb.

What we don’t like is betting our business on the cool thing that the 126th web framework released in the past 18 month does. That’s why we use Python and we use Flask. They may no longer be sexy, but they get the job done.

Photo by David Ballew on Unsplash