The Objective Blog

Keep up with what we're thinking, reading, and doing.

Startup Guide: Are you choosing the right tech stack?

August 1st, 2017 - by Dan Rasband - Salt Lake City, Utah

You’ve got a potential client that wants to build The Next Big Thing™. Or maybe it’s your Big Idea and you’re hiring the development firm down the street to build it. Maybe you’ve researched every tech stack out there, and you think you know exactly how your new project needs to be built. But what if you’re wrong? Will your technology choices determine the fate of the project? How do you know, before you’re deep into development, whether you’ve made the right choice?

At Objective, we have experience with a genuinely wide variety of different stacks and, as they say, experience is the best teacher. If you’ve ever wondered whether you are making the right choice when choosing the tech stack for a new project, this article is for you. I’ll explain why it’s crucial to make the right choice, and I’ll show you our method for choosing a stack. By reading this article, you will improve your ability to make an appropriate choice in tech stack from day one of any project.

The Problem

Here’s the problem with things these days: there are a million and one options to choose from, new and old, and many of them seem roughly equal:

  1. The “Tried and True”: Some tools are older and proven, but people you work with may think those tools are “legacy” and outdated.
  2. The “Hot and New”: Other options are new and at the peak of the hype cycle, and they seem awesome, but no one really knows where they’ll be in a few months, let alone a year or two down the road.

Let’s take JavaScript, for example. It’s pretty much ubiquitous. You can’t get away with building a website without it, and it’s now being used for API servers, desktop applications, mobile applications, and more. But there are so many precompilers, transpilers, polyfills, and versions for JavaScript that there’s no way anyone can learn all of them. Some of the tools are temporary—just filling in for language features that will be implemented in all major browsers within a few months. All of this is new to the JavaScript landscape. This movement is definitely for the best, but there are times where using the tried-and-true jQuery is a better option.

Not only do you have options in terms of languages and frameworks, you now have myriad options in terms of application architecture. Will you build a monolith that handles everything from database queries to view generation, or will you listen to the software architecture hype and build out 15 microservices? Will you build your web application using the single page application paradigm, or only use “JavaScript sprinkles” where needed? Depending on the size of your application and its features, one choice may mean failure to launch while the other means long-term success.

While having a plethora of options placed before you may seem daunting, what could be worse is the pressure you feel from developers or management. Management, for example, may push for the tried-and-true C# ASP.NET stack, but your developers want to use Elixir because they are excited about its process-oriented paradigm, and both groups have financial arguments in favor of their choice.

As you can see, and have probably experienced, choosing a tech stack is no easy task. But it’s not just a difficult task because there are multitudinous options, it’s also difficult because the choice of a stack can have long-lasting consequences.

The Cost of Choosing the Wrong Stack

Choosing the wrong tech stack can be costly, in terms of short- and long-term financial cost, opportunity cost, and developer morale. For example, when choosing an unfamiliar (and possibly over-hyped) stack, you may be in for some of the following troubles:

  • A new stack will require additional ramp-up time to learn the ins and outs of things.
  • Some new tech stacks (e.g. React Native) have overly-frequent update cycles that break existing code and require frequent changes to keep up.
  • You may have trouble finding experienced developers when you need them.
  • The tech stack may be built in an unsustainable way, and lose funding and support. For example, the company behind RethinkDB shut down, saying they were “ultimately unable to build a sustainable business.”
  • You don’t know what you don’t know. The hype may indicate that a new stack will solve all of your problems, and maybe it will, but what new ones will you have to deal with? Inevitably there will be some.

When choosing a “tried-and-true” stack, you may think your woes will be few, but you’re just as likely to run into some of the following issues:

  • Code written in some older languages is hard to reason about and costs more money to write and maintain. Think C vs. Rust.
  • Waning interest in the languages and or frameworks may mean that it is difficult to find well-supported libraries and modules.
  • Lower popularity of the stack may mean difficulty in finding developers that are willing to work on the code for a reasonable price (think Cobol in the banking industry).
  • Lower levels of maintenance on the framework/language may mean subtle security issues or bugs persist longer before being fixed.

It may seem like no matter what you do, you’re bound to fail. But there’s hope.

The Benefits of Choosing the Right Stack

Choosing the right stack for your next project can be beneficial to your business in many ways. In fact, where choosing the wrong stack can ruin your project, choosing the right one may mean the success of your project in the short- and long-term. Take a look at the following benefits you may experience when you’ve chosen the right stack:

  • The base performance of your application will be solid.
  • Your developer morale will be high, which means better code, faster, and you’ll be better able to retain your developers.
  • Your application’s codebase will be easy to maintain and, while all software incurs maintenance costs, technical debt will be relatively low, and maintenance updates fairly painless.
  • The stack will be well-documented and it will be easy to find ways to solve common problems.

The right stack doesn’t necessarily mean the newest and hottest stack. A tried-and-true stack with a lot of community support can be just as good or better than the newly-trending, corporate-backed stack of the day.

The Solution

Now that you know the possible dangers of choosing the wrong stack and benefits of choosing the right stack, let me show you how you can make an appropriate decision each and every time. Don’t be mistaken; even if you’ve made the perfect choice in tech stack, there may be bumps along the way, but by following these guidelines, you’ll be able to select a tech stack that enables your project to succeed.

1. Feature Requirements

First and foremost, it’s important to know and thoroughly understand the requirements of your project. Do you need pseudo-realtime functionality, such as with a chat application? You’ll want to use a tech stack that is good at concurrency, such as Elixir/Phoenix, Node, or Go. Or do you just need a simple blogging platform (WordPress) or a robust content management system (Drupal)? Is your client-side UI full of complex interactions? Then React or Elm may be good front-end stacks. Knowing your planned feature set can at least narrow the set of suitable options.

2. Short-Term Goals

Second, it’s important to understand the short-term goals of your project. In an ideal world, all projects would be built perfectly from the beginning so that they could withstand the sands of time, but often the project’s short-term goals demand sacrifices on long-term ideals. For example, you may be interested in vetting an idea, or perhaps your idea is already vetted and you’re ready to build a highly-scalable, robust version of the application. Or maybe time to market is critical for one project, but less important for another. When you’re building on a short timeline or want to limit costs as much as possible, it’s okay to sacrifice on scalability, robustness, or even developer happiness, as long as you recognize the technical debt that this incurs. You may want to limit using this kind of low-cost approach to a codebase that you are 100% willing to throw away once the idea is validated.

3. Developer Happiness and Availability

Another thing you’ll want to look at is whether or not there are developers that are willing and able to work within your chosen tech stack. If you choose the preferred tech stack of 1970, you’ll be hard-pressed to find many people who know how to use it, and if they do, they’ll charge a premium. So choose a stack that has a vibrant community of developers. That way if you decide to onboard new developers to work on your app, you’ll have a decent pool to choose from. It’s also somewhat important to choose a stack that developers are excited about, or at least are happy to work in. You may be able to find a handful of people in the US who are happy to work with Perl, but the majority of developers nowadays would run away from it. It’s a lot more exciting for many developers to see job postings that allow them to work on at least one thing that’s up-and-coming, even if the rest is pretty run-of-the-mill.

4. Risk Aversion vs. Need for Special Features

The last thing you’ll want to consider is your own (or your business’s) aversion to risk versus the project’s need for special features or functionality. If your company could lose millions of dollars because of a missed transaction, or your application could cause human suffering or death, it goes without saying that you should choose the tried-and-true. If, however, your company is able to absorb a few setbacks and needs the cutting edge technology of the day, it may be appropriate to use a newer (even hyped) stack that allows you to get the features you need at a lower cost of development. It may also be possible to compromise and get a good mix of tried-and-true with newer functionality by choosing something like Elixir, which is built on the Erlang VM (BEAM). You get the benefit of a well-tested VM and the perks of a well-designed, new language.

Methodology and Examples

It may help to go through a couple of examples to get a better idea of how you might think about the aspects described above in relation to an actual project and actual tech stacks.

The following is an example of how we might go about choosing a stack for a potential client:

First, we compile information about the project’s and client’s needs.

Needs:

  • Be able to manage a large amount of content
  • Content must be available in multiple languages
  • Must be able to expose an API for special content
  • Content comes in a variety of formats (video, imagery, text content) and needs to be displayed in a variety of ways
  • Must last 5+ years
  • Must support up to 1 request per second

Next, come up with a list of viable technologies. This list will be different, depending on what’s available at the time (new technologies become available every day!) and where your developers’ expertise lies.

Viable technologies:

  • Drupal
  • WordPress

I’ve excluded a variety of other tech stacks for this exercise because at Objective we view these two frameworks as the most viable for this kind of project. At a .NET shop, Umbraco could be a framework worth adding. While we do a lot of Rails, locomotive has various issues that make it inappropriate.

Rate the tech against the needs, and against risk and developer metrics:

Lots of Content I18N API Content Types Developer Happiness Developer Availability Total
Drupal 10 9 7 10 6 5 47/60
WordPress 10 3 3 5 5 10 36/60

 

It is clear that, at least out of the two technologies above, and based on these scores, Drupal is the winner. It’s most likely the tool we would choose for a project of the given requirements, and we have chosen it many times in the past, even though it’s not our favorite tool. You could also add more pieces to the rating chart, such as maintainability and scalability, but they are deemed less important for this size of project.

Note that this kind of grading pattern will always be arbitrary. There isn’t a tech stack scores cheat sheet (that I know of), but you or your developers will need to attempt to be as objective as possible when coming up with scores for each column. A little bit of bias can act in your favor in this case. I tend to grade Drupal higher, for example, because I know it better than WordPress, and the fact that I know it better means I’ll be better and faster at developing web sites with it. If WordPress comes out on top, bias withstanding, then I’ll know it really is the way to go.

Here’s another example, this time focused on choosing a software architecture paradigm:

Needs and Client Parameters:

  • Realtime updates of content across devices and users
  • Social Media login and integrations
  • Complex UI with a lot of interactions for web and mobile
  • Validated concept with potentially thousands of users per hour

Viable Architecture Patterns:

  • Monolithic back-end, Single Page App front-end
  • Monolithic back-end, JavaScript sprinkles on front-end
  • Microservices back-end, Single Page App front-end

Ratings

Handles Complex Application Features Handles Complex UI Scalability Maintainability Simplicity of Code/Design Total
Monolith + SPA 10 10 8 8 8 44/50
Monolith + jQuery 10 5 8 5 9 38/50
Microservices + SPA 10 10 10 8 5 43/50

 

It’s a close call between the monolith and microservices architectures on this one, but it’s at least obvious that the single page app paradigm is the way to go. You’d probably have to dig a bit deeper at this point to determine if a monolith would really be better than a host of microservices. The simpler the application is, the more I would lean toward a monolith. While microservices are hyped a lot nowadays and there are strong arguments in favor of using the paradigm, they add a lot of complexity to the architecture of an application.

Things to Watch Out For

When you’re deciding on a technology for your future project, there are a few things you should watch out for:

  • Don’t believe overly hyperbolic articles about certain technologies dying off, at least at first. Ruby on Rails, for example, may be waning in popularity, but it could still be the best choice for the job, assuming your developers have expertise with it and your project doesn’t need high performance out of the gate.
  • Don’t believe all the hype about new technologies. New technologies are great. They push the industry forward and bring efficiencies to development. But they are often immature and can cost your project significantly. They may solve one problem, but create 10 others, and its hard to know if all your needs can be met in the early days of a new tech stack. Etsy, for example, jumped on the MongoDB bandwagon, only to regret it later.
  • Don’t ignore developers’ opinions, but do your research, too. Developers often want to experiment with newer technologies, or are just sick of what they’ve been using for the last 5 years. It’s important to listen to your developers, but do your research and make sure the technology they want to use is appropriate for your project.
  • Don’t follow best practices blindly. It’s good to follow best practices, but when doing so could mean incurring a lot of extra development time or cost, question whether it’s necessary. For example, using AWS’s Multi-AZ RDS deployment is definitely best practice, but it’s probably not necessary when you have 2 users. Use the cheaper, easier path until you have a validated need to step things up. That said, don’t make it too difficult to upgrade if you think you’ll have the need to do so soon. If you know you’re going to have to support 5000 concurrent users in two months from now, don’t build your application in a way that won’t scale.
  • Avoid WordPress unless you’re building a blog. WordPress is an awesome tool that supports millions of websites. You can do a ton with it, including eCommerce, blogging, and content management. But if you want to build a web application that has more than just content management, or your content management needs are fairly complex, then steer clear. It will save you money (and many headaches) in the long run to use a more robust tool.
  • Use React Native for mobile applications. In our experience, React Native is the most economically sound, robust tool to use on mobile projects 99% of the time. Most mobile applications aren’t complex enough to warrant a pure native codebase, and with React Native you get the added benefit of being able to write code one time for two platforms (iOS and Android). It’s also proven much better in terms of maintainability and performance when comparing it to PhoneGap or Ionic. It’s pretty much a no-brainer for us now.
  • Don’t be an early adopter. When it comes to projects that are more than just prototypes, it’s best to use a technology that has been around the block a few times. There are definitely cases where a new technology is good enough that it makes sense to use it despite its immaturity, but in most cases, you’ll pay for the privilege of being an early adopter.

Conclusion

To recap, to help you choose an appropriate tech stack, measure your options against the following:

  1. Feature requirements and project assumptions
  2. Short-term goals (e.g. time to market, prototype, robustness)
  3. Developer happiness and availability
  4. Risk aversion vs. special features

When choosing between the “tried-and-true” or the “hot-and-new” on your next project, being methodical about your tech stack choice will not only save you time and money, it may save your business.

If you have questions or comments, please contact Dan at dan [at] objectiveinc [dot] com.

HTTP/2 Will Improve Your Site

February 2nd, 2017 - by Brett Derricott - Salt Lake City, Utah

When was the last time you said, “Technology is always staying the same”? You’ve never said that. No one has. We’re all continually amazed at how fast technology changes. The changing is the thing we find so remarkable.

Well, in some lesser-known cases technology has changed much more slowly than you’d expect. One of those is the Hypertext Transfer Protocol (HTTP), which is the primary protocol driving the communication between your web browser and every web server (site) you visit. The last update to HTTP was version 1.1 in 1999. Crazy, right? Fortunately HTTP/2 is here to bust that slump.

Plenty of articles have already been written that explain the gory technical details of HTTP/2 so for this article I’m only going to summarize the key points for you as a site owner.

Why Switch to HTTP/2?

  • Speed: Websites and browsers that support HTTP/2 can share more information in less time.
  • SEO: Google considers your website’s loading time as a factor in your rankings. Faster sites get higher rankings.
  • Development: If you’ve spent time/money optimizing your website, you know that there are extra steps required to make your site speedy in the HTTP1.1 world (sprites, combining files, domain sharding, etc). In HTTP/2 most of those become unnecessary, and in some cases, they actually become detrimental.

How Do I Switch to HTTP/2?

Most likely, you should hire a developer to do this for you, but in case you’re feeling especially brave I’ll still outline the major steps here. This will also give you an idea of what a developer will need to do for you.

  • Require SSL: If you aren’t already requiring SSL on your website, you should do that ASAP. Google is starting to use that as a ranking factor, and it’s more secure for your visitors. HTTP/2 requires an SSL connection. You can easily tell if your site is up to snuff here by attempting to load your website using http:// at the beginning of your web address. If your website loads and the http:// hasn’t been replaced with https:// you have a problem.
  • Check Audience Compatibility: As much as 75% of your site traffic is already using an HTTP/2 -compatible browser. If your traffic is all US-based it’s probably a much higher percentage. Depending on your business and your audience you may need to consider optimizing for both old and new browsers for a period of time.
  • Undo Your HTTP.1.1 Optimizations: In most cases you’ll want to undo many of the optimizations your website is using in the HTTP1.1 world. HTTP/2 uses one connection, can multiplex, and has a few other performance enhancements that make things like image sprites domain sharding, and combining CSS/JS files not only unnecessary but undesirable. Basically, we’re going back to the way we used to handle website assets before we started worrying so much about HTTP requests.

If you get nothing else from this article, here are your two takeaways: First, require SSL on your website. Second, put HTTP/2 on your to-do list for improving your website. If you need help don’t hesitate to contact us.

Building Without an Architect

September 23rd, 2014 - by Objective - Salt Lake City, Utah

You wouldn’t build a home without first hiring an architect. If you wouldn’t build a home without an architect, you’re doubly unlikely to build a commercial office tower without one. In addition to being illegal (you’d never get a permit), it’s also too risky.

In a previous post I wrote about the similarities between building a home and building a website. The analogy isn’t perfect, but it works well enough to illustrate a few points, one of which is that the architect’s role is pretty critical. The architect role in the physical world may be better established and understood, but there is no less need for an architect when creating digital products like websites, apps, and software.

The architect’s job in the digital world, much like in the physical world, is to translate the desires of the client into a detailed plan for the builders. This translation step is critical in determining the outcome of the project. The best developers in the world will fail on a project where this step is skipped or done poorly. At Agency Fusion our ability to truly understand what a client wants and needs and then translate that understanding into specifications for designers and developers is what determines our success on each client project.

If the architect role is so critical, why is it so often unfilled on digital projects? First, there’s not yet any established standard the way there is in construction. People already know they need an architect to create blueprints for their new home, but the web is still new enough that this understanding isn’t widespread. Second, when it comes to digital products, you can’t really see the foundation, framing, etc. so it’s harder for people to understand that the digital equivalents exist and that they need to be properly planned from the beginning.

When the architect role isn’t explicitly filled, what happens? The project may still get finished and appear to be a success, but with time problems may begin to appear. A poorly constructed home may look fine but over time cracks will appear in walls, the roof will leak, etc. Likewise, a poorly constructed app or site will show its true colors as updates become painful, maintenance becomes expensive, and performance degrades.

A little bit of advanced planning by an architect can ensure that a digital product is set on the correct course from day one. Updates and maintenance will be easier and more affordable, and the chance of rework will be greatly lessened.

New HTML5 Blog

July 2nd, 2010 - by Objective - Salt Lake City, Utah

Our clients are asking a lot of questions about HTML5 so we decided to put together a simple blog where we can centralize information related to HTML5.

If Steve Jobs has you all hyped-up on HTML5 and you decide you ought to know exactly what it is, check out our HTML5 blog: What is HTML5? Be sure to click the RSS link in the footer to subscribe if you want to be notified of updates.

What is HTML5

Internet Explorer 6: Time to Go

March 30th, 2009 - by Brett Derricott - Salt Lake City, Utah

Developing websites to look right in all browsers can be a pain. Many people aren’t aware that browser manufacturers often deviate from established web standards, which means developers have to do extra work to make a site look the same in all browsers.

Microsoft’s IE 6 is the worst browser, hands down, in our current list of browsers we code for. Ask any experienced web developer if they’re tired of hacking code to work in IE 6 and they’ll passionately agree.

The folks at .net magazine have created a website devoted solely to spreading the word that it’s time for IE 6 to die. Thanks, Laura, for the link!

Until IE 6 really is dead, have some compassion on the web developers you work with and either don’t force them to support IE 6 or at least acknowledge that you’re asking them to do a lot of extra work. If you’re starting a new design and you know you want/need to support IE 6, talk to your developers first and ask them what you can do to make the design more IE 6-friendly.