From Scratch
update: I’ve released Routinely!
So, I’ve got this idea for an App…
Its incredible how much dust those eight little words must have kicked up in the last twenty or so years. Ideas are followed by conversations, then arguments, then napkin sketches, then email threads. Eventually, after whiteboards, user stories, code, pizza, coffee, bugs, fixes, deployments, and some more coffee, some ideas spring to life. This is the first of a series of posts that will try to capture the story of how my idea turns into an App, from scratch.
Motivation
So, this idea that I have… it’s decent. Its not a “change the world” idea- Its barely a “change your day” idea- it’s just something that I came up with that I think will help me be more mindful, more aware, and more successful in my daily routines.
I’m not going to share too many details about the idea itself, for a couple reasons: first, I want to focus these posts on capturing the journey, not the destination. I want to capture the procedural steps along the way, and focusing on the what instead of the how will be distracting. Second, the idea itself is still only partly baked. Eventually, there will be screen shots and videos that show the app in action- that will do a much better job of showcasing the actual idea.
How I Got Here
I really can say that I’ve had a wonderful time writing software over the past 20 or so years. I’ve built business applications for small businesses, large corporations, and massive enterprise scale government customers. I’ve written software that has powered social networks with tens of millions of users, and have used voice recognition to help a marketplace of health care professionals. Most recently, I’ve developed cutting edge algorithms that drive personalized learning for thousands of students in schools across our country, every day.
Everything that I’ve accomplished with software, I’ve done with Microsoft’s .NET framework. Naturally, I want to leverage as much of that experience and expertise as possible for my app idea.
Sidebar, for my less technical readers: .NET is basically a language that people can use to describe programs to all sorts of computers, from laptops to mega-clusters of thousands of servers. Early in my career at Microsoft, I was part of a team called “.NET Velocity”, which helped get companies started writing software using .NET.
Enter Apple.
You maybe have noticed that “App” was significantly missing from my list of software development accomplishments. There is, of course, an obvious reason for this. When the iPhone was released in 2007 (or, more accurately, when the App Store was released in 2008, along with version 2 of iOS), the world of software development was forever changed. Apple introduced the next wave of computing, and we’ve all been swimming in it’s ocean of apps ever since.
However, making apps for an iPhone has traditionally not been easy. Apple chose a powerful, but relatively obscure language for it’s devices, and that language was not directly compatible with .NET.
Over the past few years, the options for creating iPhone apps has expanded. A handful of companies presented ‘cross-platform’ tools that allowed developers to create apps not just for iPhone, but for Android as well, using a bevy of different languages. Also, in 2014, Apple introduced it’s own new development platform, named Swift, which took the power and performance of their existing language and combined it with many of the features and conveniences of the cross-platform tools that had been brought to market.
Xamarin or Swift?
So, I’m faced with a choice:
- On one hand, Swift is an excellent platform for developing iPhone apps: it’s modern, well designed, and has a vibrant development community. Apple has provided excellent, robust documentation for the language, and whenever new features are announced for Apple devices, Swift will have the first and best documentation and samples to learn those features.
- On the other hand, Xamarin (one of the above mentioned cross platform tools) is built around the .NET platform, which means I can more directly apply my decades of experience building software. Xamarin provides access to the same capabilities that swift offers, but will obviously lag behind Apple in it’s support and documentation of new features. Xamarin has been around longer than swift, and also has an active, vocal, vibrant developer community.
I’m going to experiment with both, but Xamarin seems like the better choice. With Swift, I would be learning both a new language, and a new development paradigm; it would be like learning jujutsu and the Japanese language at the same time. Its certainly possible, but not ideal. Conversely, using Xamarin would allow me to focus on just learning the new development paradigm; then, If i want to learn Swift afterwards, I can focus on just the intricacies of the language, without stumbling through the motions at the same time.
Methodology
How, exactly, am I going to do this? I may not know exactly how i’m going to get there, but I have an idea of where I want to end up, I know of a general roadmap of how to get there, and I know what next steps I can take to make the best progress towards my destination. This is the right mindset for the practice of Agile software development. Unlike traditional software development approaches, Agile focuses on learning along the way, iterating often, and adapting to needs as you discover them, instead of trying to plan for every possible eventuality ahead of time. If Agile has become a positive signal of quality for software development process, Open has become a signal of thoughtfulness and contribution. Though there are many definitions of open, the common thread that weaves them together is the believe that great code should be shared: sharing code allows others to both learn from and improve upon your work.
My goal is to be as Agile and Open as possible. The code will eventually land on GitHub, and I plan on openly sharing my agile artifacts (tasks, user-stories, epics, sprints, issues, etc).
Next Steps:
in the spirit of Agility, here are my major next steps (aka, user-stories) that I hope to accomplish in the next few weeks (aka, sprints):
- Environment: Produce a fully functional Dev environment, that allows for simulated and actual (e.g., device) testing.
- Minimum Viable Product: develop a functional version of the app, that allows me to test out the most basic user stories/use cases, using my phone.
- Alpha Testing Plan: identify a group of folks that might want to participate in helping me design, test, and maybe even build the app.
- Agile Tools: find a good tool that lets me easily share Agile artifacts users and collaborators.
If anybody out there has any advice or tips, please feel free to reach out!
