What’s involved in developing an app: The initial natural history of Petunia

As mentioned, we recently launched Petunia, our iPad app for recording and sharing pet health information. After developing the app, and starting to market it, I want to say something about the work and skills involved in developing an app. There seems to be a feeling amongst some people that apps are simple to develop. Perhaps this feeling is due to the amazingly large number of apps on the market? It does seem clear that some apps are simpler than others, and an app with few features and few pages or screens is likely to be simpler to develop than an app with many features and multiple pages or screens. I can really only speak from what I know, and I do know that some apps take considerable skill and time to develop.

The main skills involved in app development are programming, visual design and user experience design. Visual or graphic design can be seen in the graphics used in many apps, Petunia included. Visual design can also be seen in other parts of an app. In the selection of colors. In the selection of fonts. And, more generally, in the layout of the entire user interface. In some cases in app development, a graphic designer creates mockups of the entire visual look of an app before programmers are involved. User experience design is possibly less obvious. Apps such as those on iPhone’s and iPad’s generally need to be designed to be easy and fun to use. For example, the so-called onboarding experience of an app is critical. If an app is difficult or confusing to use in the first 30 seconds after a user first launches it, they will likely just delete it. If an app immediately asks to use your calendar or contacts without any apparent reason for these permissions, this can amount to a bad onboarding experience. Giving a user a good experience in onboarding and other situations takes attention by programmers, visual designers, and/or specific people with user experience skills.

Petunia version 1.0 took from 4/26/13 to about 11/5/14 to develop, and most of this was programming effort. That is, about 19 months. Not all of this was full-time, however. Because Petunia doesn’t yet pay for itself, for about six months of the time in that interval, I worked full-time at contract jobs to pay the bills. That’s not to say I didn’t work on Petunia during that time. Like any small business owner, I worked some evenings and weekends. I am the Petunia programmer. My wife, Natasha Vizcarra, leads the visual design of the app.

All in all, as of 11/26/14, in programming the Petunia app, I have written about 45,150 lines of Objective-C program code. Objective-C is the main programming language used to develop Apple apps. Additionally, to develop the Petunia Server, which runs on a hosting service on the interwebs and takes care of some Petunia account and in-app purchasing issues, I wrote another 2,722 lines of program code, this time in the PHP language. Both of these counts were obtained using David A. Wheeler’s SLOCCount program. These counts are of program code only, and do not include comments or program code documentation.

What does it mean in terms of effort and skills to have nearly 50,000 lines of program code in an app? While a program is not a book, just to give an analogy, if a book has 35 lines of text per page (two pages from two different books I just counted had about that many), that gives a 300 page book about 10,500 lines of text. So, keeping in mind that this is just a rough estimate of length not of complexity, Petunia has about five books of text length-wise in its program code. I am not going to try to argue whether a page of a book is more or less complicated, involving more or less writing or thinking time, than 35 lines of program code. My point is just to give you a rough idea of the time and effort it takes to write an app.

As an interesting and related estimation, David Wheeler’s SLOCCount program, as used above to determine the count of lines of program code, estimates the amount of time to write 45,150 lines Objective-C code at 10.94 person years, and the 2,722 lines of PHP code at 0.58 person years (see also http://www.dwheeler.com/sloccount/). A “person year” is the amount of effort that a single person can make in a single year. Clearly, the reality is that it took less time than this—it took me about a year and a half. But, again, my point is that it takes considerable time and skill to develop apps.

What about the specific skills involved in writing apps? Can anyone develop apps? Well, I can say with confidence that not just anyone can develop apps. I say that because I was formerly a college professor teaching computer science, and as part of that, teaching programming, and a few students were just not cut out for programming.

Must all app developers have formal training in programming and/or computer science? Most certainly not. Not every person who is a professional programmer, and not everyone who has apps on app stores has formal education in computer science or programming. Some people (the lucky ones?) just happen to have what it takes without formal education.

I’m not one of those! Or at least, my initial exposure to computers was in the context of formal education. I have a BS, an MA, a MS, and a Ph.D. with that formal education split about equally between computer science and psychology. When I started on my BS degree in 1981, I had no prior experience with computers. My tendency is to think that as programs get longer and more complicated, it takes more and more knowledge and experience to develop those programs.

Someone once said that abstraction is the secret sauce of programming. What we often try to do when developing a program is to create abstractions or program components that model or correspond to general problems that need to be solved in the app. For example, in developing Petunia, and considering the data entry needs of the app, I decided to make an abstraction, or general-purpose set of program code, for data entry. This data entry abstraction is used when a user enters pet profile information, when a user enters vet visit or home event information, and when a user makes selections about sharing. A main part of this data entry abstraction is called a DataEntryTable, and here is an example of what one of those tables looks like when displayed on the screen in Petunia:


Why do I mention this idea of abstraction? Well, the choice of abstractions can increase or decrease the difficulty of development of a program. If you can create abstractions that are relatively general purpose, where they can be used in many places in your program code, they can reduce the difficulty of developing that program. In my example above, by creating this DataEntryTable abstraction, I was able to re-use it in various places in my program and thus I avoided re-writing similar program code in various parts of my program. This re-writing takes time (as does the development of an abstraction!). If you have to re-write a long-ish section of code more than say two or three times, you probably want an abstraction of some kind. Deciding when to create an abstraction and what that abstraction should look like is one of the skills involved in developing a program.

Program development also includes finding problems (“bugs”) in those programs. When a program crashes or stops working, we often say it has a bug. As above, my tendency is to think that as programs get longer and more complicated, it takes more and more knowledge and experience to find bugs in (“debug”) those programs. With some program bugs, it takes an analysis spanning many components of a program, and the interaction between many components, at many levels, to find the problem. And then, once you figure out what the problem is, you have to figure out how to solve the problem. Sometimes a fix is easy. A single line of code perhaps. Sometimes a fix is far more difficult and involves rethinking major parts of the system design.

I should make it clear that Petunia was certainly not developed in isolation. Apple provides an immense collection of software tools (software development kits or “SDKs”) in their iOS system. These mobile operating systems (e.g., iOS, Android) are very powerful systems. Plus, as most developers do, I have made liberal use of the SDK’s provided by other, very generous, software developers. If you take a look at the “About” box in the Settings of Petunia, you’ll see what I mean. Plus, Petunia makes use of a great deal of sounds, music, and images graciously made available by others (again, see Petunia’s About box). The program code line counts I gave above, however, were all from code developed specifically for Petunia.

C. G. Prince