Home
What’s new
The Toilet PaperExploring ScrumBut – An empirical study of Scrum anti-patterns (2016)
Every time I interview with a company and ask how they develop software, they’ll say something along the lines of “We use Scrum”, followed by a long list of deviations that decidedly make it not-Scrum. Eloranta, Koskimies, and Mikkonen describe 14 of these commonly used deviations and explain what makes them harmful.
The Toilet PaperCross-cultural web usability model (2017)
Different cultures consume information in different ways. This is why a website that’s designed for a western audience might not necessarily work well for an eastern audience, and vice versa. Alexander, Murray, and Thompson propose design guidelines that make it much easier to create and evaluate usable cross-cultural websites.
The Toilet PaperTeamwork quality and project success in software development: A survey of agile development teams (2016)
A team can be greater than the sum of its parts if its members work well together. Lindsjørn et al. conducted a survey with a large number of teams to understand how teamwork quality affects the ability of teams to deliver products effectively and efficiently, and the effect it has on work satisfaction and learning on the job.
The Toilet PaperHow do design decisions affect the distribution of software metrics? (2018)
Many organisations use static analysis tools to calculate metrics, which they then use to grade the quality of their software projects. This might not necessarily be a good approach however, as this study by Dósea, Sant’Anna, and da Silva shows that metrics don’t mean that much without proper context.
The Toilet PaperDo software engineers use autocompletion features differently than other developers? (2018)
Programmers in movies are often able to crank out working code with seemingly very little effort. In real life, programmers often rely on IDE features like autocompletion to produce correct code quickly. Amlekar et al. studied the differences in autocompletion usage between people who program for a living and people who do it “on the side”.
The Toilet PaperDoes it really matter to test-first or to test-last? (2017)
Test-driven development is a development practice that involves short, iterative cycles in which the programmer writes tests before adding new functionality or refactoring existing code. It’s commonly believed that writing tests first leads to higher-quality code and improved productivity. Fucci et al. put that belief to the test.
The Toilet PaperI’m leaving you, Travis: A continuous integration breakup story (2018)
Continuous integration services allow developers to automatically build and test their code with ease. Each of those services has its own strengths and weaknesses. Widder, Hilton, Kästner, and Vasilescu studied GitHub projects that no longer use Travis CI to understand what makes developers abandon a continuous integration service.
The Toilet PaperIntrusion of software robots into journalism (2017)
Good journalism is exciting, inspiring, and informative. But there’s also a lot of mundane reporting that simply isn’t very exciting to produce. One might be tempted to automate these tasks. Are articles written by robots robust enough to withstand the watchful eyes of journalists and the general public? Jung et al. think that may be the case!
The Toilet PaperMeasuring perceived usability: The CSUQ, SUS, and UMUX (2018)
The perceived usability of an application can be measured using short questionnaires. Most practitioners will be familiar with the SUS, but it’s far from the only one. Lewis compared two other questionnaires with acronym-y names, the CSUQ and UMUX, with SUS and discovered that they have a lot in common (which is a good thing).
The Toilet PaperThe pricey bill of technical debt: When and by whom will it be paid? (2017)
Trade-offs are made in software development every day. One of these is the choice between quick solutions and better – but also more expensive – solutions. Bad choices may result in technical debt, which leads to more costs down the road. Besker, Martini, and Bosch report on the height of these costs and their causes.
The Toilet PaperOn the usage of Pythonic idioms (2018)
Design patterns are conventions that make it easier to communicate and reason about commonly occurring problems and their solutions. The Python community takes the idea of using conventions one step further, and argues that code should be “Pythonic”. Alexandru et al. explore what that means in practice.
The Toilet PaperEmpirical study on the relationship between developer’s working habits and efficiency (2018)
There’s plenty of evidence that suggests that working long or late hours is neither good for you nor your productivity, but that doesn’t stop most developers from doing it anyway. Rodriguez, Tanaka, and Kamei analysed the actual working habits of software developers and the effect that these habits have on their efficiency.
The Toilet PaperDo programmers work at night or during the weekend? (2018)
It’s often thought that programmers have very irregular working hours compared to those of the general population. Claes, Mäntylä, Kuutila, and Adams analysed commit data from 86 large software projects and found that this isn’t actually the case – for most programmers.
The Toilet PaperJIT feedback – what experienced developers like about static analysis (2018)
Running static analysis tools in an integrated development environment is like having a peer next to you that continuously reviews and criticises your code. Tymchuk, Ghafari, and Nierstrasz studied whether and why developers think these tools are helpful.
The Toilet PaperMicro-clones in evolving software (2018)
Codebases often contain code clones: code fragments that are very similar or even completely identical to each other. Until now, only larger clones have been studied thoroughly – not much is known about micro-clones, which are only 1–4 lines of code. Mondai, Roy, and Schneider show that these micro-clones are quite widespread.
The Toilet PaperDeep code comment generation (2018)
Machine learning models can be used to find relevant code snippets for a natural language description. Does that mean we can also do the opposite and predict natural language descriptions for code snippets that lack comments? Hu, Li, Xia, Lo, and Jin designed a model that does just that.