Wednesday, August 31, 2011

Advice for Finding A Developer

While reading through my LinkedIn group messages today, I found an interesting question from a fellow group member that was search for an app developer. He had the same concerns I hear all the time with my potential client, so I decided to commit my answer to writing. My answer quickly exceeded the 4,000 character limit normally imposed on LinkedIn replies, but I think it's a really helpful guide to those out there looking to get their app idea off the ground.

I'm not sure what your background is, so I'll walk you through the process as though you had no experience. When evaluating an Android developer (or development firm), knowing the process through which a successful app is developed will help you tremendously.

Firstly, understand that a single developer is always going to be riskier than hiring a firm. While hiring a firm is scary for most people (mainly because of the perceived high cost), most firms have the product development experience to make your project a success. Individual developers may have the technical knowledge, but that's only half of the story. Without a real process (ie: Information Architecture -> Systems Design -> Graphic Design, etc), your project is much more likely to fail or never get off the ground. And once you've given money to an individual developer, you're very unlikely to get it back.

You'll also find the likelihood of having your idea "stolen" is much higher with an individual developer than with a firm. To most firms (mine included), creating apps is an internal investment, and we're far too busy trying to keep the lights on than investing in others' ideas. We have 100's of our own that we'd love to do, but just don't have the time.

You can find reasonably priced boutique firms in most cities. Look for one that specializes in the kind of software you want to write. For example, if you're looking for Android development, hire an Android development firm. They're out there (Disclosure: I own one), and you'll often get a much better price than going through a larger general purpose development firm (ie: a web development firm that does mobile). Just make sure you vet them - see what previous projects they've done, and talk to them before you commit any money.

Once you decide on a firm (or person), have them walk you through their development process. If they don't have a process, that's a big red flag and you should walk away. The process should have some form of the following steps:

1) Requirements gathering / feature development
Description: This is where the developer gets an understanding of all of the facets of your idea. They need to know exactly what you expect. Some development firms use user stories as a shortened way of doing this, while others may take longer and have a more formal process. In my experience, both are valid.
Deliverables: A list of the features that your software should have. My firm will also develop some basic marketing materials for certain customers, such as end-user profiles and target market data. This is not required, but can be helpful.

2) Information Architecture:
Description: This is where the developer creates wireframes to show how the end user will use the software (or app). This can include workflow diagrams, use-case scenarios, and wireframes. The least it should contain is wireframes. This is important, as it provides a basis for understanding how end-users are going to interact with your app which will ultimately determine how useful and usable your app is.
Deliverables: A project proposal. The developer should be able to give you a solid estimate on the price of the rest of the project after this phase.

3) Graphic Design:
Description: This is where a graphic designer takes the wireframes and information architecture documents and turns it into an appealing visual product. Graphic designers will keep the fundamentals of usability in mind, and should have a good eye for color combinations. It's easy to get side-tracked here, as this can often determine the marketing of a product, so make sure you understand the target market for your application very well before this part of the project commences. You generally won't reach 15-24 year old heterosexual males if your app has a pink unicorn theme.
Deliverables: Design Comps. These are usually Photoshop, Illustrator, or sometimes PDF files. These are exact representations of what the final app will look like, so don't be afraid to make tweaks. Understand, however, that sometimes an exact look is not possible in the programming phase, so try to encourage a design that can be "2 pixels off" if possible.

4) Software Architecture, Design, Development, and Test
Description: Finally, the meat of application development. This is usually all that a single developer will keep in mind when giving you an estimate for software development. In fact, as you can see, this is a later stage in the successful Software Development Lifecycle process. This requires a substantial knowledge of software engineering best practices, along with technical knowledge of the specific platform on which the software is being developed. Again, vet anyone you have doing this work -- ask them specific questions about how they plan to implement the software, and have them walk you through it.
Deliverables: A finished product, Project Schedule, Burn-down charts, and more. There are plenty of artifacts that are generated by a good development process. What you want to know is the process. Did they test the software? On what platforms? Is that adequate for the size of your market and your budget? Do they perform integration? Where is the source code?

Some other things to consider

Make sure you have a good contract. There are plenty of software contract examples out there. Make sure you find one specifically for Software Consulting or Product Development. Software is a new area of law, and there is a lot of contention about software ownership that can get you into trouble down the line. Make sure you are the sole owner of the software they create (called a "COMMISSIONED WORK" or "WORK FOR HIRE"). If you have any questions, don't be afraid to run it by an attorney. They'll help you find the caveats. We use a standard contract form from a company called "ContractEdge", which produces excellent contracts that are protect both sides of the arrangement are appear to me to be very fair.

That's my $0.02 -- best of luck with your project. If you're in the Southern California Area and need the best Android Developers, feel free to contact me. Android is a complicated beast, and we've been there since the beginning.

Friday, July 1, 2011

We wrote it for iPhone - but published on Android

When we first started Zomblings, the goal from the beginning was always to make it a game for iOS. After all, conventional mobile wisdom states that iOS is the way to go for paid apps. So, after over 2 months solid of 2x man teams (not including art and music), why did we suddenly release for Android first?

I think it's best to start from the beginning. When we started Zomblings, we decided to use a 3D game engine (slightly overkill, but better than writing our own from scratch) called Unity 3D. You can still see the splash screen at the beginning of our application. Unity has the ability to write the game on your Mac or Windows-powered PC, and to deploy on a number of platforms, including iOS.

Well, after months of hard work and personal mental fortitude, we finished Zomblings on the PC and it was time to build it on the Mac for iOS. I had a recent version of XCode, and after playing the provisioning certificate dance (which took over 6 hours), we were able to test and get the application working on the iPhone almost as flawlessly as it worked on the development machine. .

After one more provisioning certificate dance (this time only around an hour or so), I had a package to submit to apple. Then . . . I waited. In my searches in the meantime, I found that a good average wait time is around 6 days, and that's about how long it took. Except -- it was rejected. Why? Great question.

When I had downloaded XCode a month or two earlier, I figured the 4.3GB download would contain everything I needed. Alas, a new version of iOS -- version 4.3.3 -- had been released. Since our application was build against version 4.3.1 (and that's what we had tested on), we weren't prepared for the reviewers - who always use the latest version. Our game crashed on 4.3.3 because it wasn't built for it, and as a result we were rejected. We've created a new build since then (after another 4.3GB download) and resubmitted, but we're still waiting.

Ok -- so enough of that. How did we manage to get our app published on Android first?!

Well, in the months that we were working on the game, Unity quietly released their long-promised Android patch. After the rejection from Apple, we were left reeling. "How are we going to get our app our to our most certainly soon-to-be rabid fan base?". We all have Android phones, so the logical choice was to build for Android and see if we could get the application built for Android, tested on a number of devices, and on the market before the iOS version was approved.

The entire process, from build to publish, took 6 hours. Total. That includes testing the game on several phones, which takes an absolute minimum of 40 minutes to beat. Which illustrates again why I generally prefer to develop for Android.

Don't get me wrong, Apple has it down when it comes to paid apps. Our iOS paid game will most likely outperform our Android paid game 10 to 1 (Android 1, Apple 1). However, small companies like mine survive on the ability to come to market rapidly, and this is where Android takes the win.

Check out Zomblings on the Android market ( over a week before the iOS release. Buy a copy and support the Android platform for Developers. Let's make Android the first choice for developers, as it should be.

Tuesday, September 28, 2010

It's time to be different

If two is a pattern, three's a trend. I might have to start including TED talks in all of my business posts.

How do companies get noticed, and take off? How does a new idea become popular? It's about standing out, and taking a stand. It's about being remarkable.

Many companies talk about their differentiators in a detached way. Something like "We create high quality blah blah for the blah blah market". That great and all, but it doesn't really speak much. It doesn't compel. It doesn't inspire. It just is.

So, how do we stand out as a company? How does that fit into the paradigm of CC?

For us, it's about changing the way people interact with computers for the better. I don't mean that to say we're looking to train people. Quite the contrary -- we want to make computers work harder for our users. That means software that works right, and does what you need to do as you would expect it to. Your computers and devices should be an extension of you -- so simple to use, that you don't even have to think about it. Your software should just allow you to get things done, rather than have you thinking about how to use the software.

I'll give you an example. On our shopping list, you can view all of your shopping lists in a sticky-note view, as if they're laid out on a table. If you tap on a list on the table, it lets you view the list. And like lists on a table, you can even read the first few elements that are on the list. This is a simple concept, but one that EVERY one of our competitors missed (ColorNote now has something similar, although it's still not easy to set up).

In all of our applications, tapping on something is like picking it up or activating it. And tap-and-holding will always give you an alternate options menu when that makes sense.

We also don't believe in hiding important functions inside of menu (one peeve of mine with the Android platform). What you need should be visible to you when you need it. That's why we put the "add" and "clear" buttons in our shopping list right there on the screen. It takes little to no effort to figure out how to use our list, and that's the way it should be. Just tap the "add" or "save" buttons, and you're done.

Your computer should be an extension of you -- something so simple and intuitive that you know how to use it as you would a limb. That's what we're crazy about, and that's what makes us stand out.

Monday, September 27, 2010

It's all about the Why

Two times may be a pattern, but I've found yet another TED talk the illustrates perfectly the paradigm here at Catalyzing concepts.

How Great Leaders Inspire's all about the Why

At CC the Why for us is all about making software that makes our lives easier, because so many companies have great technical software that's unintuitive and difficult to understand. We make software that works right, that works how a normal person would expect it to work, and that makes our lives easier.

That's why we're so passionate about mobile software. Mobile platforms open the door to intuitive design, and break out of the paradigm of the standard Keyboard / mouse relationship. With Mobile software, we can make our software use touch where it makes sense to use touch, or tilt / accelerometer sensors where it makes sense to use those, or any other wide variety of fantastic new inputs to make our lives easier.

Mobile opens the door to a whole new paradigm of user input to a computer, because the user has so many more ways to interface with the computer! In a mobile platform, your physical location is now an input, as is the tilt of your phone, the direction you're facing, and even what's going on around you (via the camera)! We're all about using these new sensors to make software better.

In that way, we aim to challenge the status quo in traditional concepts of human-computer interaction. We want to create new experiences for our users, and fundamentally shift the human / computer relationship toward a more useful existence.

Wednesday, September 22, 2010

The ROWE will set you free

I just watched a great TED talk about motivating people, and a few of the things he mentioned were very eloquently-put versions of what we're trying to do here at Catalyzing Concepts.

I'd like to think that our motivations are intrinsic here. We do things because we like to do them, not because we'll receive a paycheck (we don't) or because we'll get famous (we might...;-). We do things here because they appeal to our desire to move forward, to sit on the cutting edge of technology and make cool stuff.

I'm a huge fan of the Results Only Work Environment (ROWE) - it works for me, and definitely motivates me to get things done. I like the idea of not having to work for 40 hours a week, because sometimes the project requires 80 and sometimes it requires 10. I like the idea of working on something with purpose, and doing so in my own natural rhythm.

I want people to feel like they're a part of something important, and something successful. Every cog in the machine is important, whether it's the new intern coming in or the seasoned senior engineer, or even myself. We all have a specific role to play to keep the momentum going forward. Part of this is stepping back, and trusting others to do what's right for our common goal.

Which leads me to Autonomy. People work best in a group, and you'll never bond with someone more closely then when you work together to meet a common goal. However, people should be free to exercise a certain amount of autonomy. I may require you to code a certain way (with a purpose, of course), but I'll give you the freedom to figure out how to solve a problem for the team.

Finally, we should all have the chance to show off, and we should always celebrate the small victories. Each project, each day is filled with frustrations, and with any luck these frustrations will end in a small victory. No victory is too small to celebrate, and we should strive to encourage each other in every way we can on all of our small victories.

Let's make something cool happen.

Wednesday, August 25, 2010

Follow the Rules (standards)

We have a specific way that things are done. This was determined at some point by someone, and the established method is updated periodically. However, doing things the prescribed way is not an option -- it is a requirement.

Why do we do this? Think about the franchise model. Anyone that's worked in fast food (and most of us have) remember the seemingly anal-retentive detail of the instructions. Things like "3 pickles for a large sandwich, 2 pickles for a medium sandwich" seem to be minute details that shouldn't matter.

However, if you look at franchise restaurants like McDonalds, you'll note how very successful they actually are! This is exactly a result of creating and strictly enforcing a set of rules (or in our case, standards).

McDonalds is successful as a restaurant because they establish a very specific protocol for their product. This allows them to create their products with reliable and consistent quality. Even though fast food may not get a good reputation for quality, it's amazing how consistent they are, even across franchises.

Software coding style guides and standards are our rule set. They help us establish a repeatable and consistent style within our code.

Why is consistent style important in code?

Because code that is consistent is manageable, readable, and re-usable. We develop the coding standards so that any developer can pick up any other developer's work and quickly understand it. This saves us a great deal of time and effort, and makes code review within the team easy. Consistent coding style means that our developers spend more time looking at and fixing bugs, and less time trying to figure out exactly what the code is doing.

As an added bonus, some of our rules (such as ensure variables describe their contents) have the added effect of exposing the programmer's level of understanding of the algorithm. If a developer cannot describe what a variable is, they don't understand how the algorithm works.

It is vital that all developers closely follow our coding standards and style guides.

Death by 1000 tiny features

This is a concept I've seen before. I call it "Project Death by 1000 Tiny Features". It's a syndrome that crops up whenever someone says "this project should be easy -- it's just little stuff".

This concept is pretty straight forward, and yet I've seen it happen more than once that a deadline is blown or a contract is lost because someone says "oh, that should be easy". That phrase is usually followed by a time estimate for completion which is at least an order of magnitude too short.

This is why project task enumeration is so important, and why I use it on my projects.

The idea is simple and basic engineering, done in a few parts.

For each project, write a set of user stories. These are explanations of features told as a narrative from the users' point of view. Things like "When the user clicks a button, zoom out and show the entire map" is an example of a user story.

We then take those user stories and turn them into concrete tasks. Each task is time-bound (between 2 and 8 hrs), and when the task is complete a specific feature is implemented.

After we have all the tasks, we prioritize the tasks. HOWEVER, we don't just give them a priority. We assign them to a specific version of the software. The features that are required for the core software to work are implemented in the first version. Features are then added on top of that to other versions.

This concept is also known as the Minimally Viable Product (MVP) method of development. It takes a massive, feature-rich description and pares it down to an atomic unit. Atomic is meant in the chemical sense, in that the final atomic unit is the minimum feature set required for that project to be categorized and used for its intended purpose.