New article to appear in ICSM Tool 2013! Introducing… Collaboratorium

August 2, 2013 at 7:24 PM

Eleni Stroulia, Ken Bauer, Isaac Matichuk and I have submitted a paper to ICSM Tool where we give a deeper insight into Collaboratorium, a tool we developed to understand how students collaborate during a software engineering project.

The article will appear in ICSM Tool 2013, this September, in Eindhoven (Netherlands).

Title: Interactive Exploration of the Collaborative Software-Development Data

Abstract: Modern collaborative software-development tools generate a rich data record, over the lifecycle of the project, which can be analyzed to provide team members and managers with insights into the performance and contributions of individual members and the overall team dynamic. This data can be analyzed from different perspectives, sliced and diced across different dimensions, and visualized in different ways. Frequently the most useful analysis depends on the actual data, which makes the design of single authoritative visualization a challenge. In this paper we describe an analysis and visualization tool that supports the flexible run-time mapping of such a data record to a number of alternative visualizations. We have used our framework to analyze and gain an understanding of how individuals work within their teams and how teams differ in their work on these term projects.

Demo video:

Full preprint coming soon.

Collaboratorium

Collaboratorium

This work was funded by NSERC, AITF (Alberta Innovates Technology Futures) and IBM.

Things every software engineer should know #13

June 28, 2013 at 8:19 PM

Stand up in front of the team and say “I will do this”, and do it. More importantly, let the team know how far from *done* a task is. Never “don’t know”.

Things every software engineer should know #12

May 29, 2013 at 10:06 PM

Don’t expect documented code. Most likely there won’t be any documentation.

More importantly, write code that doesn’t need documentation.

New article to appear in CSEE&T 2013!

April 11, 2013 at 9:20 PM

Eleni Stroulia and I have submitted a paper on a study that we conducted last year, where students used IBM Jazz to collaborate while developing their projects. We studied their behavior and how our visualization toolkit is useful in enabling inferences about the team’s collaboration.

The paper will appear in CSEE&T 2013, this May, in San Francisco.

Title: Understanding Individual Contribution and Collaboration in Student Software Teams

Abstract: Software development is an inherently team-based activity, and many software-engineering courses are structured around team projects, in order to provide students with an authentic learning experience. The collaborative-development tools through which student developers define, share and manage their tasks generate a detailed record in the process. Albeit not designed for this purpose, this record can provide the instructor with insights into the students’ work, the team’s progress over time, and the individual team-member’s contributions. In this paper, we describe an analysis and visualization toolkit that enables instructors to interactively explore the trace of the team’s collaborative work, to better understand the team dynamics, and the tasks of the individual team developers. We also discuss our grounded-theory analysis of one team’s work, based on their email exchanges, questionnaires and interviews. Our analyses suggest that the inferences supported by our toolkit are congruent with the developers’ feedback, while there are some discrepancies with the reflections of the team as a whole.

We are thankful to Isaac Matichuk who had a major contribution in the development of the visualization component of our system. This work was funded by NSERC, AITF (Alberta Innovates
Technology Futures) and IBM.

Full Preprint Available here

Things every software engineer should know #11

March 11, 2013 at 10:35 AM

A good programmer will should always be able to predict the output before running the code.

Don’t program by trial-and-error, kids.

At least they're pair programming.

At least they’re pair programming.

Things every software engineer should know #10

February 13, 2013 at 8:26 PM

I would advise students to pay more attention to the fundamental ideas rather than the latest technology. The technology will be out-of-date before they graduate. Fundamental ideas never get out of date. However, what worries me about what I just said is that some people would think of Turing machines and Goedel’s theorem as fundamentals. I think those things are fundamental but they are also nearly irrelevant. I think there are fundamental design principles, for example structured programming principles, the good ideas in “Object Oriented” programming, etc.

~ ACM Fellow David Parnas

Books I’m reading right now.. #2

February 10, 2013 at 10:09 PM

Last time I posted about books I mentioned a few books (not related to computer science) that I was flipping through. I started 2013, however, with a few software engineering/programming books just for fun:

1 – Growing Object-Oriented Software Guided by Tests

2 – Professional Application Lifecycle Management with Visual Studio 2012

3 – Patterns of Enterprise Application Architecture

4 – Pro C# 5.0 and the .NET 4.5 Framework

They’ll probably keep me entertained for a while :)

Where I am right now

November 12, 2012 at 12:43 AM

credits

Things every software engineer should know #9

October 29, 2012 at 11:14 AM

Test the code.

This is outdated:

This is acceptable:

“Testing” is the new “compiling”.

(image source:http://xkcd.com/303/)

The Ten Commandments of Egoless Programming

October 27, 2012 at 9:06 PM

Today I came across this great post from John Allspaw on his blog on what makes for a good senior engineer.

One of the parts I liked the most was the ten commandments of egoless programming, which all engineers should know and follow:

  1. Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry. We can, and should, learn, laugh, and move on.
  2. You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.
  3. No matter how much “karate” you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.
  4. Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
  5. Treat people who know less than you with respect, deference, and patience. Non-technical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.
  6. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, rather than some serious inconvenience to be fought.
  7. The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect so if you want respect in an egoless environment, cultivate knowledge.
  8. Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you are right, don’t take revenge or say “I told you so.” Never make your dearly departed idea a martyr or rallying cry.
  9. Don’t be “the coder in the corner.” Don’t be the person in the dark office emerging only for soda. The coder in the corner is out of sight, out of touch, and out of control. This person has no voice in an open, collaborative environment. Get involved in conversations, and be a participant in your office community.
  10. Critique code instead of people: be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.

It’s definitely a must-read for all software engineers. Go read it.