The Objective Blog

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

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 to be 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.

The Radar: September 20, 2017

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

Tests Made Easy

An interesting approach to making writing tests easier and more fulfilling.

Full article

Git Merge vs Rebase

Read one developer’s reasons for always using Git merge instead of Git rebase.

Full article

Psychological Safety

Learn how to foster a psychologically safe work environment.

Full article

HTML Templates

Create responsive HTML templates using React components.

Full article

Component Folder Pattern

Keep your React components organized for larger projects using this pattern.

Full article

Stranger Things

Fun marketing campaign for Stranger Things pays tribute to classic films from the past.

Full article

The Radar: September 13, 2017

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

Faster Test Suite

Tired of your test suit taking too long to run? Here are a couple of tips for making it run faster.

Full article

Neural Networks

Deep learning and neural networks explained.

Full article

PostgreSQL vs. MySQL

Read one developer’s reasons for choosing PostgreSQL over MySQL.

Full article

Programming Languages

Programming languages worth learning about.

Full article

Understanding AI

This article offers a synopsis on what AI is and is not.

Full article

Retrospective

Strengthen your team by hosting retrospective meetings to review the process and outcomes of a project.

Full article

The Radar: September 6, 2017

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

Inventory Tracking Drones

MIT researches found a way to use drones to scan radio frequency ID tags used for inventory management. This could save large retail companies billions in revenue.

Full article

Marketing Strategies

Learn how the fastest growing Saas companies approach marketing.

Full article

Rust

Rust strives to be fast, safe, and reasonably easy to program in. Learn more about its strengths.

Full article

Skype’s Real-time Code Editor

Skype has a new feature that allows you to test candidates using a real-time code editor.

Full article

Session Replay

This site allows you to see your customer’s experience by replaying their session on your site.

Full article

Snippet Tool

A tool to create code snippets for your favorite text editor.

Full article