Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Krishna Nareddy

dblp:124/2188 · DBLP profile ↗
← Back
2ranked-venue papers
0as first author
0since 2021 · last 2014
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Computer networks · 1Software engineering, systems software and programming languages · 1

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Computer architecture, parallel and distributed computing, and storage systems
1 paper
Storage systems · 100%

Topics — the 2 heaviest of 3, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Storage systems › storage architecture › block storage
cloud block storage
0.212014
Blizzard: Fast, Cloud-scale Block Storage for Cloud-oblivious Applications · NSDI 2014
Storage systems
virtual storage
0.112014
Blizzard: Fast, Cloud-scale Block Storage for Cloud-oblivious Applications · NSDI 2014
YearPublicationVenuePosition
2014 Blizzard: Fast, Cloud-scale Block Storage for Cloud-oblivious Applications
James W. Mickens, Ed Nightingale, Jeremy Elson, Darren Gehring, Asim Kadav, Vijay Chidambaram, Krishna Nareddy
NSDI9
2012 Facilitating enterprise software developer communication with CARES
abstract
Enterprise software developers must regularly communicate with one another to obtain information and coordinate changes to legacy code, but find it cumbersome and complicated to determine the most relevant and expedient person to contact. This becomes especially difficult when the relevant person has transferred teams or changed their personal contact information since contributing to the project. We conducted a year-long series of surveys and interviews to help us learn how, why, and how often software developers discover and communicate with one another. In response to what we saw, we designed, deployed, and evaluated a domain-specific, IDE-embedded, photo-oriented, communication tool. We overcame a significant challenge found in long-lived projects: uniquely identifying individuals years after their contributions to the project. After deploying our tool, iteratively refining it, and deploying it again on a company-wide scale, most users reported that it simplified the process of finding and reaching out to other developers and offered them a sense of community with their colleagues, even if those colleagues did not currently work on their team. The lessons learned from our study and tool development should apply to other large, multi-team, legacy software projects.
Anja Guzzi, Andrew Begel, Jessica K. Miller, Krishna Nareddy
ICSM4