Skip to main content
Log in

A field study of API learning obstacles

  • Published:
Empirical Software Engineering Aims and scope Submit manuscript

Abstract

Large APIs can be hard to learn, and this can lead to decreased programmer productivity. But what makes APIs hard to learn? We conducted a mixed approach, multi-phased study of the obstacles faced by Microsoft developers learning a wide variety of new APIs. The study involved a combination of surveys and in-person interviews, and collected the opinions and experiences of over 440 professional developers. We found that some of the most severe obstacles faced by developers learning new APIs pertained to the documentation and other learning resources. We report on the obstacles developers face when learning new APIs, with a special focus on obstacles related to API documentation. Our qualitative analysis elicited five important factors to consider when designing API documentation: documentation of intent; code examples; matching APIs with scenarios; penetrability of the API; and format and presentation. We analyzed how these factors can be interpreted to prioritize API documentation development efforts

This is a preview of subscription content, log in via an institution to check access.

Access this article

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Fig. 1

Similar content being viewed by others

Notes

  1. Details about the population of respondents can be found in a separate publication (Robillard 2009).

  2. To test with sufficiently large partitions, we aggregated the Owning and Major categories, and the Experimental and Hobby respondents.

  3. After correcting the p-values for the simultaneous testing of multiple hypotheses using Holm’s procedure (Westfall et al. 1999).

  4. Drawn only from the follow-up survey, since the interview participants were selected from the exploratory survey.

  5. A notable exception would be examples returned as the result of queries to code search engines.

  6. Complexity is informally defined as a combination of length of the example and amount of interaction with the API.

  7. Participants routinely used the terms “sample” and “example” interchangeably. In the quotes, the term “sample” does not necessarily refer to code samples as defined above.

  8. Developer 14 was relatively new to the profession, but older than average in age.

References

  • Beaton J, Jeong SY, Xie Y, Stylos J, Myers BA (2008) Usability challenges for enterprise service-oriented architecture APIs. In: Proc. IEEE symp. visual languages and human-centric computing, pp 193–196

  • Berglund E (2003) Designing electronic reference documentation for software component libraries. J Syst Softw 68(1):65–75

    Article  MathSciNet  Google Scholar 

  • Bloch J (2006) How to design a good API and why it matters. In: Companion to the 21st ACM SIGPLAN symposium on object-oriented programming systems, languages, and applications, pp 505–506

  • Bore C, Bore S (2005) Profiling software API usability for consumer electronics. In: Digest of int’l conf. on consumer electronics, pp 155–156

  • Brandt J, Guo PJ, Lewenstein J, Dontcheva M, Klemmer SR (2009) Two studies of opportunistic programming: interleaving web foraging, learning, and writing code. In: Proc. 27th int’l conf. on human factors in computing systems, pp 1589–1598

  • Clarke S (2004) Measuring API usability. Dr Dobb’s Journal Special Windows/NET Supplement

  • Corbin J, Strauss A (2007) Basics of qualitative research: techniques and procedures for developing grounded theory. Sage Publications

  • Creswell JW (2007) Qualitative inquiry and research design: choosing among five approaches. Sage Publications

  • Cwalina K, Abrams B (2009) Framework design guidelines: conventions, idioms, and patterns for reusable .NET Libraries, 2nd edn. Addison-Wesley

  • des Rivières J (2004) Eclipse APIs: lines in the sand. EclipseCon Technical Talk. http://www.eclipse.org/eclipse/development/apis/Eclipse-APIs-Lines-in-the-Sand.pdf

  • Ellis B, Stylos J, Myers B (2007) The factory pattern in API design: a usability evaluation. In: Proc. 29th int’l conf. on software engineering, pp 302–312. doi:10.1109/ICSE.2007.85

  • Feilkas M, Ratiu D (2008) Ensuring well-behaved usage of APIs through syntactic constraints. In: Proc. 16th int’l conf. on program comprehension, pp 248–253

  • Fowler M (2002) Public versus published interfaces. IEEE Softw 19(2):18–19

    Article  Google Scholar 

  • Holmes R, Walker RJ, Murphy GC (2006) Approximate structural context matching: an approach to recommend relevant examples. IEEE Trans Softw Eng 32(12):952–970

    Article  Google Scholar 

  • Hou D (2008) Investigating the effects of framework design knowledge in example-based framework learning. In: Proc. 24th int’l conf. on software maintenance, pp 37–46

  • Hou D, Wong K, Hoover JH (2005) What can programmer questions tell us about frameworks? In: Proc. 13th int’l workshop on program comprehension, pp 87–96

  • Jeong SY, Xie Y, Beaton J, Myers BA, Stylos J, Ehret R, Karstens J, Efeoglu A, Busse DK (2009) Improving documentation for eSOA APIs through user studies. In: Proc. 2nd int’l symp. on end-user development. LNCS, vol 5435. Springer, pp 86–105

  • Knowles MS, Holton III EF, Swanson RA (2005) The adult learner, 6th edn. Butterworth-Heinemann

  • Ko AJ, Myers BA, Aung HH (2004) Six learning barriers in end-user programming systems. In: Proc. symp. on visual languages and human centric computing, pp 199–206

  • Ko AJ, DeLine R, Venolia G (2007) Information needs in collocated software development teams. In: Proc. 29th int’l conf. on software engineering, pp 344–353

  • Larman C (2001) Protected variation: the importance of being closed. IEEE Softw 18(3):89–91

    Article  Google Scholar 

  • Lutters WG, Seaman CB (2007) Revealing actual documentation usage in software maintenance through war stories. Inf Softw Technol 49:576–587

    Article  Google Scholar 

  • McLellan SG, Roesler AW, Tempest JT, Spinuzzi CI (1998) Building more usable APIs. IEEE Softw 15(3):78–86

    Article  Google Scholar 

  • Nykaza J, Messinger R, Boehme F, Norman CL, Mace M, Gordon M (2002) What programmers really want: results of a needs assessment for SDK documentation. In: Proc. 20th annual ACM SIGDOC int’l conf. on computer documentation, pp 133–141

  • Olson M, Hergenhahn B (2008) Introduction to the theories of learning, 8th edn. Prentice Hall

  • Parnas DL (1972) On the criteria to be used in decomposing systems into modules. Commun ACM 15(12):1053–1058

    Article  Google Scholar 

  • Robillard MP (2009) What makes APIs hard to learn? The answers of developers. IEEE Softw (November/December):27–34

  • Rosson MB, Carroll JM (1996) The reuse of uses in Smalltalk programming. ACM Trans Comput-Hum Interact 3(3):219–253. doi:10.1145/234526.234530

    Article  Google Scholar 

  • Seaman CB (2002) The information gathering strategies of software maintainers. In: Proc. int’l conf. on software maintenance, pp 141–149

  • Shull F, Lanubile F, Basili VR (2000) Investigating reading techniques for object-oriented framework learning. IEEE Trans Softw Eng 26(11):1101–1118

    Article  Google Scholar 

  • Sillito J, Murphy GC, Volder KD (2008) Asking and answering questions during a programming change task. IEEE Trans Softw Eng 34(4):434–451

    Article  Google Scholar 

  • Stylos J, Clarke S (2007) Usability implications of requiring parameters in objects’ constructors. In: Proc. 29th int’l conf. on software engineering, pp 529–539

  • Stylos J, Myers BA (2007) Mapping the space of API design decisions. In: Proc. symp. on visual languages and human-centric computing, pp 50–60

  • Stylos J, Myers BA (2008) Implications of method placement on api learnability. In: Proc. 16th ACM SIGSOFT int’l symp. on the foundations of software engineering, pp 105–112

  • Stylos J, Graf B, Busse DK, Ziegler C, Karstens REJ (2008) A case study of API redesign for improved usability. In: Proc. symp. on visual languages and human-centric computing, pp 189–192

  • Tulach J (2008) Practical API Design: confessions of a Java framework architect. APress

  • Weiss RS (1994) Learning from strangers: the art and method of qualitative interview studies. The Free Press

  • Westfall PH, Tobias RD, Rom D, Wolfinger RD, Hochberg Y (1999) Multiple comparisons and multiple tests using the SAS system. SAS Institute Inc., Cary, NC

    Google Scholar 

Download references

Acknowledgements

We thank the anonymous participants in our study for generously contributing their time to this project, and the members of the Human Interactions in Programming group at Microsoft Research for feedback and discussions on the work reported here. Additional thanks to E. Duala-Ekoko, U. Farooq, G. Murphy, A. Ying, T. Ratchford, and the anonymous reviewers for feedback on the paper. We are also grateful to Jose Correa of the McGill University Statistical Consulting Service for his assistance with a statistical test.

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Martin P. Robillard.

Additional information

Editor: Premkumar Thomas Devanbu

Appendices

Appendix A: Exploratory Survey

Exact text of the survey described in Section 3.2 for the questions used in the research. This instrument also included questions whose answers were not included in the research reported in this article. These questions have been removed.

1.1 MSR API Learning Survey

The Human Interactions in Programming (HIP) group in Microsoft Research is conducting this survey to gather some initial data on Microsoft developers’ experiences with learning APIs. This data will be used in part to design tools and resources to help developers learn new APIs effectively. Your experiences and opinions would make a big difference in this research. Any personally-identifying information that you provide will be accessible only to the research team. For more information about this survey or the corresponding project, contact [the investigator].

This survey will take about 5 min to complete. Please refresh your memory about the API you learned the most recently. Published results will be anonymous. For your input to be useful, you must complete the survey by [deadline].

After taking the survey click “Submit” to save your changes. This survey is not anonymous

  1. 1.

    What is your primary job area?

  2. 2.

    How many total years of professional experience related to your job do you have?

  3. 3.

    How many of these years were at Microsoft?

This part of the survey will concern only your most recent experience with an API that you had to learn in your professional capacity. For this survey, consider that an API is a reusable set of program elements (classes, methods, functions, etc.) that are distributed and used together to provide higher-level functionality.

  1. 4.

    Name the last publicly-released API you learned:

  2. 5.

    What particular area of this API did you learn?

  3. 6.

    How many months ago did you start learning the API?

  4. 7.

    How many months ago did you last use the API?

  5. 8.

    How many hours in total would you estimate you’ve spent learning this API?

  6. 9.

    Were you also learning the programming language used to access the API? [Yes, No]

  7. 10.

    Were you familiar with the application domain of the API you learned? (For example, if you were learning WPF, were you already familiar with the creation of GUIs?) [Yes, No]

What obstacles made it difficult for you to learn the API? Obstacles can have to do with the API itself, with your background, with learning resources, etc. List the three most important obstacles, in order of importance (1 being the biggest obstacle). Please be more specific than the general categories mentioned here.

  1. 14.

    Obstacle 1:

  2. 15.

    Obstacle 2:

  3. 16.

    Obstacle 3:

  4. 17.

    Do you have any additional comments about learning APIs?

  5. 18.

    Would you be willing to participate in future research about this topic? [Yes, No]

Appendix B: Follow-up Survey

Exact text of the survey described in Section 3.4 for the questions used in the research. This instrument also included questions whose answers were not included in the research reported in this article. These questions have been removed.

1.1 API Learning Survey

The goal of this survey is to learn about your experience interacting with public APIs and to collect your opinions on how to improve API documentation. You can only complete this survey if you have had experience learning a public API that you remember enough to comment on. By “learning an API”, we mean using an API for the first time and engaging in activities that increase your knowledge of how this API works.

The survey should take less than 10 minutes to complete. As our appreciation for your time, participants who complete the survey will be entered in a draw for one $250 [on-line store] gift certificate.

The contest rules can be found at [internal URL]. After taking the survey click “Submit” to save your changes. This survey is not anonymous

  1. 1.

    How many years of professional experience do you have (decimals ok):

    API Learning Obstacles

This part of the survey applies only to the last public API you have learned.

  1. 2.

    What is the last public API you have learned? Pick the best match or choose “Other” (please specify below).

    [Azure; LINQ; Entity Framework; WPF; WCF; WF; CardSpace; Winforms; ASP.NET; ADO.NET; .NET Base Classes; Silverlight; XNA; Win32 (Admin); Win32 (Diagnostics); Win32 (Graphics); Win32 (Networking); Win32 (Security); Win32 (System Services); Win32 (UI); Other].

  2. 3.

    If you chose “Other”, please specify:

  3. 4.

    What programming language did you primarily use to access this API? [C/C \(\boldsymbol{++}\) ; C#; Visual Basic; JScript, JavaScript, or other web language; Other]

  4. 5.

    If you chose “Other”, please specify:

  5. 6.

    What was the main reason for learning this API? [Your team started owning it; You needed to use it extensively as part of your work; You needed to use it to complete some specific tasks, but these were not the main part of your work; You learned the API to experiment with new technology related to your job; You learned the API for a hobby project, or for a side project not critical to your work; Other (please specify)]

  6. 7.

    Other:

For each type of obstacle described below, please rate how severe this type of obstacle was in your experience learning the API you mentioned above. [For questions 8–12 and 14, possible answers were as follows:]

[Blocker (Led to work being abandoned or a different APIs used, could not be realistically overcome); Very Severe (Led to significant delays and frustration, very difficult to overcome); Severe (Led to delays and frustration, difficult to overcome); Moderate (Led to delays and/or frustration, but could be overcome without excessive difficulty); Trivial (Was easy to overcome); This was not an obstacle at all]

  1. 8.

    When learning the API you mentioned above, how severe was this obstacle: Your background was not adapted to learning the new API. For example: you were not familiar with the programming language or application domain, your previous knowledge of a similar API (or a previous version of the API) made it confusing to learn the new API.

  2. 9.

    When learning the API you mentioned above, how severe was this obstacle: The way the API was structured or designed made it difficult to understand. For example: it was not clear how to instantiate an object, there were too many abstract classes, the names did not make sense.

  3. 10.

    When learning the API you mentioned above, how severe was this obstacle: The technical environment made it difficult to use the API. By technical environment, we mean any technical aspects not directly related to the design of the API itself. For example, the tools did not work well, the API required extensive infrastructure to test, you could not get the builds to work.

  4. 11.

    When learning the API you mentioned above, how severe was this obstacle: Specific member-level usage details were not documented. For example, description of parameters, error codes.

  5. 12.

    When learning the API you mentioned above, how severe was this obstacle: You did not find conceptual-level information explaining how to use the API. Consider “conceptual-level” information to mean any type of information you need to use the API correctly that is not typically associated with particular API members (classes/methods/functions). For example, description of required concepts, the API’s execution model, non-trivial code examples, usage patterns, best practices, mappings between scenarios and API members.

  6. 13.

    If you encountered a type of obstacle not included in the above list, please describe it here:

  7. 14.

    If you described an additional obstacle, how severe was this obstacle?

  8. 29.

    Do you have any additional ideas for improving high-level API documentation that could help developers learn how to use APIs more efficiently? If so please describe it here.

Appendix C: Quantitative Survey Results

  1. 2.

    What is the last public API you have learned? Pick the best match or choose “Other” (please specify below).

    API

    Respondents

    Other

    54

    LINQ

    36

    WPF

    34

    WCF

    32

    .NET Base Classes

    32

    Silverlight

    24

    Win32 (System Services)

    17

    Win32 (Networking)

    16

    ASP.NET

    14

    Win32 (Security)

    14

    Winforms

    10

    Azure

    10

    Win32 (UI)

    8

    Win32 (Graphics)

    8

    XNA

    8

    WF

    5

    Entity Framework

    4

    ADO.NET

    4

    Win32 (Diagnostics)

    3

    Win32 (Admin)

    1

  2. 3.

    If you chose “Other”, please specify [Coded by categories]:

    API category

    Respondents

    Operating System

    16

    Development Tools

    12

    Web

    7

    Graphics/media

    7

    Networking

    5

    User Interface

    3

    Unknown

    3

    Business Applications

    1

  3. 4.

    What programming language did you primarily use to access this API?

    Language

    Respondents

    C#

    229

    C/C++

    97

    JScript, JavaScript, or other web language

    2

    Other

    5

    Visual Basic

    1

  4. 6.

    What was the main reason for learning this API?

    API learning context

    Respondents (%)

    You needed to use it extensively as part of your work

    47

    You needed to use it to complete some specific tasks, but these were not the main part of your work

    22

    You learned the API to experiment with new technology related to your job

    17

    You learned the API for a hobby project, or for a side project not critical to your work

    10

    Your team started owning it

    3

    Other (please specify)

    1

  5. 8–12.

    API Learning Obstacle Severity

     

    Blocker

    Very severe

    Severe

    Moderate

    Trivial

    Not an obstacle

    High-level documentation

    1

    9

    27

    37

    17

    10

    Low-level documentation

    2

    9

    13

    37

    21

    18

    Structure

    0

    4

    11

    43

    27

    15

    Technical environment

    0

    3

    10

    27

    32

    27

    Background

    0

    1

    6

    32

    29

    32

Rights and permissions

Reprints and permissions

About this article

Cite this article

Robillard, M.P., DeLine, R. A field study of API learning obstacles. Empir Software Eng 16, 703–732 (2011). https://doi.org/10.1007/s10664-010-9150-8

Download citation

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s10664-010-9150-8

Keywords

Navigation