What's our problem?

Wow! You're working on that new feature?

  • Stack Overflow
  • Jira
  • GitHub
  • ServiceNow
  • Confluence
  • Company Intranet
  • MS Sharepoint
  • GitLab
  • Wiki
  • Email
  • IRC
  • Jenkins
  • Bamboo

How do we navigate these

And ... I found it

Where was I again?

Coffee break anyone?

Why does this matter?

Tools should support humans creative abilities, not obstruct or hinder them!
"Complexity in toolchains, processes and information hinders delivery of business value" - Kersten (2018)
"The usage of different tools forms part of a developers cognitive load" - Klemola & Rilling (2002)
"Problem solving requires significant amount of cognitive load" - Sweller 1998
"Limited working memory" - Miyake and Shah 1999
Context ultimately forms an important part of problem solving.

So how do we remmedy this cognitive stressing disconnect?

There's already a solution?

The ...

"Integrated"

Development Environment

The defacto home for a developer

Or is it?

"I'll google that"
- Unknown
IDEs are great at enriching our context.

Except ... they tend to focus on assisting the local context.

  • Version history
  • Code manipulation
  • Local references
  • etc

Source specific plugins are created to enhance context

however ...

  • their availability varies largely
  • their integration still creates fragmeneted retrieval
This problem is not unexplored ...

The IDE language issue ...

m IDEs * n languages

What did we do?

Re-use the principles of the Language Server Protocol - LSP

The design

graph LR A["IDE A"] AA["IDE B"] AB["IDE C"] B["Local Context
Daemon"] C(("Message
Bus")) D[("Documentation
Provider")] E[("Experts
Provider")] F[("Work Items
Provider")] X["Data sources"] subgraph Client A --> B; AA --> B; AB --> B; end subgraph Server B --> C; C -- 1 * --> D; C -- 1 * --> E; C -- 1 * --> F; end D --> X; E --> X; F --> X;

The protocol

						
							

								sequenceDiagram
									IDE->>+Daemon: Here's a context, answer this?

									Daemon->>+Message Bus: Send this request to\nto subscribed parties 

									Message Bus ->>+Providers: Here's a query

									Note right of Providers: Scatter query

									Daemon->>+IDE: Here's a collection identifier

									loop Poll
										IDE->>+Daemon: Any new results 
 for this identifier!
										Daemon->>+IDE: Paged Results, if any
									end								

									Note right of Providers: Empty result set 
 returned for lack of 
 understanding.

									Providers ->>+Message Bus: Return results to requester

									Message Bus ->>+Daemon: Here's a new result

									Note left of Message Bus: Add to collection

How do providers integrate?

								@Component
public class ExpertsProvider implements ExpertsQueryListener {
	@QueryHandler
	@Override
	public List on(AssociatedExpertsQuery query) {
		// TODO: compute values that need returning
		return new ArrayList<>();
	}
}
implementation 'org.axonframework:axon-spring-boot-starter:{axon-version}'
implementation 'com.dominiccobo.fyp:context-lsp-api:{api-version}'
implementation 'org.springframework.boot:spring-boot-starter-web:{spring-version}'

Demonstrated providers ...

Work Items Experts Documentation
GitHub ✔ ✔
GitLab ✔
Stack Overflow ✔

Does the approach introduce noticeable improvements?

Finding associated work items

Traditional

~40s

Our approach

~12s

Where do we go from here?

Language support conundrum ...

  • Axon focuses mainly on Java
  • Mining is usually done with scripting e.g. Python
  • GraalVM vs other polyglot approaches

Building out the responses ...

  • Improved, more flexible models for response
  • Improved filtering based on these models

Truly IDE-agnostic plugins...

  • Currently our data flow is mostly uni-directional
  • Expanding, a bi-directional ability could provide a better interaction platform.

Enabling greater metrics?

  • Looking at how developers truly use IDEs?

Questions?