The Objective Blog

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

The Radar: October 19, 2017

October 19th, 2017 - by Isabel - Salt Lake City, Utah

Video Trimmer

Free online video trimmer.

Full article

Simplify the Complex

This article teaches you how to simplify complex ideas using cartoons.

Full article

New Firestore Database

Google launched a new database service for Firebase.

Full article

Improve Your Ruby Ways

Learn some functions that can help simplify your Ruby code.

Full article

Event-Driven Architectures

A great overview of 3 types of event-driven architectures along with their pros and cons.

Full article

Software Security

This brief guide provides an overview of software security.

Full article

 

The Radar: October 11, 2017

October 11th, 2017 - by Isabel - Salt Lake City, Utah

Cat Swinging Using CSS

It’s amazing what you can do with CSS nowadays!

Full article

Emotional Intelligence

Learn why emotional intelligence is such a critical skill in business.

Full article

Reducing Global Mutable State

Tips on reducing the amount of global mutable state to improve the quality of your code.

Full article

Better Typography

Basics for better typography in just five minutes!

Full article

Facebook Access Tokens

Learn how to handle access tokens with Facebook SDK v4.0.

Full article

Bug-Free Code

An insightful article about the perils of buggy code and attempts to write and create bug-free code.

Full article

 

The Radar: October 4, 2017

October 4th, 2017 - by Isabel - Salt Lake City, Utah

Redefine Stakeholders

While internal input is important when getting a product ready to launch, designing for internal consensus could lead to the creation of bad products. Read how one author redefines stakeholders and their contribution to design.

Full article

Website Experiments

Website experiments help drive decisions using data. Read seven rules for running your experiments.

Full article

Design-to-Code Platform

Introducing an easier and faster way to take applications from design to code. Currently, Android and iOS are supported and support for React Native is coming soon!

Full article

Stranger Things Gets Legal

A creative cease-and-desist letter that demonstrates company creativity at all levels.

Full article

Experiential Marketing

Marketing is changing and now calls for fast and effective brand experiences that build loyalty with consumers through one-to-one interactions.

Full article

Rethink Heroku

Read one author’s take on why they prefer Heroku over AWS.

Full article

 

The Radar: September 27, 2017

September 27th, 2017 - by Isabel - Salt Lake City, Utah

Tech Tattoo

Introducing DuoSkin, an on-skin interface that allows you to use your skin to control mobile devices, display information, and store information.

Full article

Reduce Power Consumption

Researchers at MIT are working on a new system that uses flash memory for data center caching.

Full article

Recalling Popular Brands

Although we instantly recognize popular brands when we see them, accurately recalling the details of those brands turns out to be a bit more difficult, as this simple study shows.

Full article

New Web Fonts

An interesting article about two new types of fonts for the web; variable and parametric.

Full article

Avoid Performance Issues with GraphQL

This article provides some insight into the potential performance pitfalls that can arise when using GraphQL.

Full article

Open Source Software Awards

InfoWorld highlights the leading open source projects for software development, cloud computing, machine learning, data storage and analytics, and security.

Full article

Software is Never Done

September 22nd, 2017 - by Brett Derricott - Salt Lake City, Utah

For first-time software entrepreneurs, the realities of creating and owning a software product can be a shocking eye opener. The trouble is, most have to learn the hard way. My hope is to give you some insights, gained after 15 years of designing and creating software for hundreds of clients, that will help inform you as to what you’re really getting into when you set out to create a new software application.

Incorrect Expectations

Most people who’ve never created nor maintained software are somewhat unreasonable in their expectations of what it will cost to create software that can achieve product-market fit, and unreasonable in their expectations of what it will cost to maintain that product after launch.

Based on my experience, expectations are often off-base because of the following reasons:

  1. The entrepreneur has never done this before. How could they know any better? If I decided to build a boat, which I’ve never done before, it’s safe to assume the project would take longer and cost more than I naively think it would. The same holds true for a first time software entrepreneur. We don’t know, what we don’t yet know.
  2. They’ve been conditioned to this thinking. There are many other things in business, even within a loosely-related category, that are more “pay $X and then you’re done”, such as a logo, computer, or brochure. Software, unfortunately, is not at all like this.
  3. Historically, software was a bit more of a static product. We bought software on discs and in the pre-Internet dark ages it was rare to get any updates for that product. I think this gives some precedent to the notion that “I’ll build an app and then sell it.” We still buy mobile apps that way, in fact, even though our mobile apps are constantly being updated.

The Dawn of Awareness

One of my favorite conversations with new-ish entrepreneurs is the one we have about a year after they’ve launched their app or SaaS product. By that point in time, the entrepreneur has usually started to realize that they will be working on this app (translation: spending money) continually for as long as they are in business.

They now know first hand that creating and maintaining software isn’t quite as simple as they originally expected. What leads them to this new understanding? It’s first hand experience of the following truths:

  1. All software has bugs. A hallmark of an inexperienced entrepreneur is that they believe in bug-free software. It’s a myth. Certainly, everyone strives toward that mythical goal, but no amount of money or expertise will prevent 100% of bugs. Get used to bugs, learn to prioritize them, and accept that they’ll cost you some money.
  2. Devices, operating systems, and browsers change…and they change often. Each change represents a potential problem for the software product, and some amount of effort must always be dedicated to keeping the software product up to date with the devices with which it must interact.
  3. Technologies become out of date or obsolete. Protocols get updated, libraries and frameworks evolve, APIs change, security patches need applied, and on and on. Your mobile app or web app lives within an ecosystem of other code and as that other code changes yours must change along with it.
  4. Your market changes. Even if you could build your product perfectly, your market and your customers are evolving, and that means your product has to keep pace. Your competitors are improving their products too, so forward movement is essential to stay relevant. You will need to invest heavily in your product for this reason alone.
  5. Your success will drive change. As you succeed in winning customers, their needs and the impact they have on your product will drive you to refactor code, optimize queries, build new administrative and reporting tools, etc. Your own success will demand further investment (which is a good problem to have).
  6. Technical debt must be addressed. Technical debt is an uncomfortable concept for product owners. Technical debt comes from tradeoffs developers have to make in order to meet timelines and stay within budgets. If you demand that your developers incur no technical debt, not only are you being unrealistic but you’ll never launch your product because you’ll forever be chasing the mythical perfect product. Technical debt will always exist, but you must devote some resources to keeping the amount of debt reasonable. Ignoring technical debt is also a good way to alienate your developers, by the way.

Avoiding Some of the Pain

Some of what you need to know is only going to be learned through experience. Some of what I’m telling you may not resonate until you’ve gained some mileage. But I do believe it’s possible to save you from at least some of the pain inherent in learning the hard way about the cost of creating software, and the following tips are offered with that goal in mind:

  1. Welcome the adventure. Have the humility to recognize that your expectations are probably a bit off, and welcome the experience of learning what it really takes to launch and own a software product. Like doing anything new, having an open mind and an eagerness to learn will turn your journey into an adventure rather than a frustration.
  2. Start small and conserve budget for the future. Even though you may feel like you have a perfect vision of what you want your app to do, start as small as possible, and iterate your way to that vision. If you do this, you’ll spend less money making the mistakes you will inevitably make. In other words, learn cheaply.
  3. Spend money on quality. While my previous point said to learn cheaply, the point is more about reducing the scope of your initial versions. Don’t go cheap on the quality. Cutting corners on quality increases your chances of having to start over or do a major rewrite of your software later. At least once a month we talk to a company who hired an inexperienced web developer (or an ad agency) to design and build an app for them, and the project is failing. It’s heartbreaking to have to educate them on why the money they’ve spent was nearly all wasted by an unqualified vendor.
  4. Get validation early and often. Validate your assumptions about the market as much as possible before you invest heavily in a product. Part of that market validation does require designing and building one or two versions of your product, but don’t spend hundreds of thousands of dollars trying to build the perfect product right out of the gates. Get validation first.
  5. Educate yourself about technology. You don’t have to become a developer, but if you’re going to own a software product you need to gain some technical knowledge so that you understand enough to manage those who will write the code. The more knowledge you have, the more effective they’ll be, and the more equipped you’ll be to avoid major issues.
  6. Find trusted advisors and vendors. The lowest cost vendor (or developer if you’re hiring internally) is rarely going to get you the quality you need. Avoid the siren song of anyone who tells you it can be done for significantly cheaper than what the other qualified sources are saying. Chances are they cheap vendor won’t deliver what you really need, and the technical choices they make will cause you major headaches and expense down the road. The best development firms are always going to give you a healthy dose of honesty and reality, which is often at odds with what you want to hear. If you’re tempted to ignore their candid advice, read #3 above, and then read it ten more times. You don’t want to be the firm calling us to find out if we can fix the mess you’re in. A reputable firm will also help guide you in terms of how you spend your budget so that you can balance quality with affordability.