Higher Productivity and Lower Costs

According to VersionOne’s 2010 study, 66% of agile practitioners report faster time-to-completion for software projects.  More than half of all respondants report that agile has “Significantly Improved” or “Improved” their ability to respond to change, alignment with business objectives,   team morale, time-to-market, productivity, software quality, risk management, engineering disciple, and software maintainability.

But a significant feature of Agile is that developers are less likely to build software that is no longer needed.  When software development iterations are large or are done in a “big bang” fashion, the long lead times between specification and delivery can mean that the features requested are no longer relevant to users.  Shortening the feedback cycle means that engineering resources are spent on delivering features that are actually useful, instead of out-of-date by the time that they are delivered.

VersionOne found that 74% of those surveyed reported that morale was improved through the introduction of agile processes.  Improvement in developer morale not only means higher-quality productivity as developers are motivated to work harder to ship software, but also that the highly mobile top tier of technical talent can be more easily acquired by the organization.

Faster to Market

Rally Software’s in-depth study of agile development showed that Agile practices lead to a 37% faster time-to-market for software projects vs traditional methods.

Salesforce.com reports a +568% increase in features delivered to customers as a direct result of implementing agile methods.

Higher Quality

David Rico’s research on Agile development showed that Agile projects have a median quality improvement of 63% over traditional methods and a minimum quality improvement of 10% in the companies he surveyed.  84% of the VersionOne survey respondants felt that Agile methodologies had reduced the number of bugs by 10% or more.

Improved Client Satisfaction

With all of these improvements, it’s no wonder that these practices lead to higher satisfaction among iPhone project clients.  iPhone development is a fast-changing world that moves even more quickly than other types of web, desktop, or systems development.

Many potential clients make the common mistake of adapting a traditional software development process to the mobile development world, without a true understanding of the assumptions and underlying requirements of the development methodology.

The iOS software market is much  more competitive than the traditional software market, because there is only one primary sales channel–the Apple App Store.  As a result, millions of software products compete for the same real estate.  Even in a “niche” vertical, there are often many software vendors competing for customer dollars.  If a competitor is using a lower-cost development methodology, that competitor will be able to consistently deliver a higher-quality experience to its users, putting you out of business.

Even if you have no competitors, Apple itself dictates a rapid pace for the iPhone and iPad application market.  iOS, the iPhone and iPad operating system, is currently on a yearly release cycle.  Because of Apple’s highly secretive product roadmap, it is very difficult to predict the future in this market.  Apple’s rapid improvements to iOS can obsolete dozens of product lines from individual developers overnight.  Sudden announcements can cause an unforseen shift in development, due to added or removed functionality in the underlying operating system or new hardware capabilities.  In this challenging marketplace, it is more important than ever to adopt an agile software development process for your iPhone projects, both to stay current on the latest Apple development practices and to remain competitive in a marketplace of other agressive software developers.

It should come as no surprise that according to a study at Colorado University, an overwhelming 80% of respondents reported an increase in customer satisfaction after introducing Agile methods.  Agile development methodologies are an important ingredient in our overall strategy at DrewCrawfordApps to deliver the highest quality software at the fastest possible speed.  When selecting a development partner for your iPhone project, make sure you are working with a development team with an understanding of the unique challenges of the iOS marketplace and with a development strategy that will lead to success for your iPhone development project.

Maintenance tasks typically involve:

• Fixing crashes or errors reported by users of the application.  Our automated bug tracking software helps us monitor bugs in the wild.  If the client has done a thorough job reviewing deliverables over the course of development and the developer is a high-quality developer, the number of errors is usually low, if they even exist at all.
• Adding features requested by users after release.  It is difficult to anticipate the cost of feature requests without knowing what they are, and the cost for this depends heavily upon the features requested.
• User support, an ongoing cost that varies depending on the popularity of the application and how easy it is to use.
• Networked applications may require hosting and administrative costs.  For example, a server might need to be rebooted occasionally.
• Scaling costs.  If your application becomes popular and uses a server or shared database, additional servers may be required or code may need to be optimized to scale more effectively to maintain high performance with more users.

Rather than signing lengthy recurring contracts, we generally recommend adding  a short-term (30-day) maintenance contract to handle minor issues after an application’s release, particularly for networked applications.  In our experience, this is usually more than enough to make minor bugfixes and add a few features to an application after release.  Major changes or additions that will not fit in the maintenance contract can be negotiated as a separate project.
Maintenance tasks typically contribute 10% of the total project size for a standalone application, and 30-40% of the project size of a networked or server-based application.

But it’s not enough just to have the idea of producing a simple phone.  Everyone knew that phones were too complicated.  It was a different matter to actually build one.  This is what was so hard.  Simple to use and simple to build are two very different things.

When RIM ( the creator of the Blackberry and the market leader) saw Steve Jobs’ simple demo, their reaction was not to copy the “great idea” of building a simpler device.  Their reaction was to laugh it off as impossible.  It couldn’t be done.  It was too difficult to build.

Apple was effectively accused of lying as it was supposedly impossible that a device could have such a large touchscreen but still get a usable lifespan away from a power outlet.  [RIM believed] the iPhone “couldn’t do what [Apple was] demonstrating…”

RIM is not a stupid company.  Their assessment of the iPhone as virtually impossible to build was completely accurate.  Their only miscalculation was just how many tens of billions Apple was willing to spend to bring this “simple device” to market.  Over 200 patents.  Billions of dollars in acquisitions.  Nearly 5 billion in R&D.  Thousands of full-time hardware and software engineers.  Investing billions in chip design at a time when every other computer manufacturer has outsourced all design overseas.  All to build a simple phone.

Like the iPhone itself, looking at an app project from a consumer’s point of view is like looking at the tip of the iceberg.  “Simple” applications are always the most difficult kind to build, because they require all of the complexity to be carefully hidden from the user.  Simple, well-designed applications have so much hidden below the surface.

Complex applications, in contrast, can sometimes be the easiest applications to build.  The easiest app to build is the one that does nothing–that requires the user to do all the work.  The less work the user has to do, the more work the programmer has to do, and the more complicated the project will be to build.

This is why it is so important to have a software developer on your team from the start.  A good developer will instinctively know what is “below the surface” for any proposed feature and will be able to guide the design to stay within budget and focus on those features which can be implemented within time and schedule constraints.

If you don’t have a software developer on your team from the start, you are doomed to making terrible decisions about designing any app, big or small.  You can only see what is “above the surface”, and you have know way of knowing if the “simple” menu you asked for is a few hours of effort or it really has a few months of costs submerged below the surface.

Misunderstanding this “iceberg principle” is perhaps the most common source of software project failure.  In the industry, it’s called the 90-90 rule:  the first 90% of the code takes the first 90% of the time, but the last 10% of the code takes the other 90% of the time.  In other words, the time and cost to implement a feature often has no determinable relationship to the user-visible part of the feature.

From our vantage point in the iOS development market, the unfortunate design procedure is usually something like this:  the client comes with a laundry-list of features without any technical guidance in creating the list, a list full of iceberg-features.  The client is tight-lipped about the budget because they want to shop the project to many different firms.  None of the contractors are sure whether they should cut a few of the pricey features to fit inside a budget, so everybody guesses what number the client wants to hear.  The company that wins is the one that says the lowest number–the company that failed to see most of the submerged complexity–usually the least competent firm.  Then the project runs over-budget and fails.

In reality, software development is a conversation.  Here’s what can be done for $20k, here’s what can be done for $50k, here’s what can be done for $100k.  If you  haven’t had that kind of conversation directly with a senior developer (not a sales rep), your project is doomed before you’ve written the first line of code.

According to the Standish Report, 71% of software projects are challenged or fail completely, and the average budget overrun for those challenged or failed projects is 56% over the original budget.  Software development is a risky business by any measure.  Overruns in software far exceed every other industry, and for those not “in the industry” it is difficult to understand how a project “estimated” at $25k turns into $39k in the blink of an eye, but it is unfortunately a market reality.

The dirty secret about T&M terms is that there’s no guarantee that the final cost resemble the initial estimate.  It’s no wonder that many contractors favor Time & Materials contracts, where when (not if) the budget is overrun, the client eats the cost.

Even above and beyond the Standish Report’s numbers for generic software development, competition in the iOS contract development space is at an all-time high, and there’s increasing downward pressure on iOS contractors to get contracts.  Over the same period, the actual cost to develop iOS projects has remained relatively stable.  This creates an impossible situation.

Since there’s no requirement that a T&M estimate match up with reality–it doesn’t.  Contractors keep producing more and more unrealistic “estimates” in order to beat out the equally unrealistic estimates of competing firms.  The end result is a sham competition to produce the lowest number, instead of the correct one.  We monitor the market constantly, and we regularly see “estimates” going out for 10-20% of the final project cost.  Either scope is aggressively cut, or budget is aggressively raised (often both), and the final product is nothing like the negotiated functionality or cost.  Sometimes the project is simply abandoned.  Either way, the client is left holding the bag.

My grandfather used to say “If you pay a man by the hour, he’ll work a lot of hours; if you pay him by the brick, he’ll lay a lot of bricks.”  Fixed Bid projects mean that you pay by the project, so you’ll actually get that project without any bait-and-switch.  It also means that the estimate the developer produces will be a real one, not a sham number to get you to sign.

In an environment where budget overruns are incredible, the most valuable thing you can have is insurance.  When you sign a Fixed Bid contract, you’re not only getting a project delivered–you’re buying insurance against a bad estimate.  The contractor is legally required to produce the agreed-upon project at the agreed-upon price, regardless of the accuracy or realism of the original estimate.  The developer eats the cost of overruns.

Contractors are reluctant to offer Fixed Bid terms for three reasons.  Firstly, because it’s difficult to accurately estimate the final cost of a software project, and they don’t really have confidence in their estimates.  Secondly, because taking the appropriate steps to ensure good protection against risk can be expensive, and can significantly raise the price of the estimate.  Thirdly, because the estimate is often competing against other T&M (made up) numbers, and quoting the premium for Fixed Bid terms often means the contractor loses the bidding war before it starts.  As a result, lots of deals are signed on T&M terms, and the App Store is littered with the carcasses of T&M projects gone awry, not to mention the mile-high pile of projects that never even made it that far.

Unlike every other player in the market, the vast majority of our business is Fixed Bid, and we have very few T&M contracts only in unusual circumstances.  We have tremendous confidence in the accuracy of our estimates and we’re not afraid to stick to them.  At the same time, our quotes tend to be a lot higher than the wishful optimism of T&M “estimates”.  But that’s the premium you pay to know with certainty how much your project is going to cost instead of being surprised part way through development.

When you’re comparing quotes, make sure that you’re comparing them on equal footing.  T&M estimates aren’t worth the paper that they’re printed on.  Ask the developer what percentage of its projects were delivered within the original budget.  After dozens of Fixed Bid projects, our track record is still 100%.

It should cost much less!

Sometimes it does.  Certain applications may simply not need certain components.  Coke or McDonalds may not need a PR campaign to launch an app–their existing brand recognition may be enough.  Highly technical apps designed for engineers may not require much in the way of design work–accurate technical bits may be enough.  Apps that rely heavily on off-the-shelf components may not require much QA.  And so on.

You may elect to learn some of the disciplines and do them yourself.  We’ve had professional graphic designers, marketers, and even other developers as clients, and so in these situations it’s not uncommon for a development firm to back off and have the client take more responsibility for the project–reducing the cost.  But if you’re not a professional, taking on responsibility can be a costly move when measured in terms of lost sales.

Another tactic is to aggressively cut scope to reduce costs.  It may be possible to cut features to get a Client/Server Application into the Standalone category, or to significantly reduce the complexity of the server tier by cutting features.  By reducing an application to a mere prototype, it may be possible to produce something tangible that can be used to acquire funds to develop it further.

There is also a certain amount of variation in developer costs.  For instance, we have no sales team to pay, and since we rely primarily on the strength of our work for business, our marketing budget is close to zero.  So our costs tend to be lower than shops with an army of sales staff and billboards on both sides of the street.  On the other hand, our estimates tend to be more accurate than the competition, and since projects are universally underestimated, sometimes realistic numbers can be higher than what others quote.  These effects can cancel each other out.

But far too often, instead of responsible scope cuts and other cost-cutting measures, corners are cut instead.  Software may be outsourced and developed poorly, QA may be forgotten entirely, design may be sent to the back of the bus, and so on.  In the rush to ship some product, it’s easy to lose track of what the value of that product is.

Suppose you are trying to build a strip mall in a populated area.  You find a plot of land that is next to a high-traffic road, do some research to determine that a strip mall could be reasonably successful, and start talking to architects and contractors.  They tell you that a typical strip mall is constructed for in the neighborhood of $5M.  Unfortunately, you only have $20,000 for the project.  Undeterred, you start trying to cobble together a team of temporarily-unemployed electricians on Craigslist, some freelance architects in India, and since the budget for materials is tight, you decide to construct it from corrugated cardboard.  It does not take a genius to work out that this will not be a successful project.

In fact, there are many successful avenues open to you–with $20,000 you could build a furnished treehouse or shed, you can give your home a new room or a remodel–these are realistic construction projects within your budget.  These projects have the advantage that you are not simply throwing your $20,000 away.

The same common sense does not seem to extend to iOS projects.  Undeterred by the true cost of building that strip mall, many people are trying to piece their apps together out of corrugated cardboard.  But unlike the construction industry, where there may be building codes, inspections, city ordinances, standards of practice, and professional organizations to protect people from scams and swindlers, there is unfortunately no equivalent for software development.  It’s the closest thing there is to a completely deregulated market.  And it’s the perfect condition for a lot of companies to come out of the woodwork to say what people want to hear–that with this industrial strength corrugated cardboard, you too can own a strip mall!  It’s a sales pitch older than Amway.

With good advice from the right developer, you can figure out what is possible within your budget and execute a sensible plan instead of an insensible one.

Wrapping Things Up

I hope this series has shed some light into the time, effort, and cost it takes to launch a successful iPhone or iPad app.  I’ve barely scratched the surface of what goes into project costs, even in a massive three-part blog post!

There are many factors to consider when thinking about any software development project, and every situation is unique.  If you’re interested in talking to a real developer about a realistic way forward for your project, get in touch.

Development

Any iPhone or iPad app is going to involve developers, people who write the software code.  Depending on the firm, these people may be called software developers, programmers, or engineers.

For many apps, the developers are the people who make or break your software.  Good developers can mean applications that run quickly, are powerful, and generally behave as expected.  Bad developers mean buggy, crash-ridden software that’s behind schedule.

An entry-level salary for a software developer in the United States is $50-60k.  Developers with several years of experience are often paid $80-90k, depending on location and workload.  Very simple applications (at the low end of the “Standalone App” category) may require a few weeks of developer time, more complex applications may  require six months and several full-time developers.  Considering an average time of two months and two developers, you’re looking at a cost of $30k in developer time.

It’s important to meet the actual people who will be responsible for developing your application.  Many firms are much larger than we are in sales staff VPs, managers, etc., but have about the same number of developers!  Others may simply be a friendly sales force for a low-quality overseas development shop.  Don’t let anyone pull a bait and switch! It’s not enough just to evaluate the sales guys for compatibility with your project–they’re paid to be compatible.  Make sure that you talk to the people who will actually be responsible for implementing the project, and ensure that they share your vision.

What about outsourcing?  Can’t I cut costs there?

I’ve written about outsourcing in the past.  Like everything in life, you get what you pay for.  There are wonderful overseas development shops that charge rates competitive with US developers.  If you are paying below market, you are asking for trouble.  Far too much of our work is fixing botched outsourcing jobs that could have been done right the first time at much less cost than it will be patch it up, both in terms of development time and effort as well as lost customer trust as a result of a buggy application.

QA

A good QA department can catch bugs and problems in-house before they escape in a test build, or worse, to your customers.  Every project needs a solid second pair of eyes to spot programming problems and squash bugs.  Good QA engineers bill $50-75 an hour, and you probably want one hour of QA for every three hours of development to spot bugs.

Design

In addition to development work, you need designers, people who lay out the user interface, produce artwork, and do other graphical design work.  It’s possible to have a good developer that drifts into some light UX design, or a good designer that drifts into light frontend development, and so you may find slightly different divisions of work across different types of firms, depending on the skillset of the individual people.  Smaller application developers tend to work with outside designers or have a few contractors “on-call”, whereas larger firms can have entire graphics and UX design departments in-house.  Larger corporate clients may already have an in-house design department that they’d like to use, so the background of the development firm and the makeup of their clients can have an impact on the design skill.

Again, it’s important to communicate and share your vision to the design team.  It’s also important for the technical and design team to have good rapport and to get along well.  Animations or dynamic visual effects may have complex technical and design requirements that require both skillsets to move in lockstep, and the last thing you want is for artwork to be produced or a technical solution to be chosen that is incompatible with the other!  It’s usually important to ensure the artists or UX designers have a good track record of designing for mobile software (as opposed to graphic design, web design, etc.)

Senior UX designers with some development experience are typically worth about $80k/year.  Graphic designers with more limited experience generally earn about $55k/year.  With an average figure of a designer with medium experience for a month, you are looking at about $7k for typical design and artwork production.

Management

Someone needs to coordinate and oversee project development.  At small firms like ours, senior developers may take this role and oversee and coordinate development, design, and the other parties in the dance.  At larger firms, project management may be a dedicated department with a sizeable staff.  Software development managers typically make about $120,000/yr, but usually oversee multiple projects at once, so the actual cost of that person for a single project may be closer to $5k-10k for shorter projects.

Marketing

A successful app launch often requires an extensive marketing campaign.  In today’s market, it is difficult to stand out from the crowd.  Retaining a PR firm can run anywhere from $5,000-$25,000/month or more.  Some PR freelancers bill in the neighborhood of $100/hr for basic press release and whitepaper writing if you want more of an “a la carte” public relations approach, but the economics of the app store often dictate doing an all-or-nothing marketing push over an incremental marketing model.

Tools & Technology

In addition to personnel, it takes specialized tools to create mobile applications.  Software has to be tested on a regular basis on every conceivable device, and so many firms stock up on dozens of test devices in multiple configurations.  Professional developers wear out computers far faster than consumers do, and so it’s not uncommon to budget $10k in new computing equipment per developer per year.

Then you need to factor in software licensing and costs.  The advent of open-source software has reduced these somewhat, but custom tools are still a requirement.  Professional-class bug trackers typically run about $5,000/year for a site license.  Source control hosting, testing software, database editing tools, Photoshop, and other tools of the trade have to be licensed.

Then you must factor in custom frameworks or components to be licensed for use in applications.  Because we’re a very focused company with almost all of our work in iOS, we’ve invested in building an incredible volume of pre-built libraries that are more readily adapted for iOS use (see our articles on CrashBuddy and LogBuddy), and so we tend to have a reduced licensing burden than other firms, but this comes at the cost of our developers’ time to write and maintain those libraries.

Then you have your typical overhead: office space and furniture might be $1000/month/person in a midsized city.  IT, servers, backups, infrastructure, hosting, e-mail, and internet access might run another $250/month/person.  Benefits, taxes, and payroll probably add about 15% to the cost of every contract.

The Final Bill

Consider a fairly simple application that is on the books for two months.  The cost structure might look like this:

• Two developer salaries, two months: $25,000
• One designer salary, one month: $7,000
• Tech lead / project manager : $5,000
• QA: $6,000
• Office space, computers, equipment (amortized): $8,000
• Software, licensing (amortized): $1,500
• Benefits, taxes, payroll: $8000

The final cost to develop our simple application (leaving no profit for the firm) in this case is $60,500.
It’s important to emphasize that these are typical figures for an application of arbitrary size.  Some apps have more or less development costs, more or less design costs, etc.  As discussed in the first part of this article, there are many different types of applications that may require more or less responsibilities from each of the necessary disciplines.

Also factoring into the price, different firms tend to emphasize different disciplines.  We are a developer-driven company, where software developers take more of an active role.  There are talented design-run or management-run firms, in which those skill-sets tend to be more emphasized and tend to extend further into territory traditionally controlled by other disciplines.

In addition, however, there are a few operating costs.  Considering a 12-month application life (many applications run shorter or longer), you may be looking at:

• Hosting costs: $500/month for 12 months
• Support contract: $500/month for 12 months
• PR/marketing: $5000/month for 3 months

e.g. an additional $27,000 in the first year.
So how does our $87,500 number for a simple application stack up?  Chockenberry, the developer of the award-winning Twitterific application estimated their total cost at $250,000.  Twitterific is a design-heavy app in the “Pre-existing API” category, which is much more complex than our simple application.  Another data point is the Barack Obama application, which reportedly cost $50-150k, also in basic agreement with our number.

Was this a lot more than you were expecting?  Continue on to Part III!

App Types

iPhone or iPad apps are not all alike.  You have several different kinds of applications.

Each of these application types may require a slightly different skill set, have a different time and cost profile, and require developers with different expertise.  Counterintuitively, it can sometimes be a mistake to try to find developers with experience building applications very similar to yours.  Generally speaking, developers with experience writing very complicated application types will be more effective at simple applications than those that have only developed simple products (Just as mathematicians are generally better at Algebra than high school graduates).  And so it’s important to identify the type of application you’re building in order to assemble the right construction team.

Standalone applications

Standalone applications are self-contained.  These applications can do data processing, display static content that doesn’t change, manipulate documents, and do other types of basic tasks.  Development time and effort varies primarily based on the type of processing required (file format support, etc.) and the complexity of the user interface to design and implement.

P2P applications

Peer-to-peer applications do some light app-to-app networking, like a multiplayer mode for a game.  They generally involve connecting with nearby users over Bluetooth.  This type of networking requires additional debugging and testing involving multiple phones or devices.

Pre-existing API or integration applications

The next tier of complexity are applications that talk to pre-built servers.  For instance, your company may have a database of information to be queried by the app, or you may be accessing data from a third-party data source.  Time must be allocated to learn the quirks of the API or server, to debug problems with communication, and to handle unusual error conditions.

Client/Server applications

Certain applications requires a server for off-phone storage and processing.  For instance, if your application allows users to save reviews, share status updates, search for nearby users, display content that updates on a regular basis, or other nontrivial tasks, a server is required to store and distribute this data to all devices.  Client/Server applications are one of the most common types of applications that people want to build.  Unfortunately, because Client/Server applications require both complete application development and complete development of server software, plus hosting and other ongoing costs, they tend to be both one of the most complicated and most expensive project types.

Multi-platform development

Apps that run well on more than one platform must typically be rewritten largely from scratch for each platform.  So if you are looking for an app that supports iPhone, iPad, Blackberry, Desktop Web, Android, and Windows Phone 7, you are looking at approximately 6x the cost of what that app would be on one platform.  If the platforms communicate in a networked manner, care has to be taken to define standards in an interoperable way.  In addition, most cross-platform projects engage different development teams for each platform, as most developers of quality only know one or two platforms well.  Doing cross-platform development correctly often requires the engagement of multiple firms as well as a “master” firm that writes the general specification.

Specialized technology, research

Some applications, like Augmented Reality applications, indoor location systems, or other technical challenges may require the development of novel methods or intellectual property.  Like any kind of invention, the time required to develop new technology is unbounded.  Many different approaches may need to be tried and combined to achieve the desired result, or the result may not even be achievable within the limitations of the current generation of technology.

Impossible applications

We sometimes get request for applications that are not possible on iOS, at least in the App Store.  These include things like affecting the behavior of other applications, modifying system settings, disabling features of the phone, accessing restricted data such as user e-mails, etc.  Apple has limited what App Store apps can do in order to prevent malicious apps from stealing user data, breaking a phone, or other matters of poor user experience.  If it’s a simple idea that doesn’t already exist in the store, it’s probably because technical or legal restrictions are in place that prevent it from being easy to execute.

Now that we’ve identified the type of application and learned something about the required skillset, it’s time for Part II: assembling the team.

To discover this, we need to look back all the way to C, the original “universal” programming language.  Many forget that the original goal was to create a standards-based, cross-platform development environment.  C/C++ is still in wide use today, but everyone will tell you there is no such thing as true cross-platform C/C++.

To rectify this situation, Java was created, the next savior of cross-platform code.  While Java is still widely used (particularly in the enterprise and a strangely Java-yet-not-Java implementation on Android), Java has also failed to live up to its name as a truly cross-platform application development framework, and it was recently deprecated for the Mac and is being largely abandoned as a desktop platform as well, apart from continued use in special niche open-source software and enterprise software.

The new siren song is cross-platform mobile development, the ability to write the code once and have it work on many platforms: Android, iOS, Windows, Blackberry, and more.  Unfortunately this is even more of a pipe dream than cross-platform desktop development, which has seen botched “solutions” dozens of times over its history.  Let’s examine some of today’s mobile cross-platform contenders.

HTML5

HTML5 is a standards-based loose collection of web technologies that let you build applications that run in a web browser.  HTML5 is mature enough that tool and platform support is pretty good, at least relative to the stability of some of the proprietary platforms.

Performance

Like any high-level language, HTML5’s JavaScript suffers from performance problems.  Mobile technology is still at the stage (unlike desktop development) where performance matters substantially.  Technologies we take for granted like garbage collection, while making the programmers’ lives much easier, suffer unacceptable performance penalties that make graphics, animations, and transitions sluggish and the UI appear unresponsive.  Even if you’re not doing complex calculations, basic UI suffers to the point where your users will notice.

We’re still at the infancy stage in mobile performance.  The computing power of an iPhone is, quite literally, the size of a postage stamp (the device is all screen and battery, very little horsepower).  Software advances like the Nitro Javascript Engine are interesting only because the engine they replace is so terrible, not because the new engine is particularly good.  Without an enormous breakthrough in battery life design, HTML5 development will likely continue to have poor performance for the foreseeable future.

Features

HTML5 offers only very limited visibility into device capabilities.  If you want to send push notifications, use CoreAudio, perform advanced GPS or location-based tasks, run in the background, record or edit video, audio, access the users’ Photos or Contacts library, do any sort of data visualization, responsive UI drawing, leverage existing frameworks, do any kind of number crunching or performance-sensitive calculation, display maps, utilize the contacts database, or store much data on the device, you will need to use native code instead of an HTML5 application.  If you don’t need any of those things, an HTML5 app might have enough power to do what you want–but in that case your app isn’t really very exciting to begin with.

Distribution

If you’re interested in distributing your app through the Apple App Store, you need to write native code.  If you want to leverage the iTunes billing system to do in-app purchasing, subscriptions, etc., you need to write native code.  While it is possible to wrap an HTML5 app in a thin layer of native code for this express purpose–unless you already have invested in an existing HTML5 app, it’s almost always cheaper to go the native route to begin with.

PhoneGap

PhoneGap is a small set of libraries that essentially offer a little bit of native glue to access native features while still basically writing an HTML5 application.

Tool Support

Because PhoneGap is so new, the tool support is terrible.  The state of PhoneGap debugging is absolutely awful. There is no debugger, and as good as you will get is printing debug statements to a log somewhere and/or trying to debug in a desktop web browser that behaves differently.  The debugging burden for a system like PhoneGap is enormous, which translates into huge productivity losses.

Performance

Because PhoneGap uses underlying web technologies, performance is the same as HTML5, i.e. not ready for even the most basic applications, at least according to the standards of most iOS users.

Features

PhoneGap adds a lot of native features to HTML5, but is still missing key features  like Contacts access, maps, any kind of fine-controlled media playback, calendar APIs, messaging APIs, access to native UI controls, and many more.

Distribution

Historically, PhoneGap users have had problems getting their apps approved for distribution, although it’s not clear whether or not this is still the case.  The official wiki describes how to hide PhoneGap from Apple and then states “This is not a guarentee, [sic] many users have been reporting rejections after removing all phonegap references.”

Titanium

Appcelerator’s Titanium is a purportedly cross-platform development solution covering desktop and mobile development for iOS, Android, perhaps Blackberry, Windows, Mac, and Linux.

Tool Support

The free tools do not have debugging support.  To get debugging and other basic developer comforts, you need to spend $500/developer/year.  Unfortunately I was not able to find anyone who had paid for the subscription to evaluate the effectiveness of the premium tools.

Performance

Titanium bills itself as a “native” app development environment.  Unfortunately, this is simply not true, at least not by any meaningful definition of the term.  It is only accurate to say that Titanium uses proportionally more native code than other platforms and exposes native controls, meaning faster UI response times in many common cases.  It does not mean that your entire app runs at native speed, since it still relies on the same JavaScript that powers HTML5 web apps, which suffer terrible performance problems.

Distribution

We’re aware of no problems related to distributing Titanium-based apps on the App Store.

Cross-Platform Compatibility

Because Titanium tries to be a “more-native” platform, it has many cross-compatibility problems, as native UI controls simply work differently on Android vs. iOS, and there’s no one-to-one mapping that will work perfectly, in spite of Appcelerator’s best efforts.

The problem that you then end up with the situation where I developed for iOS but didn’t test it on Android. I had faith that if it worked properly on iOS then it would still work fine on Android presuming I didn’t use any “platform specific” functionality. The problem is that it very quickly gets to a situation where everything doesn’t work properly on Android and it requires lots of time to fix the issue. Cross-platform? Not really.

If you’re technical, I would highly recommend reading Sam Moffatt’s entire review, as he does an excellent job relating the dozens and dozens of little snags in developing the most simple application in Titanium.  He documents inconsistent behavior between platforms, documentation that is completely missing or (worse) misleading, etc.  Titanium ends up being a passable development platform for certain situations, but completely fails in its effort for cross-platform compatibility.

So What’s the Right Way?

The right way is to write a separate native application for each platform.  This requires high time, effort, and expense, but it is the only way to provide a high-quality experience (i.e. one worth paying for) to your users.

If a platform is worth supporting at all, it’s worth supporting right.  Bad app experiences damage your brand and cost you valuable reputation with your customers.  Unfortunately we see many potential clients led astray by the lure of cross-platform development, only to end up with buggy software that runs poorly on any platform.  For many applications, true Objective-C-based native development is the clear best choice.

If you’re interested in letting us develop your native iPhone or iPad project, get in touch today.

This is only one of the latest in a long, dismal history of IT projects gone awry… What’s more, the failures are universally unprejudiced: they happen in every country; to large companies and small; in commercial, nonprofit, and governmental organizations; and without regard to status or reputation. The business and societal costs of these failures–in terms of wasted taxpayer and shareholder dollars as well as investments that can’t be made–are now well into the billions of dollars a year.

For one thing, software is one field in which it’s incredibly easy to snowball nontechnical people, who are often the ones providing funding for the project. I’ve seen this story play out way too many times:

It became pretty clear what Dave was really supposed to do: simulate an installation of Knowledge Essentials, run into “technical difficulties,” gather technical requirements and send them back to the developers, stall for a few days while the developers rush to build a prototype, install the prototype while explaining “technical difficulties” are preventing it from being functional, and then work closely with the marketing team to find a good excuse to reschedule the installation for a few weeks later. As soon as Dave realized this, he stormed into his manager’s office and angrily proclaimed: you’re kidding; there is no way I’m going to do this!
Three days later, Dave was on a plane headed to The Netherlands. They say everyone has a price; Dave’s was a 20% bonus and an extra week’s vacation.

As margins shrink, there’s increasing pressure for even the best firms to employ tactics like this.  It’s become so commonplace that programmers joke about how much they can get away with over drinks.

But it’s not just dishonesty that’s the problem.  Even when everyone means well, schedules are almost always worse than worthless.  From Rapid Development:

If Las Vegas sounds too tame for you, software might just be the right gamble. Software projects include a glut of risks that would give Vegas oddsmakers nightmares. The odds of a large project finishing on time are close to zero. The odds of a large project being canceled are an even-money bet (Jones 1991).

In 1998, Peat Marwick found that about 35 percent of 600 firms surveyed had at least one runaway software project (Rothfeder 1988). The damage done by runaway software projects makes the Las Vegas prize fights look as tame as having high tea with the queen. Allstate set out in 1982 to automate all of its office operations. They set a 5-year timetable and an $8 million budget. Six years and $15 million later, Allstate set a new deadline and readjusted its sights on a new budget of $100 million. In 1988, Westpac Banking Corporation decided to redefine its information systems. It set out on a 5-year, $85 million project. Three years later, after spending $150 million with little to show for it, Westpac cut its losses, canceled the project, and eliminated 500 development jobs (Glass 1992). Even Vegas prize fights don’t get this bloody.

The dirty secret about the software industry is that time and cost estimates are worse than guesses.  Nobody wants to talk about it, because they’re afraid everyone will discover that the emperor has no clothes.

Our Estimates

We’ve worked at a lot of firms with the industry-standard terrible software schedules, and when we formed our own company, we knew we could do better.  At DrewCrawfordApps, we pride ourselves on creating the most accurate estimates in the industry.

We use a modified form of Evidence-Based Scheduling, a scientific method that gives us incredibly accurate insights into our software schedules.  We start by breaking every project into small tasks, so small that each task is at most a few hours.  Projects may have hundreds or thousands of tasks, from planning, testing, development, feedback, maintenance, and more.  This granularity helps us estimate projects and keeps us honest about the work involved.

Obviously the first ingredient to accurate estimates is having experienced developers write them, instead of sales people.  Our estimates are always written by senior-level developers, and we perform extensive cross-checking by independently estimating items and comparing the estimates.  It sounds obvious, but many firms don’t invest the effort in getting it right.

We then estimate each individual task.  But we don’t just trust the estimates we write–we correlate them against previous work.  So if we estimate a task at 30 minutes, we don’t write 30 minutes on the schedule–we write down the average amount of time we’ve historically spent on things that were originally estimated at 30 minutes.  We have a wealth of historical information and complex algorithms that do the number-crunching for us.  For instance, here’s my estimation history:

You can see that my estimates are slightly pessimistic–what I estimate at five hours is usually four and a half.  But I have a few really bad estimates and a few really good estimates.  Our software corrects my estimates, so when I estimate a task at five hours, it writes it down as 4.5 hours.  But it also builds a full probability distribution–there’s a 10% chance it could be as bad as 10 hours, and a 10% chance it could be as good as 30 minutes.

Determining Ship Dates

We take all of these probability distributions for all of these individual tasks, aggregate them across all of our developers, and we are able to forecast our ship dates the way meteorologists forecast the weather (but with a lot more accuracy!).  Here’s a completion graph for one of our projects:

This project is on schedule.  There’s an 80% chance we will ship on time, and a 50% chance that we will ship a week early.  (We’re the only firm that ever ships projects early.)  This is a live report, that’s always up-to-date, telling us exactly when the project will ship.

Developer Timelines

But it’s not just about measuring delivery dates.  Our advanced systems can also predict individual developers’ schedules hour-by-hour:

Here you can see that on Saturday I’ll probably be working on “core2”, but there’s some chance I could be working on other things.  There’s a 4% chance I will be blocked and waiting for information from a client or one of our developers, which is good information to know.  If that number gets too high, I can take proactive steps to reduce that risk and keep the process flowing smoothly.  We construct color-coded timelines like this for every project and every developer, which helps us predict and proactively address slips well before they occur.

It’s important that we block out time for particular tasks.  It’s possible to ship a 100-hour project in two weeks–in theory.  In practice, we work on many projects at once, and it’s important to balance our time commitments effectively.  We can’t just drop everything we do and work on a new project, as that wouldn’t be fair to our existing clients.  Tracking individual developer timelines on individual tasks forces us to be honest about the amount of work we have currently on our plate and our ability to commit to new projects to maintain our high standards to clients and customers.

Data Collection

Our estimation algorithms are only as good as the data we can collect.  If logging time becomes too much of a hassle for our developers, we won’t have accurate historical data, and that means bad scheduling predictions.  Thankfully, we’ve invested in complex proprietary tools that automatically log our time with minimal effort.  There’s one step to start work on a project which automatically finds the correct version of the software to work on, downloads it to the developer’s local computer, and starts tracking time.  We’ve made it more difficult not to collect data.  This lets us correlate every individual change to a piece of software with an estimation item, meaning that every time we work on something, we’re collecting data to improve our scheduling forecasts.  As a result, we’ve collected tens of thousands of points of data.

The Result

What does this mean for you, the client?  It means that our estimates are more than just pieces of paper.  Every date, figure, and number has a wealth of expertise and research backing it up, and that’s why we have the most accurate estimates in the industry.  We hit our targets over 90% of the time, whereas the industry average has recently improved to 34%.

Unfortunately, it also means that we lose some work when we claim, accurately, that a project will cost $25,000 and take four months to deliver and a competitor claims, inaccurately, that it will cost only $10,000 and take two months.  But we think it’s more important that our clients feel comfortable relying on us for accurate information about their software projects than it is for us to win every contract.

If you’re interested in getting an accurate estimate for your software project, get in touch with us today!

Myth #1: Outsourcing Is Cheap

Consider this scenario: a potential client will come to us and ask us for a quote, which we gladly provide.  The client discovers that an overseas firm is quoting half our price, and so they select the overseas firm.  Six months later, they ring us up and beg us to do the project for our original number, because the firm they selected has already billed them triple and they have a horrible, buggy, half-fininshed product to show for it.

Unfortunately this scenario is very common, and we “rescue” several dozen projects a year from overseas vendors.  In many cases, the quality of the product is so terrible that we have to throw it in the garbage and start over from scratch. Many unscrupulous vendors will tell you anything to get the contract signed. If it sounds too good to be true–it probably is.  Don’t listen to anyone who says that your app can be built for a few grand and a prayer–unless you have a few grand to throw away.

A good rule of thumb is that a good developer will dig deep into your project requirements, will ask for a specification or will insist on developing one, and will ask questions and make suggestions that demonstrate a very deep understanding of your project’s design and goals.  Anyone who quotes you an exact number without first receiving and asking questions about your detailed specification is someone who has no idea what you want and is making up a number to get you to sign the contract.  Don’t fall for that trap.

Myth #2: Outsourcing Is Easy

When you select a professional, local iPhone developer or contractor, you get someone who understands your business problem and is someone who can get things done.  You get someone who keeps you up to date on your projects’ progress, who doesn’t need to be babysat or micromanaged, and who you can rely on to be an excellent advisor and partner in designing and developing your project.

When you outsource a project to a bottom-of-the-barrel software vendor, you get a different kind of service.  Language and cultural barriers conspire to prevent you from communicating about problems and issues effectively.  Work may be performed based on a bad specification (or even no specification!).  Issues and errors constantly have to be corrected, and the client often develops a severe mistrust for the vendor.  Cheap developers skimp on code quality, failing to prevent bugs, and even critical components like verifying that the software basically works for its purpose.  Working with a cheap developer means constantly listing and re-listing, e-mailing and re-emailing about every single problem, managing and micromanaging each individual task, and continually worrying about whether the vendor will ever get it right.   Do you want to stay up late at night wondering if your project is six months or six years behind schedule, or do you want a vendor that you can count on to get it right?

Myth #3: All Programmers Are About The Same

Paul Graham, an angel investor who makes his money picking software companies wrote that “A great programmer might be ten or a hundred times as productive as an ordinary one”.  Not to mention how many times an average programmer might be better than a bad one.  The variation in skill between programmers is enormous.  A good programmer can get your project done ten times faster and five times better than a bad one–if the bad one can even get the project done at all.

Myth #4: My Project Is Really Simple

There are no simple iPhone or iPad projects.  Each project requires a unique expertise and attention to detail.  The iPhone and iPad are some of the only platforms remaining that require the rare and esoteric skill of manual memory management, which often makes up well over 50% of the complexity of any iOS project.  Even many good developers do not have experience in this area and as a result iOS development is one of the most difficult types of software development today.

Not to mention the special challenges of performance on a low-power mobile device, battery life, navigating Apple review, limited memory, and testing and diagnosing bugs across many different devices.  Creating an app that is fast and easy to use requires a lot of experience.  Make sure you pick a vendor who is prepared to meet the unique challenges that your app will present.

Myth #5: This Cheap Vendor Has Many Success Stories

You only see the success stories.  IBM claims that over 80% of software projects fail because they were “over budget, late, missing function, or a combination”.  At DrewCrawfordApps, we have a proven track record of delivering custom software right, on-time and on-budget.

Large outsourcing clearinghouses have incredibly high turnover.  Smaller shops are bought and sold, and your project may pass through any number of developers’ hands.  How do you know the people working on your project are the same people who built the company’s portfolio?  You don’t.  How do you get in touch with the developers who actually work on your app?  If you’re lucky, you can e-mail a person who can e-mail a person who can talk to the developers actually responsible for doing the work.

At DrewCrawfordApps, I personally oversee all our projects.  Our clients all have my cell phone number and can always talk to myself or another senior engineer directly who can solve their problem or give them a status update.  We have no slimy sales people, no telephone menus, nobody to screen our calls, and nothing to prevent you from getting any concerns or anxieties you may have dealt with immediately.  Since I personally handle all our client aquisitions and proposals, I can answer any questions you have and because I’m a developer, not a sales guy, I’m not afraid to tell you if for some reason we’re not the right fit for your project.

Choosing the right development partner is the most important decision in ensuring your project’s success.  So before you outsource that project, think about the hidden costs.  Doesn’t your app deserve a professional developer?

Contact us today to discuss your projects’ unique needs.  But even if we’re not the right fit for your project, we’d encourage you to choose a local professional developer, or even an overseas developer of comparable quality and cost.  But we’ve rescued enough botched projects to know that if you solicit quotes from a cheap shop you’re asking for trouble.