Deciding Which Technology to Use

When developing a new product, it can be difficult to determine which technology to use. When working on Pylons, I ran into this problem. I had an idea of what I wanted, but wasn’t sure of the tools to use to get there. It’s a bit like envisioning a masterful statue, but not knowing which chisels to use, or when to use them.

When it comes down to it, there’s probably a few questions you should ask yourself before getting too far into things when developing a technology related product:

  • Will the technology I choose allow me to create the product I envision?
  • Will it give a good user experience?
  • Will it scale up to the number of users that I’d like?
  • Will it be safe and secure? What are the risks associated with this particular technology with regards to data breaches, hacking, or general security?
  • Will it be supported for a long time, or will it be deprecated/outdated in a short period of time? (A related question: Does the company that produces the technology use it? Do they eat their own dog food?)
  • What will it be like for maintenance?
  • Am I already familiar enough with the technology, or will there be a substantial learning curve? If so, will the time it takes to learn it be worth it?

I’m sure there are things missing in this list, but at least it gets a person thinking.

When I first started prototyping Pylons, I was coming from a background of doing business software in .Net, although I was also learning Python at the time. To me, it made the most sense to choose .Net for the back-end. I had some experience with WCF, but after looking into using it to create a RESTful http service, and hearing the experiences of a fellow student, the MVC Web API looked like a better choice.

I also hadn’t worked with any mapping services, and I didn’t want to get too tied to a specific mapping provider. I came across a product called Mapstraction, that would allow me to quickly switch providers if I felt the need. Unfortunately there wasn’t a ton of documentation around it, so it did take me a little longer to get things implemented.

For the front end, I quickly discovered that just a bare web page wasn’t going to work well on a mobile device. From hearing about the experiences of the big guys (Facebook, etc.), they all seemed to be going away from HTML5 to native apps. Again, given that I had .Net experience, I went ahead and created a .Net Windows Phone app.

Unfortunately for Pylons, the whole team has been pretty busy with other endeavors, so we haven’t had the time to sink into it that we’d all like. Given our limited time and experience, I’m not sure we’ve actually chosen the right route. In the end, we might be better off with a tool like Xamarin that would allow us to hit all the platforms at once with minimal code change. It will still let us get decent performance without having three different learning curves – one for each platform. Another option we need to investigate is using something like Leaflet, that is able to handle mobile maps better than Mapstraction.

So I guess there is one more thing to consider:

Once you’ve chosen a given technology, don’t forget to keep learning about new technology.

In this business you can’t afford to rest on your laurels too long. Yes, getting things done is important, but so is having an idea of what is coming down the pipe.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s