Newfangled works with independent agencies to create lead development web platforms for their clients.

Newfangled works with independent agencies to create lead development web platforms for their clients.

New Technology, and Balancing the Fun with the Practical

at 9:08 AM


Following technology trends on the web is a dizzying pastime. New programming languages rise to popularity seemingly every month and the buzzword-laden web frameworks make their introductions and dance on stage for half a verse before bowing out to younger, fresher technologies. When deciding which pieces of new technology to build into your web presence, there are several things that a developer should consider and some simple guidelines to pull in new, fun technology.

Obviously, the first attribute that a technology is measured by is its quality. Simply, is the code behind it good and sturdy? If you lean on it too hard, will it break? If you sense code smell, follow your gut and keep moving.

The next attribute I look for is community. You read about a new technology and it seems to be the silver bullet for your application. (We'll disregard for the sake of the example that there is no silver bullet.) Reading further you find out that the technology is driven by one developer. The online mailing list gets a question once every two days, and the IRC channel is frequented by the lead developer and a fistful of other passersby just checking things out. That is no community; that's a household.


Django Community Sprint, Photo by Nathan Borror


Now, almost every software project gets started with meager few people involved, and maybe this interesting new technology is in this stage of its life, but what if it's not? Maybe the lead developer hits the lottery and moves to the sunny French Riviera, never touching his MacBook Pro again except to order fine wines for his chateau. You now have a software project that has possibly no active developers and the project fades away to the great Internet Archive in the sky. If you had adopted this technology for a website, you are now riding with an effectively dead technology. This is not a good situation to be in when you need to hire someone that knows it to maintain your site, or to fix bugs that may pop up in the software.


The French Riviera, Photo by Serge Melki


With community, a software project has staying power. The more people involved, the higher chance it will be around longer.

Signs of good community:
1) A local user group
2) Corporate backing (not essential, but definitely nice)
3) Lots of blog posts and Twitter messages indicating that people are talking about the tech.
4) Active mailing lists, both for general help list and the developer list.
5) An IRC channel where you can pop in and find numerous people to help you with an issue.

All of these are not necessary to have a good community but the major software projects tend to have these in common.

My personal favorite trait in assessing a new hunk of technology is documentation. Well-written and kept-up documentation is something that makes most developers happy, but unfortunately writing documentation is not enjoyable as a task. If a software project has a fantastic demo, and then I click through to the documentation wiki and find more instances of "coming soon" than code samples, I usually step away.


Photo by Amit Gupta


Lack of documentation and time to implement a technology are usually inversely related. Little documentation results in lots of tinkering and cursing, fumbling in the dark and looking for that magic combination of words to get the spell working. Software is painful enough; building with it without proper guidance is torture. Some developers thrive on the poke-and-prod method of development, but when a client's money (and the developer's sanity) is on the line, a few breadcrumbs goes a long, long way.

Now that some simple guidelines on vetting technology has been laid down, how do you bring the technologies that look fun and promising, but may not be quite ripe, into the workflow? Easy. Start small and leave traces.

Starting small means don't build anything mission-critical on it. You definitely don't want to nab a big client and then decide to to build their website on a funky schema-less graph database you read about on Reddit. I can guarantee you they don't want to be your testing ground. Now, you may grab another client whose needs may line up for the new and edgy technology. Let them know what you are doing and be honest about your experience with the tech. No one enjoys any surprises in budget or functionality further along.

Leaving traces means let your co-workers know what you did. On your dev team's wiki (if you don't have one, you should), document out why you chose the technology that you did and how you used it, with lots of links and code samples. In case you hit your numbers on the weekend PowerBall and retire early, you don't want to leave your comrades high and dry poking through your code when a bug pops up.

The web is a fun place, with lots of smart people doing cool things every day. Playing with new technology is why a lot of web developers do what they do, and bringing this into enterprise doesn't have to be a pipe dream. So, feel free to experiment, but just be responsible.

*All photos licensed under the Creative Commons





Comments

Brian | May 5, 2009 10:41 AM
Great post Nolan. Would you recommend developers like yourself to pick up additional languages in case one falls out of favor?

http://en.wikipedia.org/wiki/List_of_programming_languages

"The aim of this list of programming languages is to include all notable programming languages in existence, both those in current use and historical ones, in alphabetical order."
Nolan | May 5, 2009 10:51 AM
@Brian I absolutely recommend learning as many languages as possible, trying to learn the ins-and-outs of what make one language appropriate for a particular niche over another. Learning multiple languages, especially across the spectrum of paradigms, stretches your brain and almost always will make you a better programmer.

As far as languages falling out favor, there are certainly languages that are easier to find jobs for (eg, Java, PHP, C, C++), but languages that aren't trendy in the least, like COBOL, are still very much in demand and commands *big* bucks, but are nowhere near the Web-world epicenter.

I'd recommend becoming a master at 2-3 languages, and feeling comfortable with half a dozen more, if nothing else but as a mental exercise.
Chris Butler | May 5, 2009 1:53 PM
Nolan,

I really appreciated this quote:
"Leaving traces means let your co-workers know what you did. On your dev team's wiki (if you don't have one, you should), document out why you chose the technology that you did and how you used it, with lots of links and code samples. In case you hit your numbers on the weekend PowerBall and retire early, you don't want to leave your comrades high and dry poking through your code when a bug pops up."
It's true that if the "gets-hit-by-a-bus" scenario (or the "wins-the-lottery") happens, having documentation would be really helpful. But even aside from good planning in the event of catastrophe, I think leaving these kinds of traces is a great way of holding yourself accountable: A publicly processed decision is likely to get worked out well in discussion, and maybe even objection.

Chris
Nolan | May 5, 2009 2:20 PM
@Chris

I agree, and you bring up a good point that I didn't mention.

Definitely when choosing a new technology to bring in, if other people are going to be working on the same codebase as you, it would help to have group consensus, and someone may see a shortcoming that you didn't see. Or, it could be the opposite, and you introduce a new piece of software to the team.

↑ top