“It brings more awareness to what people are doing. Sometimes people take it for granted that people are always interruptible. But there is actually a cost or a penalty when you interrupt someone. So, I think just the concept is good because it reminds people that there is sometimes a good time and a bad time to interrupt people. So, I think just from an awareness campaign, it’s valuable as well.” -Interview #20
Modern offices are dominated by creative workers. Programmers, designers, analysts, and engineers. These creative workers need long blocks of time to tackle the cognitively demanding activities that their jobs require. Unfortunately, they are constantly interrupted via chat messages, drop-in visitors and notifications, causing stress and sapping their productivity. According to UC Irvine professor Gloria Mark each of these interruptions require an average of 23 minutes and 15 seconds of recovery time.
To eliminate these distractions, we introduce FlowLight. FlowLight is an application that runs in the background on a user’s computer, automatically detecting when they are most focused and then changing their status accordingly. While the user is most active, FlowLight discourages remote interruptions by dynamically updating the user’s digital availability as well as discouraging local interruptions by changing the color status of the USB powered FlowLight Bulb
To evaluate the FlowLight's effectiveness we partnered with the University of Zurich to perform an 18 month field study with over 400 participants from 12 different countries. This study showed that the FlowLight eliminated 46% of interruptions, that 85% of participants continued using it after the two month trial, and that users appreciated its impact, claiming that "[the FlowLight caused] less interruptions both in person and via Skype. [resulting] in more focus and ability to finish work.
Reducing interruptions with the FlowLight is just the first step in our work to redefine the modern workplace. Our ultimate mission is this: to foster flow at work.
You Missed the Mother of All Demos
Gergő Balogh demonstrated his prototype, CodeMetropolis, which visualizes software systems as cities using the MineCraft engine (actually at SCAM, a co-located event). While this work is obviously influenced by earlier work on CodeCities, as well as the Source Viewer 3D project, it was a great example of how taking research one step further towards application really creates a wow factor. During this presentation everyone completely ignored their urgent emails and many formerly anti-social participants suddenly learned how to tweet! :)
You Missed srcML's Coming Out Party
For anyone working in software maintenance, srcML should be a familiar name. Since its inception over ten years ago it has had great success, being used in tens if not hundreds of projects (including several ABB projects), parsing millions and millions of LOCs, and even winning the ICPC's most influential paper this past year. Unfortunately, it is not as popular as it should be (some still insist in writing their own C or Java parser!), and so this year Jonathan Maletic and Michael Collard are getting serious about publicizing this well-tested project. Armed with their ~$800K infrastructure grant, they will be continually improving srcML over the next three years, working with the talented developer Michael Decker (full time on srcML!) to improve both the code and the community.
You Missed a Great TraceLab Talk
For those of you who haven't heard of TraceLab, it's "an experimental workbench for designing, constructing, and executing traceability experiments", such as evaluating feature location tools. While I was already familiar with TraceLab, I was very happy to hear the tone and content of their distinguished paper presentation. This talk was not only focused on the contributions of TraceLab, but on the need for increasing the reproducibility of results in software engineering. Their clear presentation of how difficult it currently is to reproduce feature location evaluation results, and how TraceLab can help fix this, gives me hope that I'll see better comparisons between evaluations in future work.
You Didn't Beat Michele Lanza in Football
ICSM has an annual tradition of hosting a football game. While this may seem odd for a research conference it's a great way to meet and interact with other researchers outside of coffee breaks and formal networking. More importantly, it's a ton of fun! For those of you that will join us next year, I've heard rumor that Michele Lanza's team has *never* lost an ICSM match, and this year was no exception. Will worthy challengers appear in 2014?
You Missed Meeting Many "Applied Innovators"
ICSM is a haven for what my friend Brian Robinson calls applied innovation. A working definition of applied innovation is work that is both interesting to academics (i.e., innovative, containing new ideas) and developers (i.e., it actually works and saves them time or money). While I've used Arie van Deursen (above) as an example, as he is a full professor at Delft and co-founder of two software spinoffs, I could have chosen many other participants at ICSM to make the same point (e.g., Jurgen Vinju and his group, creators of Rascal). The average participant at ICSM is, in my experience, more likely to have written working software that one can leverage, founded a company that is interacting with real customers, or applied their work on industrial source code. In my opinion, these applied innovators are exactly the type of people that are starting to bridge the large gap between research and practice, and I'm happy to have spent a week learning from them!
I hope you'll join us next year for SCAM or ICSM 2014.
I read a few articles and a book about what companies usually look for in a full-time candidate and was wondering whether I could fit the bill with the research project in place of the usual internship.
Recently I gave a guest lecture at NCSU for their software engineering course. One of the students I chatted with afterwards will be using this summer to work on his research thesis. This particular thesis work involves significant software development. Having just heard my talk on the importance of gaining software development experience prior to graduation he was wondering how to get the most out of his summer work. Here is my advice for both this student and any other student taking on summer research.
Open Source Your Work
Academia affords students great opportunities for opening up their work. While some specific DoD grants may have restrictions, most typical grants (e.g., NSF or industrial grants) allow or even encourage open sourcing your work. As a student, open sourcing your research code will have two major benefits. First, your code will become much cleaner. While many developers may have some bad habits they relapse into when committing to a closed repository, when they write code they know will be public the code is simply better. This will not only make for a more pleasant summer but will also help you as you begin to build a programmer's portfolio, or a set of publicly available projects that you have written. This second benefit of open sourcing your code, while not a new idea, this is a surprisingly simple way of gaining credibility with potential employees. For instance, two of the three interns that made it past the first round at ABB this year provided us with links to their publicly available code (note: the third provided a live demo of their work).
Collaborate if at all Possible
While generating a sizable project alone can certainly be impressive working with others is an important part of experience that many students are lacking. If at all possible, collaborate with other researchers and students on your code. This can be as simple as building upon an existing framework or a set of libraries that another student has generated. For instance, during my time at UDel summer undergrad students would often start from an existing tool (e.g., a search tool) and improve a single component of that tool (e.g., an abbreviation expander), investigating the effect of that component's improvement on the overall performance. This forced them to not only understand that existing component, but to also learn how that component interacted with the larger system. In most research labs there is ample opportunity to build upon others' work.
I have a planned my schedule for the summer and I notice that I could spare time in a day for projects/ work outside my thesis.
One point I want to warn against is losing focus. While a summer may seem like a long time, it is short. So short, in fact, that at ABB we communicate with upcoming interns for months in advance to hammer out a well-scoped idea so that when they join us for the summer they can have a chance at finishing something significant. Thus, I advise students to focus on a single project. When doing this, it is important that this project have a significant coding component, as this student has, so that, should he/she have any extra time they can continue to polish and refactor and improve this code base ad infinitum. If a student can finish the summer with a well-polished research prototype, with clean code and a working demo, in addition to an (eventually) completed thesis, that student will certainly have good job prospects.
Enjoy the Summer...
I hope this post helps you as you organize your summer. To summarize, I recommend open sourcing as much as you can, working with others whenever possible, and focusing on a single project. Following these guidelines I'm sure that you can have a polished, well-narrated demo video posted on youtube by the end of the summer (add a link in the comments!). For those of you pursing PhDs in software engineering that enjoy both research AND developing software tools, consider applying to our internship program next year.
Many software engineers (i.e., those that actually program on a daily basis) are unaware of the dedicated sub-field of software engineering researchers (like these from Microsoft) whose mission is to help make the daily grind of writing software better. While software engineering researchers have historically had limited practical impact, there are some notable companies and tools that were born out of software engineering research, and many brilliant, driven individual researchers who want to have impact. I hope that raising awareness of this research among software engineers will encourage more feedback to the software engineering research community, ultimately leading to more useful output.
To that end, I'm posting a short 3 minute video that provides a quick overview of a typical software engineering research project at ABB. I hope this video gives you a better sense of what we're working on, our balance between theoretical and practical impact, and what types of technologies we're investing in. If you're a software engineer we'd love to hear what you think about our research directions, how we could improve, or even just what problems are currently slowing you down. Feel free to leave comments or even contact me directly.
The ABB team is headed out to FSE next week! While we regularly work with academics (e.g., Jonathan Maletic, Michael Collard, Lori Pollock, Thomas Fritz, Kostadin Damevski, Emerson Murphy-Hill, Gregg Rothermel, Myra Cohen, Mary Jean Harrold...) it's often over Skype, and so we are looking forward to meeting the academic community in person. Please stop by our table, where we'll have ABB tumblers to give away, or grab us during a coffee break. We are always looking for next year's interns, possibilities for collaborations, sabbatical opportunities, or students graduating on the next cycle... so don't be shy!
One of the best ways you can get to know what our research group is up to is to visit us at one of our three tool demo sessions. They are:
10:30-11:45 Research Tool Demos, Session Chair: Brian Robinson, ABB Corporate Research
Automating Adaptive Maintenance Changes with SrcML and LINQ
Vinay Augustine,ABB Corporate Research
13:00-14:15 Research Tool Demos
Practical Change Impact Analysis Based on Static Program Slicing for Industrial Software Systems
Mithun Acharya and Brian Robinson, ABB Corporate Research
Sando: An Extensible Local Code Search Framework
David Shepherd, ABB, Inc.Kostadin Damevski, Virginia State University
Bartosz Ropski, Autodesk, Inc. Krakow, Poland, Thomas Fritz, University of Zurich
If you'd like to read about some of these projects ahead of time you can check out this video on Sando, visit the srcML.Net code repository, or review one of Mithun's papers on slicing industrial scale programs. See you soon!
Who says Microsoft's the only company interested in pushing the boundaries of software engineering forward? Not ABB, as I'm happy to announce the second running of the ABB Software Research Grant Program. These grants, ranging from 20K to 80K, are focused on several topic areas with at least two (shown below) being highly relevant for software engineering researchers. Researchers whose work has focused on mining software repositories or working with task context should consider applying!
Important Notes on ABB Software Research Grant Program
Note that this program is only in its second year of running and its organizers are still in the process of balancing ABB's interests with universities' interests. This means that the IP policy outlined for the grants may be too restrictive for some universities to participate, especially for US universities. If this is the case for you I recommend sending email to the provided contact on the grant page (so they can get a sense on whether this is a problem for many or only a few). Also note that this is my personal blog and all thoughts expressed here are my own and not representative of ABB's official policies.
David Shepherd leverages software engineering research to create useful additions to the IDE.