Tag Archives: development

App Strategy

On the subject of doing app planning & strategy, I recently came across this post from Rob Caraway: http://robcaraway.com/blog/index.php/2017/02/12/how-i-overcame-crippling-perfectionism-and-made-200k-on-the-saturated-app-store/

Parts of it really resonated with me. He says:

Our strategy was basically “Let’s brainstorm ideas and ship massive features and hope people want them”.

That has been my naive strategy so far. Acting as my own ideal user.

Then he talks about validating a MVP:

  • using “Traffic, as indicated by Google Trends”
  • a landing page to capture e-mails
  • building a prototype in a week
  • validating the demand for the prototype

This all seems standard or obvious when you look at it. But I can say that in reality, I have various app ideas that I think are worth making. When it comes to pick the next one, my current process might as well be rolling dice with bad odds. It’s 1000% obvious, but building a neat app with good UX in 2017 doesn’t count for much. Having a solid marketing strategy in a validated niche is significantly more important than building the best app ever.

I’m currently at a point where I’ve released 3 iOS apps. One of them has done decently and the other two are not. I have to make a decision between prioritizing developing new features for my current apps or creating a new app. For the sake of learning new iOS tools (like the camera), it’s probably better for me to work on a new app. Hopefully I can properly validate my idea before I spend months building it this time.

Anger Driven Development

As a programmer, it’s nice to imagine perfect productivity conditions: many well defined, small units of work lined up. If the work at hand is clear and you have ample time to get into a flow, you expect to finish many things. Unfortunately, real life rarely works out that way.

Instead of picturing an ideal, efficient scenario, I want to talk about a less than ideal productivity method that manages to pop up every now and then: Anger Driven Development (ADD). ADD in this context might mean different things to different people.

What ADD means to me is that I’m working on a task, get frustrated, and then refuse to be beaten. Some of my more productive times have occurred when I was so pissed at the situation that I refused to throw in the towel. I will NOT be beaten by a machine. The power of human will can be indomitable at times.

While driven to extreme frustration at what started off as an “easy task”, it becomes man versus machine. Man does not want to give up. Man refuses to give up.

Even if I was tired or had other reasons to put the work off until later, Anger Driven Development does not give me the choice to stop. Like taking a hammer to a screw and forcing it in through sheer will power and brute force, Anger Driven Development can be messy. Anger Driven Development can’t stop, won’t stop.

The most amazing part of ADD (besides the task that is now completed) is the sense of triumph at the end. While it always feels good to be productive and get things done, there are few things like the joy of victory after ADD.

Anger Driven Development would never be my modus operandi, but it inadvertently has its place in my toolbox.

Logging during development with Apple Watch hardware

Inserting breakpoints or logging statements (such as NSLog) is relatively straightforward with an iPhone-only iOS app. But how do you log from the WatchKit Extension (aka Watch app)?

The good news is that logging isn’t filled with many complicated steps. The bad news is that the logging works intermittently.

  1. Add your NSLog statements in your WatchKit Extension. This is probably your InterfaceController.m
  2. Run the watch app on iOS Device + watchOS Device (in the WatchKit App scheme)
  3. Select Debug > Attach to Process > (click on your watch app name)
  4. Profit! You should see your NSLogs when they are triggered in the app lifecycle in Xcode

debug

If logging isn’t working, try typical Xcode debug steps such as:

  • deleting the app on your phone & re-running it in Xcode
  • restarting the phone and/or watch devices
  • clean Xcode (cmd + shift + k) and re-run the app
  • quit & restart Xcode

Optimizing for stable tools that don’t create perpetual work

Time is an incredibly important asset.

I come from a Ruby on Rails background. The progress of Rails updates & JS frameworks has been amazing & constant. Each new Rails patch brings with it some work to stay current. It’s not Rails’s fault since there are always new features or security issues that arise. Having a well maintained framework, such as Rails, is a huge boon for the community.

With any programmer tool, you generally want to be on the current stable release (for a variety of reasons including security & bug fixes). The issue is that upgrading to the latest stable version creates a never ending stream of (hopefully small) work.

Even if you went without a framework (Rails, Django, etc.), your server is running on a suite of tools. You’ll need to keep your OS (even LTS) and most likely nginx up to date.

Perhaps you want to outsource server maintenance, so you’re using Heroku. You’ll have to keep your configs compliant with the Heroku deployment framework & best practices.

What I’m getting at is that there are so many incredible tools available to developers today. Oftentimes, these tools are free and constantly get better & faster over time.

I’m wondering if there is, or if it would be possible to create developer tools that are optimized for API stability. No more figuring how to do things the framework-way every several months. Setup once, use forever. When you’re able to minimize the present value amount of time spent maintaining a tool, you’re freeing your future self to work on higher value tasks.

True Business

I recently read The Box by Marc Levinson.

Marc brings out this excellent insight about Malcom McLean, a pioneer in containerization (using Shipping Container to modularize transport & avoid break bulk):

Malcom McLean’s real contribution to the development of containerization, in my view, had to do not with a metal box or a ship, but with a managerial insight. McLean understood that transport companies’ true business was moving freight rather than operating ships or trains.

As the excerpt says, a shipper’s business is about transporting goods and not operating ships. I’d like to draw a parallel to web development. Developers need to know how to build & maintain websites, but the true business side of web development is about providing services to visitors.