mirror of
https://github.com/amyjko/cooperative-software-development
synced 2024-12-25 21:58:15 +01:00
Fixed several typos.
This commit is contained in:
Amy J. Ko
parent
b46afee2f9
commit
27274c2abf
7 changed files with 26 additions and 27 deletions
17
book.json
17
book.json
|
|
@ -67,7 +67,7 @@
|
|||
"brooks95": "Brooks, F.P. (1995). [The Mythical Man Month|https://books.google.com/books?id=Yq35BY5Fk3gC].",
|
||||
"callaú13": "Callaú, O., Robbes, R., Tanter, É., & Röthlisberger, D. (2013). [How (and why) developers use the dynamic features of programming languages: the case of Smalltalk|https://doi.org/10.1145/1985441.1985448]. Empirical Software Engineering, 18(6), 1156-1194.",
|
||||
"casalnuovo15": "Casey Casalnuovo, Bogdan Vasilescu, Premkumar Devanbu, and Vladimir Filkov. 2015. [Developer onboarding in GitHub: the role of prior social links and language experience|https://doi.org/10.1145/2786805.2786854]. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2015). ACM, New York, NY, USA, 817-828.",
|
||||
"casalnuovo15-2": "Casey Casalnuovo, Prem Devanbu, Abilio Oliveira, Vladimir Filkov, and Baishakhi Ray. 2015. [Assert use in GitHub projects|https://doi.org/10.1145/2568225.2568285]. In Proceedings of the 37th International Conference on Software Engineering - Volume 1 (ICSE '15), Vol. 1. IEEE Press, Piscataway, NJ, USA, 755-766.",
|
||||
"casalnuovo15b": "Casey Casalnuovo, Prem Devanbu, Abilio Oliveira, Vladimir Filkov, and Baishakhi Ray. 2015. [Assert use in GitHub projects|https://doi.org/10.1145/2568225.2568285]. In Proceedings of the 37th International Conference on Software Engineering - Volume 1 (ICSE '15), Vol. 1. IEEE Press, Piscataway, NJ, USA, 755-766.",
|
||||
"chedeua15": "[React JS with Sebastian Marbage and Christopher Chedeua|https://softwareengineeringdaily.com/2015/07/27/react-js-with-sebastian-markbage-and-christopher-chedeau/], Software Engineering Daily",
|
||||
"chen09": "Chen, Chien-Tsun, Yu Chin Cheng, Chin-Yun Hsieh, and I-Lang Wu. [Exception handling refactorings: Directed by goals and driven by bug fixing|https://doi.org/10.1016/j.jss.2008.06.035]. Journal of Systems and Software 82, no. 2 (2009): 333-345.",
|
||||
"chen15": "Chen, L. (2015). [Continuous delivery: Huge benefits, but challenges too|https://doi.org/10.1109/MS.2015.27]. IEEE Software, 32(2), 50-54.",
|
||||
|
|
@ -85,8 +85,8 @@
|
|||
"dibella13": "di Bella, E., Fronza, I., Phaphoom, N., Sillitti, A., Succi, G., & Vlasenko, J. (2013). [Pair Programming and Software Defects--A Large, Industrial Case Study|https://doi.org/10.1109/TSE.2012.68]. IEEE Transactions on Software Engineering, 39(7), 930-953.",
|
||||
"dingsøyr03": "Torgeir Dingsøyr, Emil Røyrvik. 2003. [An empirical study of an informal knowledge repository in a medium-sized software consulting company|http://dl.acm.org/citation.cfm?id=776827]. In Proceedings of the 25th International Conference on Software Engineering (ICSE '03). IEEE Computer Society, Washington, DC, USA, 84-92.",
|
||||
"duala12": "Ekwa Duala-Ekoko and Martin P. Robillard. 2012. [Asking and answering questions about unfamiliar APIs: an exploratory study|http://dl.acm.org/citation.cfm?id=2337255]. In Proceedings of the 34th International Conference on Software Engineering (ICSE '12). IEEE Press, Piscataway, NJ, USA, 266-276.",
|
||||
"dybå02": "Dybȧ, T. (2002). [Enabling software process improvement: an investigation of the importance of organizational issues|https://doi.org/10.1145/940071.940092]. Empirical Software Engineering, 7(4), 387-390.",
|
||||
"dybå03": "Tore Dybå. 2003. [Factors of software process improvement success in small and large organizations: an empirical study in the scandinavian context|http://dx.doi.org/10.1145/940071.940092]. In Proceedings of the 9th European software engineering conference held jointly with 11th ACM SIGSOFT international symposium on Foundations of software engineering (ESEC/FSE-11). ACM, New York, NY, USA, 148-157.",
|
||||
"dybå02": "Dybå, T. (2002). [Enabling software process improvement: an investigation of the importance of organizational issues|https://doi.org/10.1145/940071.940092]. Empirical Software Engineering, 7(4), 387-390.",
|
||||
"dybå03": "Tore Dybå (2003). [Factors of software process improvement success in small and large organizations: an empirical study in the scandinavian context|http://dx.doi.org/10.1145/940071.940092]. In Proceedings of the 9th European software engineering conference held jointly with 11th ACM SIGSOFT international symposium on Foundations of software engineering (ESEC/FSE-11). ACM, New York, NY, USA, 148-157.",
|
||||
"ebert15": "Ebert, F., Castor, F., and Serebrenik, A. (2015). [An exploratory study on exception handling bugs in Java programs|https://doi.org/10.1016/j.jss.2015.04.066]. Journal of Systems and Software, 106, 82-101.",
|
||||
"endrikat14": "Stefan Endrikat, Stefan Hanenberg, Romain Robbes, and Andreas Stefik. 2014. [How do API documentation and static typing affect API usability?|https://doi.org/10.1145/2568225.2568299] In Proceedings of the 36th International Conference on Software Engineering (ICSE 2014). ACM, New York, NY, USA, 632-642.",
|
||||
"ernst15": "Neil A. Ernst, Stephany Bellomo, Ipek Ozkaya, Robert L. Nord, and Ian Gorton. 2015. [Measure it? Manage it? Ignore it? Software practitioners and technical debt|https://doi.org/10.1145/2786805.2786848]. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2015). ACM, New York, NY, USA, 50-60.",
|
||||
|
|
@ -112,8 +112,7 @@
|
|||
"jackson01": "Jackson, Michael (2001). [Problem Frames|https://books.google.com/books?id=8fqIP83Q2IAC]. Addison-Wesley.",
|
||||
"johnson13": "Brittany Johnson, Yoonki Song, Emerson Murphy-Hill, and Robert Bowdidge. 2013. [Why don't software developers use static analysis tools to find bugs?|http://ieeexplore.ieee.org/abstract/document/6606613] In Proceedings of the 2013 International Conference on Software Engineering (ICSE '13). IEEE Press, Piscataway, NJ, USA, 672-681.",
|
||||
"johnson15": "Brittany Johnson, Rahul Pandita, Emerson Murphy-Hill, and Sarah Heckman. 2015. [Bespoke tools: adapted to the concepts developers know|https://doi.org/10.1145/2786805.2803197]. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2015). ACM, New York, NY, USA, 878-881.",
|
||||
"kalliamvakou17": "Kalliamvakou, E., Bird, C., Zimmermann, T., Begel, A., DeLine, R., & German, D. M. (2017). [What makes a great manager of software engineers?|https://ieeexplore.ieee.org/abstract/document/8094304/] IEEE Transactions on Software Engineering.",
|
||||
"kalliamvakou20": "Kalliamvakou, E., Bird, C., Zimmermann, T., Begel, A., DeLine, R., German, D. M. [What Makes a Great Manager of Software Engineers?|https://doi.org/10.1109/TSE.2017.2768368]] IEEE Transactions on Software Engineering, 45, 1, 87-106.",
|
||||
"kalliamvakou17": "Kalliamvakou, E., Bird, C., Zimmermann, T., Begel, A., DeLine, R., & German, D. M. (2017). [What makes a great manager of software engineers?|https://ieeexplore.ieee.org/abstract/document/8094304/] IEEE Transactions on Software Engineering, 45, 1, 87-106.",
|
||||
"kay96": "Kay, A. C. (1996). [The early history of Smalltalk|http://dl.acm.org/citation.cfm?id=1057828]. History of programming languages---II (pp. 511-598).",
|
||||
"kenney00": "Kenney, M. (2000). Understanding Silicon Valley: The anatomy of an entrepreneurial region. Stanford University Press.",
|
||||
"kernighan16": "[Language Design with Brian Kernighan|https://softwareengineeringdaily.com/2016/01/06/language-design-with-brian-kernighan/], Software Engineering Daily.",
|
||||
|
|
@ -159,7 +158,7 @@
|
|||
"murphyhill09": "Emerson Murphy-Hill, Chris Parnin, and Andrew P. Black. 2009. [How we refactor, and how we know it|http://dx.doi.org/10.1109/ICSE.2009.5070529]. In Proceedings of the 31st International Conference on Software Engineering (ICSE '09). IEEE Computer Society, Washington, DC, USA, 287-297.",
|
||||
"murphyhill13": "Emerson Murphy-Hill, Thomas Zimmermann, Christian Bird, and Nachiappan Nagappan. 2013. [The design of bug fixes|http://dl.acm.org/citation.cfm?id=2486833]. In Proceedings of the 2013 International Conference on Software Engineering (ICSE '13). IEEE Press, Piscataway, NJ, USA, 332-341.",
|
||||
"müller03": "Matthias M. Müller and Frank Padberg. 2003. [On the economic evaluation of XP projects|http://dx.doi.org/10.1145/940071.940094]. In Proceedings of the 9th European software engineering conference held jointly with 11th ACM SIGSOFT international symposium on Foundations of software engineering (ESEC/FSE-11). ACM, New York, NY, USA, 168-177.",
|
||||
"nelson19": "Nelson, N., Brindescu, C., McKee, S., Sarma, A., & Dig, D. (2019). [The life-cycle of merge conflicts: processes, barriers, and strategies</a>. Empirical Software Engineering, 1-44.|https://link.springer.com/article/10.1007/s10664-018-9674-x]",
|
||||
"nelson19": "Nelson, N., Brindescu, C., McKee, S., Sarma, A., & Dig, D. (2019). [The life-cycle of merge conflicts: processes, barriers, and strategies. Empirical Software Engineering, 1-44.|https://link.springer.com/article/10.1007/s10664-018-9674-x]",
|
||||
"ng06": "T. H. Ng, S. C. Cheung, W. K. Chan, and Y. T. Yu. 2006. [Work experience versus refactoring to design patterns: a controlled experiment|http://dx.doi.org/10.1145/1181775.1181778]. In Proceedings of the 14th ACM SIGSOFT international symposium on Foundations of software engineering (SIGSOFT '06/FSE-14). ACM, New York, NY, USA, 12-22.",
|
||||
"norris17": "[Tech Leadership with Jeff Norris|https://softwareengineeringdaily.com/2016/09/22/tech-leadership-with-jeff-norris/] (2017). Software Engineering Daily.",
|
||||
"northrup16": "Software Engineering Daily (2016). [Reflections of an Old Programmer|https://softwareengineeringdaily.com/2016/11/09/reflections-of-an-old-programmer-with-ben-northrup/]",
|
||||
|
|
@ -206,7 +205,7 @@
|
|||
"stol14": "Klaas-Jan Stol and Brian Fitzgerald. 2014. [Two's company, three's a crowd: a case study of crowdsourcing software development|http://dx.doi.org/10.1145/2568225.2568249]. In Proceedings of the 36th International Conference on Software Engineering (ICSE 2014). ACM, New York, NY, USA, 187-198.",
|
||||
"stroustrup96": "Stroustrup, B. (1996). [A history of C++: 1979--1991|http://dl.acm.org/citation.cfm?id=1057836]. In History of programming languages---II (pp. 699-769).",
|
||||
"stylos08": "Jeffrey Stylos and Brad A. Myers. 2008. [The implications of method placement on API learnability|http://dx.doi.org/10.1145/1453101.1453117]. In Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of software engineering (SIGSOFT '08/FSE-16). ACM, New York, NY, USA, 105-112.",
|
||||
"syedabdullah06": "Syed-Abdullah, S., Holcombe, M., & Gheorge, M. (2006). The impact of an agile methodology on the well being of development teams|https://doi.org/10.1007/s10664-009-9123-y]. Empirical Software Engineering, 11(1), 143-167.",
|
||||
"syedabdullah06": "Syed-Abdullah, S., Holcombe, M., & Gheorge, M. (2006). [The impact of an agile methodology on the well being of development teams|https://doi.org/10.1007/s10664-009-9123-y]. Empirical Software Engineering, 11(1), 143-167.",
|
||||
"tao12": "Yida Tao, Yingnong Dang, Tao Xie, Dongmei Zhang, and Sunghun Kim. 2012. http://dx.doi.org/10.1145/2393596.2393656 How do software engineers understand code changes? An exploratory study in industry. In Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering (FSE '12). ACM, New York, NY, USA, , Article 51 , 11 pages.",
|
||||
"thongtanunam16": "Thongtanunam, P., McIntosh, S., Hassan, A. E., & Iida, H. (2016). [Review participation in modern code review: An empirical study of the Android, Qt, and OpenStack projects|https://doi.org/10.1007/s10664-016-9452-6]. Empirical Software Engineering.",
|
||||
"treude09": "Christoph Treude and Margaret-Anne Storey. 2009. [How tagging helps bridge the gap between social and technical aspects in software development|http://dx.doi.org/10.1109/ICSE.2009.5070504]. In Proceedings of the 31st International Conference on Software Engineering (ICSE '09). IEEE Computer Society, Washington, DC, USA, 12-22.",
|
||||
|
|
@ -226,9 +225,9 @@
|
|||
"weiser81": "Mark Weiser. 1981. http://dl.acm.org/citation.cfm?id=802557 Program slicing. In Proceedings of the 5th international conference on Software engineering (ICSE '81). IEEE Press, Piscataway, NJ, USA, 439-449.",
|
||||
"wobbrock11": "Wobbrock, J. O., Kane, S. K., Gajos, K. Z., Harada, S., & Froehlich, J. (2011). [Ability-based design: Concept, principles and examples|https://doi.org/10.1145/1952383.1952384]. ACM Transactions on Accessible Computing (TACCESS), 3(3), 9.",
|
||||
"woodcock09": "Jim Woodcock, Peter Gorm Larsen, Juan Bicarregui, and John Fitzgerald. 2009. [Formal methods: Practice and experience|http://dx.doi.org/10.1145/1592434.1592436]. ACM Computing Surveys 41, 4, Article 19 (October 2009), 36 pages.",
|
||||
"woodfield81": "S. N. Woodfield, H. E. Dunsmore, and V. Y. Shen. 1981. http://dl.acm.org/citation.cfm?id=802534 The effect of modularization and comments on program comprehension. In Proceedings of the 5th international conference on Software engineering (ICSE '81). IEEE Press, Piscataway, NJ, USA, 215-223.",
|
||||
"woodfield81": "S. N. Woodfield, H. E. Dunsmore, and V. Y. Shen. 1981. [The effect of modularization and comments on program comprehension|http://dl.acm.org/citation.cfm?id=802534]. In Proceedings of the 5th international conference on Software engineering (ICSE '81). IEEE Press, Piscataway, NJ, USA, 215-223.",
|
||||
"xia17": "Xia, X., Bao, L., Lo, D., Kochhar, P. S., Hassan, A. E., & Xing, Z. (2017). [What do developers search for on the web?|https://link.springer.com/article/10.1007/s10664-017-9514-4]. Empirical Software Engineering, 22(6), 3149-3185.",
|
||||
"ye03": "Yunwen Ye and Kouichi Kishida (2003). [Toward an understanding of the motivation Open Source Software developers|http://dl.acm.org/citation.cfm?id=776867]]. In Proceedings of the 25th International Conference on Software Engineering, 419-429.",
|
||||
"ye03": "Yunwen Ye and Kouichi Kishida (2003). [Toward an understanding of the motivation Open Source Software developers|http://dl.acm.org/citation.cfm?id=776867]. In Proceedings of the 25th International Conference on Software Engineering, 419-429.",
|
||||
"yin11": "Zuoning Yin, Ding Yuan, Yuanyuan Zhou, Shankar Pasupathy, and Lakshmi Bairavasundaram. 2011. [How do fixes become bugs?|http://dx.doi.org/10.1145/2025113.2025121] In Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering (ESEC/FSE '11). ACM, New York, NY, USA, 26-36.",
|
||||
"zeller02": "Andreas Zeller. 2002. [Isolating cause-effect chains from computer programs|http://dx.doi.org/10.1145/587051.587053]. In Proceedings of the 10th ACM SIGSOFT symposium on Foundations of software engineering (SIGSOFT '02/FSE-10). ACM, New York, NY, USA, 1-10.",
|
||||
"zeller09": "Zeller, A. (2009). [Why programs fail: a guide to systematic debugging|https://www.google.com/books/edition/_/_63Bm4LAdDIC]. Elsevier.",
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ More recent developers have investigated ideas of *architectural styles*, which
|
|||
* *Client/server*, in which data is transacted in response to requests. This is the basis of the Internet and cloud computing<cito15>.
|
||||
* *Pipe and filter*, in which data is passed from component to component, and transformed and filtered along the way. Command lines, compilers, and machine learned programs are examples of pipe and filter architectures.
|
||||
* *Model-view-controller (MVC)*, in which data is separated from views of the data and from manipulations of data. Nearly all user interface toolkits use MVC, including popular modern frameworks such as React.
|
||||
* *Peer to peer (P2P)*, in which components transact data through a distributed standard interface. Examples include Bitcoin, Spotify, and Gnutella._
|
||||
* *Peer to peer (P2P)*, in which components transact data through a distributed standard interface. Examples include Bitcoin, Spotify, and Gnutella.
|
||||
* *Event-driven*, in which some components "broadcast" events and others "subscribe" to notifications of these events. Examples include most model-view-controller-based user interface frameworks, which have models broadest change events to views, so they may update themselves to render new model state.
|
||||
|
||||
Architectural styles come in all shapes and sizes. Some are smaller design patterns of information sharing<beck96>, whereas others are ubiquitous but specialized patterns such as the architectures required to support undo and cancel in user interfaces<bass03>.
|
||||
|
|
|
|||
|
|
@ -53,6 +53,6 @@ These differences in notation can have some impact. Encapsulation through data s
|
|||
|
||||
Code editors, development environments, and program comprehension tools can also be helpful. Early evidence showed that simple features like syntax highlighting and careful typographic choices can improve the speed of program comprehension<baecker88>. I have also worked on several tools to support program comprehension, including the Whyline, which automates many of the more challenging aspects of navigating dependencies in code, and visualizes them<ko09>:
|
||||
|
||||
|https://www.youtube.com/embed/pbElN8nfe3k|The Whyline for Java|The Whyline for Java, a debugging tool that faciliates dependency navigation|Amy J. Ko]
|
||||
|https://www.youtube.com/embed/pbElN8nfe3k|The Whyline for Java|The Whyline for Java, a debugging tool that faciliates dependency navigation|Amy J. Ko|
|
||||
|
||||
The path from novice to expert in program comprehension is one that involves understanding programming language semantics exceedingly well and reading _a lot_ of code, design patterns, and architectures. Anticipate that as you develop these skills, it will take you time to build robust understandings of what a program is doing, slowing down your writing, testing, and debugging.
|
||||
|
|
@ -1,12 +1,12 @@
|
|||
Despite all of your hard work at design, implementation, and verification, your software has failed. Somewhere in its implementation there's a line of code, or multiple lines of code, that, given a particular set of inputs, causes the program to fail. How do you find those defective lines of code? You debug, and when you're doing debugging right, you do it systematically <zeller09>. And yet, despite decades of research and practice, most developers have weak debugging skills, don't know how to property use debugging tools, and still rely in basic print statements <beller18>.
|
||||
Despite all of your hard work at design, implementation, and verification, your software has failed. Somewhere in its implementation there's a line of code, or multiple lines of code, that, given a particular set of inputs, causes the program to fail. How do you find those defective lines of code? You debug, and when you're doing debugging right, you do it systematically<zeller09>. And yet, despite decades of research and practice, most developers have weak debugging skills, don't know how to properly use debugging tools, and still rely in basic print statements<beller18>.
|
||||
|
||||
# What is debugging?
|
||||
|
||||
To remedy this, let's discuss some of the basic skills involved in debugging.
|
||||
# Findings defects
|
||||
|
||||
To start, you have to *reproduce* the failure. Failure reproduction is a matter of identifying inputs to the program (whether data it receives upon being executed, user inputs, network traffic, or any other form of input) that causes the failure to occur. If you found this failure while _you_ were executing the program, then you're lucky: you should be able to repeat whatever you just did and identify the inputs or series of inputs that caused the problem, giving you a way of testing that the program no longer fails once you've fixed the defect. If someone else was the one executing the program (for example, a user, or someone on your team), you better hope that they reported clear steps for reproducing the problem. When bug reports lack clear reproduction steps, bugs often can't be fixed<bettenburg08>.
|
||||
|
||||
# Finding the defect
|
||||
|
||||
To start, you have to *reproduce* the failure. Failure reproduction is a matter of identifying inputs to the program (whether data it receives upon being executed, user inputs, network traffic, or any other form of input) that causes the failure to occur. If you found this failure while _you_ were executing the program, then you're lucky: you should be able to repeat whatever you just did and identify the inputs or series of inputs that caused the problem, giving you a way of testing that the program no longer fails once you've fixed the defect. If someone else was the one executing the program (for example, a user, or someone on your team), you better hope that they reported clear steps for reproducing the problem. When bug reports lack clear reproduction steps, bugs often can't be fixed <bettenburg08>.
|
||||
|
||||
If you can reproduce the problem, the next challenge is to *localize* the defect, trying to identify the cause of the failure in code. There are many different strategies for localizing defects. At the highest level, one can think of this process as a hypothesis testing activity <gilmore91>.
|
||||
If you can reproduce the problem, the next challenge is to *localize* the defect, trying to identify the cause of the failure in code. There are many different strategies for localizing defects. At the highest level, one can think of this process as a hypothesis testing activity<gilmore91>.
|
||||
|
||||
* Observe failure
|
||||
* Form hypothesis of cause of failure
|
||||
|
|
@ -15,16 +15,16 @@ If you can reproduce the problem, the next challenge is to *localize* the defect
|
|||
|
||||
The problems with the strategy above are numerous. First, what if you can't think of a possible cause? Second, what if your hypothesis is way off? You could spend _hours_ generating hypotheses that are completely off base, effectively analyzing all of your code before finding the defect.
|
||||
|
||||
Another strategy is working backwards <ko08>.
|
||||
Another strategy is working backwards<ko08>.
|
||||
|
||||
* Observe failure
|
||||
* Identify the line of code that caused the failing output
|
||||
* Identify the lines of code that caused the line of code in step 2 and any data used on the line in step 2
|
||||
* Repeat three recursively, analyzing all lines of code for defects along the chain of causality
|
||||
|
||||
The nice thing about this strategy is that you're _guaranteed_ to find the defect if you can accurately identify the causes of each line of code contributing to the failure. It still requires you to analyze each line of code and potentially execute to it in order to inspect what might be wrong, but it requires potentially less work than guessing. My dissertation work investigated how to automate this strategy, allowing you to simply click on the fault output and then immediately see all upstream causes of it <ko08>.
|
||||
The nice thing about this strategy is that you're _guaranteed_ to find the defect if you can accurately identify the causes of each line of code contributing to the failure. It still requires you to analyze each line of code and potentially execute to it in order to inspect what might be wrong, but it requires potentially less work than guessing. My dissertation work investigated how to automate this strategy, allowing you to simply click on the fault output and then immediately see all upstream causes of it<ko08>.
|
||||
|
||||
Yet another strategy called _delta debugging_ is to compare successful and failing executions of the program <zeller02>.
|
||||
Yet another strategy called _delta debugging_ is to compare successful and failing executions of the program<zeller02>.
|
||||
|
||||
* Identify a successful set of inputs
|
||||
* Identify a failing set of inputs
|
||||
|
|
@ -42,12 +42,12 @@ One of the simplest strategies is to work forward:
|
|||
|
||||
This strategy is easy to follow, but can take a _long_ time because there are so many instructions that can execute.
|
||||
|
||||
For particularly complex software, it can sometimes be necessary to debug with the help of teammates, helping to generate hypotheses, identify more effective search strategies, or rule out the influence of particular components in a bug <aranda09>.
|
||||
For particularly complex software, it can sometimes be necessary to debug with the help of teammates, helping to generate hypotheses, identify more effective search strategies, or rule out the influence of particular components in a bug<aranda09>.
|
||||
|
||||
Ultimately, all of these strategies are essentially search algorithms, seeking the events that occurred while a program executed with a particular set of inputs that caused its output to be incorrect. Because programs execution millions and potentially billions of instructions, these strategies are necessary to reduce the scope of your search. This is where debugging *tools* come in: if you can find a tool that supports an effective strategy, then your work to search through those millions and billions of instructions will be greatly accelerated. This might be a print statement, a breakpoint debugger, a performance profiler, or one of the many advanced debugging tools beginning to emerge from research.
|
||||
|
||||
# Fixing defects
|
||||
|
||||
Once you've found the defect, what do you do? It turns out that there are usually many ways to repair a defect. How professional developers fix defects depends a lot on the circumstances: if they're near a release, they may not even fix it if it's too risky; if there's no pressure, and the fix requires major changes, they may refactor or even redesign the program to prevent the failure <murphyhill13>. This can be a delicate, risky process: in one study of open source operating systems bug fixes, 27% of the incorrect fixes were made by developers who had never read the source code files they changed, suggesting that key to correct fixes is a deep comprehension of exactly how the defective code is intended to behave <yin11>.
|
||||
Once you've found the defect, what do you do? It turns out that there are usually many ways to repair a defect. How professional developers fix defects depends a lot on the circumstances: if they're near a release, they may not even fix it if it's too risky; if there's no pressure, and the fix requires major changes, they may refactor or even redesign the program to prevent the failure<murphyhill13>. This can be a delicate, risky process: in one study of open source operating systems bug fixes, 27% of the incorrect fixes were made by developers who had never read the source code files they changed, suggesting that key to correct fixes is a deep comprehension of exactly how the defective code is intended to behave<yin11>.
|
||||
|
||||
This risks suggest the importance of *impact analysis*, the activity of systematically and precisely analyzing the consequences of some proposed fix. This can involve analyzing dependencies that are affected by a bug fix, re-running manual and automated tests, and perhaps even running users tests to ensure that the way in which you fixed a bug does not inadvertently introduce problems with usability or workflow. Debugging is therefore like surgery: slow, methodical, purposeful, and risk-averse.
|
||||
|
|
@ -21,8 +21,8 @@ Note that in the division of responsibilities above, software engineers really a
|
|||
|
||||
There are other roles you might be thinking of that I haven't mentioned:
|
||||
|
||||
* *Engineering managers* exist in all roles when teams get to a certain size, helping to move information from between higher and lower parts of an organization. Even _engineering_ managers are primarily focused on organizing and prioritizing work, and not doing engineering (#kalliamvakou": "Kalliamvakou et al. 2018)</a>. Much of their time is also spent ensuring every engineer has what they need to be productive, while also managing coordination and interpersonal conflict between engineers.
|
||||
* *Data scientists*, although a new role, typically _facilitate_ decision making on the part of any of the roles above #begel": "(Begel & Zimmermann 2014)</a>. They might help engineers find bugs, marketers analyze data, track sales targets, mine support data, or inform design decisions. They're experts at using data to accelerate and improve the decisions made by the roles above.
|
||||
* *Engineering managers* exist in all roles when teams get to a certain size, helping to move information from between higher and lower parts of an organization. Even _engineering_ managers are primarily focused on organizing and prioritizing work, and not doing engineering <kalliamvakou17>. Much of their time is also spent ensuring every engineer has what they need to be productive, while also managing coordination and interpersonal conflict between engineers.
|
||||
* *Data scientists*, although a new role, typically _facilitate_ decision making on the part of any of the roles above <begel14>. They might help engineers find bugs, marketers analyze data, track sales targets, mine support data, or inform design decisions. They're experts at using data to accelerate and improve the decisions made by the roles above.
|
||||
* *Researchers*, also called user researchers, also help people in a software organization make decisions, but usually _product_ decisions, helping marketers, sales, and product managers decide what products to make and who would want them. In many cases, they can complement the work of data scientists, [providing qualitative work to triangulate quantitative data|https://www.linkedin.com/pulse/ux-research-analytics-yann-riche?trk=prof-post].
|
||||
* *Ethics and policy specialists*, who might come with backgrounds in law, policy, or social science, might shape terms of service, software licenses, algorithmic bias audits, privacy policy compliance, and processes for engaging with stakeholders affected by the software being engineered. Any company that works with data, especially those that work with data at large scales or in contexts with great potential for harm, hate, and abuse, needs significant expertise to anticipate and prevent harm from engineering and design decisions.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ When we think of productivity, we usually have a vague concept of a rate of work
|
|||
|
||||
Despite the challenge in defining productivity, there are numerous factors that affect productivity. For example, at the individual level, having the right tools can result in an order of magnitude difference in speed at accomplishing a task. One study I ran found that developers using the Eclipse IDE spent a third of their time just physically navigating between source files<ko05>. With the right navigation aids, developers could be writing code and fixing bugs 30% faster. In fact, some tools like Mylyn automatically bring relevant code to the developer rather than making them navigate to it, greatly increasing the speed which with developers can accomplish a task<kersten06>. Long gone are the days when developers should be using bare command lines and text editors to write code: IDEs can and do greatly increase productivity when used and configured with speed in mind.
|
||||
|
||||
Of course, individual productivity is about more than just tools. Studies of workplace productivity show that developers have highly fragmented days, interrupted by meetings, emails, coding, and non-work distractions<meyer17>. These interruptions are often viewed negatively from an individual perspective<northrup16>, but may be highly valuable from a team and organizational perspective. And then, productivity is not just about skills to manage time, but also many other skills that shape developer expertise, including skills in designing architectures, debugging, testing, programming languages, etc.<baltes18>. Hiring is therefore about far more than just how quickly and effectively someone can code<bartram16>.
|
||||
Of course, individual productivity is about more than just tools. Studies of workplace productivity show that developers have highly fragmented days, interrupted by meetings, emails, coding, and non-work distractions<meyer17>. These interruptions are often viewed negatively from an individual perspective<northrup16>, but may be highly valuable from a team and organizational perspective. And then, productivity is not just about skills to manage time, but also many other skills that shape developer expertise, including skills in designing architectures, debugging, testing, programming languages, etc.<baltes18> Hiring is therefore about far more than just how quickly and effectively someone can code<bartram16>.
|
||||
|
||||
That said, productivity is not just about individual developers. Because communication is a key part of team productivity, an individual's productivity is as much determined by their ability to collaborate and communicate with other developers. In a study spanning dozens of interviews with senior software engineers, Li et al. found that the majority of critical attributes for software engineering skill (productivity included) concerned their interpersonal skills, their communication skills, and their ability to be resourceful within their organization<li15>. Similarly, LaToza et al. found that the primary bottleneck in productivity was communication with teammates, primarily because waiting for replies was slower than just looking something up<latoza06>. Of course, looking something up has its own problems. While StackOverflow is an incredible resource for missing documentation<mamykina11>, it also is full of all kinds of misleading and incorrect information contributed by developers without sufficient expertise to answer questions<barua14>. Finally, because communication is such a critical part of retrieving information, adding more developers to a team has surprising effects. One study found that adding people to a team slowly enough to allow them to onboard effectively could reduce defects, but adding them too fast led to increases in defects<meneely11>.
|
||||
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ function min(a, b) {
|
|||
}
|
||||
`
|
||||
|
||||
These two new lines of code are essentially functional specifications that declare "_If either of those inputs is not an integer, the caller of this function is doing something wrong_". This is useful to declare, but assertions have a bunch of problems: if your program _can_ send a non-integer value to min, but you never test it in a way that does, you'll never see those alerts. This form of *dynamic verification* is therefore very limited, since it provides weaker guarantees about correctness. That said, a study of the use of assertions in a large database of GitHub projects shows that use of assertions _is_ related to fewer defects<casalnuovo15-2> (though note that I said "related": we have no evidence that assertions actually prevent defects. It may be possible that developers who use assertions are just better at avoiding defects.)
|
||||
These two new lines of code are essentially functional specifications that declare "_If either of those inputs is not an integer, the caller of this function is doing something wrong_". This is useful to declare, but assertions have a bunch of problems: if your program _can_ send a non-integer value to min, but you never test it in a way that does, you'll never see those alerts. This form of *dynamic verification* is therefore very limited, since it provides weaker guarantees about correctness. That said, a study of the use of assertions in a large database of GitHub projects shows that use of assertions _is_ related to fewer defects<casalnuovo15b> (though note that I said "related": we have no evidence that assertions actually prevent defects. It may be possible that developers who use assertions are just better at avoiding defects.)
|
||||
|
||||
Assertions are related to the broader category of *error handling* language features. Error handling includes assertions, but also programming language features like exceptions and exception handlers. Error handling is a form of specification in that _checking_ for errors usually entails explicitly specifying the conditions that determine an error. For example, in the code above, the condition `Number.isInteger(a)` specifies that the parameter `a` must be an integer. Other exception handling code such as the Java `throws` statement indicates the cases in which errors can occur and the corresponding `catch` statement indicates what is to done about errors. It is difficult to implement good exception handling that provides granular, clear ways of recovering from errors<chen09>. Evidence shows that modern developers are still exceptionally bad at designing for errors; one study found that errors are not designed for, few errors are tested for, and exception handling is often overly general, providing little ability for users to understand errors or for developers to debug them<ebert15>. These difficulties appear to be because it is difficult to imagine the vast range of errors that can occur<maxion00>.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue