Among those companies I worked with, one of them holds the record for the shortest time from first conceptualization to actually being available in the Store: two weeks! (I’m electing to not identify the app, simply because doing so in the context of this post can be interpreted a number of ways.)
To be more specific, the first meeting I and a few of my teammates had with this company, its developers, and members of the agency that would be helping them with the app, was October 3rd, 2012. A working app was the available to the public from the Windows Store on October 17th, and we had time to make a few updates and improvements before the Windows 8 launch events a week later.
How did we manage to pull this app together so quickly? In addition to the direct support provided by myself and my team, there are a number of factors that contributed to the speedy turnaround as I’ve written below. This list is also my answer to a question posed by one of my managers: “Why do some partners struggle when we have some who turn out an app very quickly?” What I’ve written here are then the guidelines of how to avoid struggling and get your productivity in high gear.
- Complete commitment. These guys weren’t sitting on the fence or making passive agreements. They made a decision and then didn’t let anything get in their way. Another way of saying this is that they just completely accepted the job and the platform as it is, and wanted to make the best experience within that reality. Another company I worked with early in 2012 for the first Windows 8 Consumer Preview, a travel app, took the same approach and got their first app done in 6 weeks, even with early tools and platform bugs. Conversely, some partners we’ve worked with seem to resist this level of commitment, making a big deal out of some small branding issue or turning other molehills into mountains, meaning that we seemed to slog through the process for month after month.
- Knowing the Resources for a Quick Start: with the two-week project, the first thing I did, given that I’m deeply familiar with the Win8 platform, was to bang out an 8-page summary of what controls, APIs, and samples to use to implement what features in the design. I think this significantly shortened the amount of time they needed to do the job. Indeed, I highly recommend that developers really know the scope of the resources available in the samples, because you can then just grab code from a certain sample to solve a certain need–the Windows 8 samples in fact cover about 95% of the platform (see this post for what’s not), so for most needs you’re find code that you can quickly borrow and adapt. You can use my book as a reference for this, because I made note of every JS sample in the appropriate feature context, and by extension this also hits a significant number of C#/C++/XAML samples as well.
- Properly scoped design: In short, don’t try to do too much the first time out the door. Locking down the scope of an app early on and limiting design and development work to just that scope is super helpful. The app we did in two weeks was like this: we had a design in two days to which we only made minor modifications after thorough review. This meant that we could focus on developing just that, and not get sidetracked into other ideas. I’ve seen other partners, in contrast, go back and forth many times with many different ideas, which meant that the developers were having to rewrite stuff.
Given that it’s so easy to update apps in the Windows Store, you don’t have to worry about getting it perfect the first time. Be sure to make it good enough to be useful and get good initial reviews, of course, but understand too that providing updates with more features later on will help to reengage customers.
Another way of saying this is that because the development cycle for apps can be short (a matter of weeks instead of months or a year), then it seems to work better to have the designers and planners lock down a rev of the app and let the developers go at it, rather than have too much back-and-forth while the app is being developed, trying to add features, etc., as that just bogs down the dev team.
- Clear, efficient, and appropriate methodologies: when a dev shop has clarity about who is doing what in their own teams, the process seems much smoother. The team on the two week app, for instance, had multiple teams or individuals working in parallel on app features that were easy to integrate together (my initial document also outlined what could be done in parallel). I’ve worked with other partners and agencies who had clear processes, as well; some partners, on the other hand, felt like they did everything by committee (too much methodology), as decisions were very slow in coming.
Some partners, on the flip side, also end up being too chaotic (lack of methodologies).By the way, if you don’t have a testing methodology, get one. Because the turnaround time for an app is not immediate like it is for the web, and because the customer reviews and ratings for your app stick across updates, you need to invest in up-front testing and not leave it to your customers to do that work for you!
- Experience with tools: Having a solid familiarity with the tool stack ahead of time makes a big difference. With Visual Studio, I think newcomers are put off by the complexity of the whole thing, not knowing where to begin, exactly. For my book I made a 10-minute introduction to Visual Studio to address this, in which I show the core features you need to know about for writing and debugging code. This is Video 2-1 in the book’s companion content; I’ve also posted to Channel 9 and YouTube.
I also highly recommend learning to use Blend for Visual Studio Express, especially for CSS styling and probably for XAML, because the tool can make you highly productive. Blend very much helped the travel app developer last year—saved many hours, if not some says, when tracking down style issues. I show some of this tool in Video 2-2 of my book’s companion content (I haven’t posted it elsewhere).I can also recommend A deep dive into Expression Blend for designing Metro style apps using HTML (//Build 2011), Building Awesome HTML apps in Blend for Windows 8 (//Build 2012), and Designing awesome XAML apps in Visual Studio and Blend for Windows 8 and Windows Phone 8 (//Build 2012).And again, knowing where to find answers (docs, samples, forums–see http://dev.windows.com) is a kind of tool. Some devs just don’t know what’s available to them. Third party libraries, if you know how to use them (e.g. jQuery), can also help productivity.
- Courage to ask questions: This has surprised me sometimes. Some devs are quick to reach out when they get stuck, whereas others seems to struggle along for a day or two before asking. I’ve made it a point to tell my partners that if they find themselves spending more than 30 minutes trying to find an answer, to just ask me. Otherwise you lose momentum and can get a little emotionally depressed (devs are not machines!) when you look too long for something, especially if you’re unsuccessful.Similarly, some devs are too fine-grained in their questions—asking how to solve something that doesn’t need solving if you step back and look at the larger issue at hand. I think the best results have come from devs who seek advice first on the general development approach, then ask good mid-level questions, then ask on specific details. This is again why the 8-pager I banged out for the two-week app was so effective.
More generally, having good ongoing communication is helpful for a variety of reasons. I worry most about partners that don’t say anything for a while; having a regular sync call helps to keep the doors open. This is very necessary if you’re working with an agency or have developers in different locales.
- Making the right assumptions: Beyond core architecture decisions, I’ve seen devs make a design choice based on mistaken assumptions about how the platform works, and didn’t consult with us until they were a ways down that road and started to run into trouble (e.g. assuming that they could do more with an iframe or webview than is actually allowed). Of course, devs don’t always know that they’re making wrong assumptions, and if they didn’t communicating well with us then we weren’t able to provide timely feedback (hence again the utility of having regular sync calls).Checking one’s assumptions is especially important for developers coming from other platforms like iOS and Android, because what works on those platforms might not work like you think on Windows.