All Posts By

Gary Newcomb

How Building an Application is like Building a House

By | Articles | No Comments

When people plan to build a house, they may contract an architect to design it. He’s expensive, but he’ll make sure you get exactly what you want, is up to code, and will probably even suggest things you will also want to potentially add that you didn’t even think about. You’re not stupid…he’s just good at it and it is what he does… and he’s done it a lot.

When it’s time to actually build the house, you don’t generally give that guy a hammer. He’s probably done it. And he’s possibly efficient and meticulous. But a carpenter can do the job, and he can probably do it for a whole lot less per hour. Of course, your carpenter probably isn’t also a licensed electrician… or plumber. You’re going to have to contract several people/firms. And you’re going to want to make sure they are good at what they do. Not pretty good at doing everything.

When you plan to build an application, you want to have it thought out by a guy that has built things before. And someone who is good at it. A Software Architect that can take your ideas and requirements, and design a solution that gives you exactly what you want, is up to code, and will probably even suggest things you will also need potentially to add that you didn’t even think about.

When it’s time to actually build that application, you don’t generally give that guy a keyboard. … you’re getting the point. Hire a Software Developer. More specifically, hire a Software Developer who is exceptionally good at the specific things that the design requires.

When I first started working (some 20+ odd years ago), I fancied myself as a Company Man. Think old-school IBM… back in the day when you gave a company your life, and they took care of you for life. Unfortunately, I was born about a decade too late for that to be a useful career plan. The industry gained momentum. So many technologies, languages, platforms. Just as the medical field advanced from the days when a generalist could do everything, now we require specialists. And it is impossible for anybody to be a specialist at everything.

So, why do some developers feel underpaid? Because for the most part, the current industry will hire full-time generalists. And a general developer doesn’t always provide a service that requires a specialist level of pay. Companies hire the software equivalent of a handy-man, because they may not always understand what they are going to need, and when they might need it. In fact, some of the today’s larger companies actually do employ a cavalcade of specialists but treat them as a group of generalists due to a lack of specialized skill tracking over time.

So, if you pay your Architect a Carpenter’s wages over the course of a year, then he’s going to feel underpaid. Alternately, if you need an Architect for a couple months, but you hire him full-time for an entire year (worried you might need him), then he’s going to feel overpaid for the carpentry work. He probably won’t complain about the money… but he knows you and he is both not getting the full potential.

Unless you’re a company of plentiful ideas and solid R&D budget, don’t hire a full-time Software Architect. You should contract a Software Architect. Let him work with you to design (or re-design or performance analysis/improve) your applications. Then hire or contract (or search your current developer base) the right team of specialists/generalists to build and maintain from a solid foundation.

That provides a value proposition that is appealing to both sides of the coin.

Mobile Dev Stack: Cross-platform toolset or not?

By | Articles | No Comments

As you start to build a new mobile app (or maybe you have a mobile app that needs major renovations) — the first technical choice is: Do you leverage one of the many cross-platform tool-set available or go directly to the iOS and Android SDKs?

There are absolutely situations where the cross-platform tool-set approach is preferable to writing and maintaining purely native applications on multiple platforms. But before you hook your horse up to that attractive looking wagon, let’s discuss a few important considerations that might save your project, and your bottom line.

Cross-platform mobile development has come a long way in the last couple of years. Lessons learned have pushed the development of these frameworks to address the more painful points (performance, access to native APIs, test-ability…), moving further from the old Hybrid approach that leverages WebView components toward a much more native experience.

That being said, here are 5 Things to Consider Before Leveraging Cross-platform Mobile Development Frameworks

1. It Ain’t All Technical.

Oh, I’d love if it were. But let’s not pretend that it is. If it were, then the considerations would be much easier.

You only get one chance to make a first impression. And if your application is not responsive and intuitive, then your retention rate will suffer. Of course, if it takes you 2 years to get your MVP into the customers hands, they may already have something else to hold.

I will say this unequivocally: An application written entirely using the native platform SDK directly will result in an application that is functionally equal or better than one written using any proxy framework.  I will not qualify this statement here except to put the burden of proof on the counter-point: How can a tool-chain that relies on generated native code (as well as a bridge to access said code) ever perform better than something written directly to the native platform? It cannot, and thus the choice isn’t about technical superiority, it is about time and money.

The reality of the situation is that there are a lot of tough decisions when you intend to spend good money creating something that you expect to leverage to make better money. Somewhere the Wallet behind the work is going to want some input on how much it’s going to cost, and how quickly bills are going to start filing back in instead of falling out. This is probably the greatest driver behind making the tough choices. I support the Wallet, and I don’t envy his job. What I will tell him, and I am telling you now, is please sit at the whiteboard with me and discuss the risk versus reward of the next 4 points we’re going to discuss. If you can’t say them out loud, then maybe you don’t yet understand the risks. And if you don’t understand risks, then you don’t really understand the final costs.

2. Hold My Beer, I Got This.

I get it… People are comfortable with what they know. And they honestly believe that if they are proficient enough with a certain tool, then they can carry that tool out into the world and do magical things … that the tool was not originally designed to do. Let’s say you already have a full-time software developer, and he’d like to keep his job, thankyouverymuch. He’s already proficient in a programming language (say… JavaScript), and most bankable developers these days are proficient in two or three, then you probably feel you can tackle this mobile problem without hiring and training new talent.

Your JavaScript web developer is going to be tempted to point out that React Native, developed and maintained by Facebook as an open-source framework solution, can be used to create “native” mobile applications using only JavaScript.

Let me slow your roll right there.

The languages for mobile development are Objective-C/Swift for iOS, and Java/Kotlin for Android. If you do not have a developer with these proficiencies, then you may not be able to objectively make the right decision. I’m not saying your RockStar developer isn’t capable of “stackoverflowing” his way into a demo-able version in the vein of your MVP. But are you both sure he can actually produce that MVP on his first attempt into this new realm? Can you afford this new expedition? This leads to my next point…

3. Down the Rabbit Hole.

Shortcuts can be dangerous. One time, pre-Google, my wife and I were trying to get to a party. The major roads were busy, so we decided to cut through a neighborhood we’d never been in before. We knew the destination was just on the other side. We certainly spent the time moving in the right direction, and we saw some really nice houses and landscaping that we decided we might incorporate ourselves. However, what we learned after spending that time is that even though we got close to where we wanted to get… we couldn’t quite get there. We had to go back to the front of the neighborhood, and get back onto a path we knew would succeed.

Your lead developer is your navigator. If he’s not familiar with developing mobile applications, then bear in mind that choosing the cross-platform shortcut may take you down a path that will not lead easily (if at all) to your MVP.

4. Keeping Up With the Jones’.

Apple and Google have done a fine job of making sure that iOS and Android stay current to meet the ever changing needs of the consumer and push the capabilities of our evolving mobile devices. XCode9 with Swift4 is coming out this fall. Kotlin is just starting to get its hooks into Android, as Java 1.8 support is leaking into Android Studio (Canary). Think about this… there is no other platform on which the underlying hardware technology evolves, the operating systems evolve, and the very development languages evolve on a semi-annual frequency that is adopted by the general population. Quite literally, if it takes you 6 months to author both iOS 1 and Android 2 applications, your development lifecycle will experience at least one major-revision language migration on one or both platforms. And note the key words in that last sentence: “major-revision”. They aren’t tweaking the languages, they are transforming them. Not to mention the myriad of hardware accessible changes (Bluetooth Low Energy, Graphics, Camera,…) and additions (Watches, VR devices,…). Keeping your application, unit tests, and build environment up-to-date with all these changes will be a full-time job. Whatever methodology you choose to bank your code base on will need to move just as fast. This sets up my last point…

5. Who’s Steering this Boat?

Whenever you choose to put a proxy between your code and it’s target platform, you are choosing to give up some level of control. This is the risk/reward point that you will eventually have to make. What you are deciding is to take the risk to speed your MVP to market at the expense of some level of control. For simple, minimal applications that don’t interface too heavily with external components and don’t have very complex background tasks, this is very advantageous. For applications that are more complex, there will be a need for some level of Native coding in addition to the cross-platform work. And this means learning not only the native languages but also the framework environment that sits between you and your platform. And if your choice of cross-platform tool-set can’t keep up with the shifting landscape from point 4 above (or worse, fails to maintain support at any level), then you’ll learn the hard way that the risk you thought you were taking just tore off your rudder and threw out your oars.

And remember, not only are these frameworks supporting changes to the Native APIs, but they are also trying to keep up with changes to the other underlying technologies on which they are built. Take for example Ionic, who recently released Version 3.0 that was migrated to Angular 4. Since the initial release, there were 13 updates address numerous bug fixes — in just 4 months.

Need a Little Bit More…

Don’t let me scare you away from the cross-platform tool-set. But the risk rewards truly need to be quantified through analysis. Consider that Facebook leverages a cross-platform framework for part of their mobile offerings. But Facebook isn’t likely to let that framework (React Native) steer their application. Facebook will steer React Native. After famously transitioning from using an HTML5 approach to a native application offering (2012), Facebook authored their own cross-platform framework. Not many companies can mitigate the dependency risk that way.

If you’re still early in the life-cycle of your mobile development and don’t have your own Native mobile application team, let us help you understand your risk/rewards.

Orange Robot is customer software development firm that designs and builds native mobile applications and back-end server solutions.

Looking to build or refresh a mobile app? Let's talk