ninlabs research

In 2013, inspired by GitHub’s octocat, I too wanted a mascot. It wasn’t something I exactly needed, but I thought would be interesting to have. I had come across a freelance designer, and decided to splurge and commission a design. The designer did good work, and I was happy with the results. Overall, it cost $200.

It is not unreasonable to speculate on what the future of software engineering will look like in the next 50 years. Software engineering is still a young discipline, with almost half a century since the coining of “software engineering”. Although we could claim some sort of success by simply pointing out the software underlying almost every facet of today’s world, that success has not been consistently repeatable nor teachable. As we become dependent on trillions of lines of code in the next 50 years, there is little comfort we still have no fundamental scientific understanding of how to create software.

We collected 1,316 days of Android developer history (average 11 weeks per developer) and we found 9,234 visits to stackoverflow, as well as 2,547 to developer.android.com, which hosts the official documentation for Android. We also analyzed the code examples that could be found in the Stack Overflow data dump and developer.android.com/guide.

But it is only so long before interruption finds a way to pierce my protective bubble. Like you, I am programmer, interrupted. Unfortunately, our understanding of interruption and remedies for them are not too far from homeopathic cures and bloodletting leeches.

Software development isn’t just about the code we write. It also spans the many situations, experiences, and new knowledge we encounter when we write code.

Traditional documentation requires a process where a few people write for many potential users (especially in the case of API documentation). The resulting documentation, more often than not just doesn’t cut it — There aren’t enough examples, details, or explanations.

Continuing my series of posts on cognitive neuroscience of memory. In this post, I first give an overview of attentive memory, some examples of attentive memory failures, and then end with some thoughts on how we might want to support attentive memory in our design of interfaces and tools.

Why are we still using ideas about memory from the 60’s to build programming tools?

Commonly, we need to perform a programming task that we do not know how to do or is not well-documented. Collectively, we perform these reoccurring programming tasks all the time, but only a few of us actively blog or contribute to sites like stackoverflow with answers. Thus, there are many remaining programming tasks, which are never documented for other teammates (on internal company blogs), don’t have any (good) official documentation, or discussion on blogs or Q&A; sites.

My best guess is that developer’s have a love/hate relationship with tabs. They’re great when they work, but many times they get cluttered, and developers have to go nuclear on them (Close All Tabs).

Continuing my last post on creating a basic history extension, let’s actually do something! Here, we dive into capturing events to code documents in Visual Studio and using that to create a help build a local code history for edits.

I will publishing a series of blog posts describing how to extend Visual Studio (VSX in particular) to maintain a history of code changes or actions within the IDE. The audience for these articles would most likely be researchers who are trying to understand how to do interesting developer analytics, intelligent work summaries, or build interesting work history visualizations, or next-gen developer tools.

The International Conference on Program Comprehension (ICPC 2011) was a charming affair, bringing together a diverse set of researchers from around the globe.

Tasks, for the purpose of this post, are assigned units of work. In practice, this may be a “story” or “defect” from an iteration in the agile world, or a “work item” in TFS land, or even a “feature” in trackers such as trac. There are many names given to tasks, but for the programmer, ultimately they are externally assigned responsibilities.

This is my second attempt at a software-related comic, but this time it is completely hand drawn.

VSX extensions/packages published and installed through the visual studio gallery will automatically check for updates and allow you to install the newest versions.

The default WPF expander is functional but is ugly. Many people have asked for simple examples for changing the look+feel, and most responses point to ripping the style template from Expression Blend and then customizing it. This is probably the third time I’ve needed to do this and each time looking at pages and pages of all that style code leaves me queasy.

Following a successful collaboration with Emerson Murphy-Hill on “How We Refactor, and How We Know It”, we decided on doing another empirical study, this time on Java generics. Turns out Christian Bird had similar interests, so we banded together for a new paper recently accepted for MSR’11.

Developers search the web for many questions they have about using apis. Developers can also use social media sites such as codesnipr, stackoverflow, refactormycode, or blog sites such as this one to provide answers or share knowledge about using apis. For example, this blog gets many hits each week from people looking on how to do programmatic search with the automation api in Visual Studio.

This winter break, I’ve written way too many papers. I’m keeping this list so I can keep track where I’m submitting or may be traveling to.

I have seen many papers justifying how much effort debugging or testing costs by saying something like:

Ever since google released a comic describing the design of the chrome browser, I’ve been fascinated by the idea using comics to communicate software design. There is something compelling about distilling down your concepts into a simple narrative. This is no easy task — here is my first attempt, an illustration describing how the concept of code history can change how programmers work: (see the pdf version here: [pdf])

Never forget where code came from again.

Display of search results in Visual Studio has been remarkably primitive despite numerous improvements in other areas. Eclipse, in contrast has added some compelling features such as clustered results grouped by packages and classes and the ability to prune results. Now, simplicity has its place, sometimes the simple list of text makes it easier to scan.

“Those who cannot remember the past are condemned to repeat it”

Viewing source code differences is something programmers do almost daily. Yet, how we view diffs is little changed since some of the first tools came out in the 1970s. Sure, techincal improvements have been made (accounting for whitespace, word-level diffs, providing more context, structural diffs).

Some quick code I cooked up to extract text from a collection of word/pdf:

If you want to log searches for code or perhaps wanted to provide a better UI for search results, then you need to listen to search events with a Visual Studio Addin/VSPackage.

When recording EMG signals, you want to be able to segment and associate those signals with certain events, e.g., the presentation of a stimuli.  Because one of my goals is to recognize subvocalized words, it is even more important to get tight segmentation.