- App Projects Are Not Small and Easy
- Apps Are Not Easy to Program
- Poor Skill Set Fit
- If You Get a Good Developer, You Still Have to Worry
- The Idea Is Not More Important Than the Execution
- Unwillingness to Delegate: Micromanaging
- Bikeshedding
- Poorly Defined Requirements
- Out-of-Date Requirements Documentation
- Constantly Changing Requirements
- Leaving the Worst for Last
- Cost Overruns
- That Last 10%
- The Whack-a-Mole Problem
- Poor Communication
- Abdication of the Management Process
- Wrapping Up
This chapter is from the book
This chapter is from the book
This chapter is from the book
Apps Are Not Easy to Program
App development requires skill and experience. Because of the relative lack of raw computing power, one of the difficulties with mobile development is that the code in an app is fairly interdependent. It’s unfortunately way too easy for this piece of code in this part of the app over here to have an effect on that piece of code in that part of the app over there. So the developer has to be extra careful.
Our Expectations Were Set by the Web...
We software developers as an industry got somewhat spoiled during the late 1990s and early 2000s because much of the exciting work being done in technology used web technologies and web servers. And the good thing about web servers at the dawn of the century is that really powerful servers could be purchased for a modest amount of money. With the rise of the 64-bit PC CPU, servers could hold more RAM than most web transactions could ever use, and it became not just feasible but expected for servers to hold entire databases in memory cache.
Add to that the fact that web protocols themselves were becoming widely adopted, and it became easier than ever to build a web application that could be reached by millions or tens of millions of users with a relatively small team of programmers working out of someone’s garage. Web protocols also allowed the creation of much richer user experiences than had previously been possible for widely distributed applications because the layout rendering, font handling, and image display were offloaded to the machine running the web browser.
The good thing about this kind of web development is that each web request is mostly independent of every other web request, and the servers have enough power that each request can have all the resources it wants. Under enough traffic, that ceases to be true, but then at that point, it’s relatively simple (assuming that things are engineered correctly) to put more web servers in parallel and use the networking infrastructure to share the incoming traffic load between them. Eventually if a service became popular enough, it would start running into tricky scaling problems that required a lot of performance tuning, but a lot of companies avoided this entirely.
...And Then Invalidated in the Mobile World
But mobile development has different constraints and requires different techniques. There’s never as much memory in the device as the app developer wants because memory banks draw too much power, and battery life is the overriding concern of the device vendor. All the graphics have to be drawn on the device’s screen as well, so you don’t have the luxury of offloading it to another machine as you can with the web. And apps don’t even have exclusive use of the device; there’s often mail being fetched or music being played in the background, and the app could be interrupted at any instant if a phone call or text message comes in. This means that apps are constantly resource constrained. It’s a delicate balancing act that doesn’t happen so often in the web world.
So the situation in mobile app development today is much closer to the client/server programming of the 1980s and 1990s than the web programming of the early 2000s. The primary differences from a programming standpoint are that mobile platforms have far, far better development environments (developer tools, frameworks, libraries, and components) than existed back in the heyday of client/server, and mobile apps generally only have to implement the client half of the client/server equation. Figure 1.2 shows the major differences between web, enterprise, and mobile development.
)
Figure 1.2 Visualization of the three largest differences between mobile app development and other common types. (Shorter bars are better in this case.)
Mobile Apps Are Outside Your Control
The other thing that web servers made us lazy about is bugs (and I say that as a recovering ASP.Net and Ruby on Rails programmer). The nice thing about writing server code is that when something goes wrong, you can figure out what happened (hopefully) from the server logs, and you can make a change and push it to the servers and fix the bug before it affects too many of your users (again, hopefully). There were times, especially immediately after particularly poorly tested releases, that teams I’ve worked on have done a dozen or so different releases of web server code in a day, each one fixing one or more bugs or performance problems. And the great thing there is that as soon as the server is patched, every subsequent web request will get the fixed behavior.
In mobile app development, by contrast, you can’t iterate as quickly. Once an app is installed on a user’s phone, only that user can decide to upgrade to the next version of the app. Depending on the bug, the user might choose to just delete your app instead of update it (and maybe even leave a bad review). But even worse, in mobile app development, you don’t ever have direct access to the machine your code is running on, so if there’s a problem, you can’t just look at your server logs and find it. Tracking down a bug that’s happening only on a subset of smartphones and tablets and doesn’t happen for the developer can be a real nightmare.
And last but not least, there’s often the dreaded “Waiting for Review” lag. Although some app stores, like Google Play, will let you upload new app versions as soon as you’ve fixed a bug, other stores, like those from Apple and Amazon, require your update to be reviewed before it can be released, and that causes even more time to elapse between when a bug is brought to your attention and when a fix is available to your users.