

Version control systems- why do we throw away so much data? - markm208
http://www.storytellersoftware.com

======
ap22213
Sorry - I want my version control system to be really, really good at being a
version control system, not at being a system to train other software
developers.

If you're an experienced developer, you should be able to pick up the static
source code and figure it out how it was engineered. If you're not as
experienced, you will learn through doing (not reading) and perhaps by working
side-by-side with a more experienced developer.

~~~
markm208
If you're a really good developer it is true you might not get a whole lot of
value from watching a playback. If you're a really good developer, though, it
is difficult to take the time and effort to teach all of your less experienced
team members about what you have learned while writing the code and to become
better programmers. These playbacks offer a relatively efficient way of
letting good developers teach once and have many developers learn.

If you're not a really good developer the question is how do you become one?
It is possible to learn the hard way by doing (like you suggested), but it is
painful. A playback is not just watching the code as it was developed but it
is listening to the developer explain _why_ they are doing things. My
hypothesis is this will make it easier for people to become better.

------
PaulHoule
I'm skeptical.

People have a limited cognitive capacity.

There really may be some learnings worth extracting from a long-term source
repository, but I think the cognitive overhead of looking at years of old
commits competes with being able to focus on the code in front of you.

------
amalag
I always wanted more dynamic commenting which some of the fisheye/github tools
already do. For instance being able to have a discussion about a line of code.
Not necessarily a code review, but more like explaining the code with pro/con
discussion if necessary. It is a bit troublesome to implement you always get
snapshots of code, so how to track lines. Plasticscm seemed interesting,
<http://www.plasticscm.com/gallery.aspx>, but I think they are aiming at the
Microsoft crowd, git is pretty firmly entrenched otherwise. Looks like they
tried to learn lessons from git and it's success.

------
sandfox
Can't help but feel this would produce an epicly poor signal to noise
ratio.... No one cares about someone's keystrokes as thats attacking the wrong
level in information hierarchy. Overall seems like a self indulgent academic
effort (nothing wrong with that per-se but the real world doesn't need it).
It's interesting to compare relative interest in this to Light table mentioned
a few days ago

~~~
markm208
All keystrokes are recorded but that is not the main form of documentation
created. A developer creates a playback of only the 'interesting parts' of the
code and provides a narrative about why they think it is interesting.

Then, when someone looks at some unfamiliar code they can search to see if
there is a 'story' about that bit of code. The code and the narrative playback
side by side. The noise can efficiently be bypassed.

------
jamesu
To me a playback system does not provide anything useful. Never have i found
it insightful watching people write code. In fact, most of the insightful
stuff comes not from the code itself, but the design and brainstorming process
that went on before even a single line was written.

~~~
markm208
That information can and should be recorded somewhere. The most natural place
(I think) for it to be recorded is along side the code where the insights are
applicable. The tool was built to allow developers to create these 'stories'.

------
exDM69
What I want: an undo graph, like vim's undo tree with merges. I want it
visualized and browsable, maybe with real time sharing. It needs powerful git-
like tools for squash, rebase, etc so you can make neat changesets to publish
for review.

------
senthilnayagam
if the playback component is available separately would like to use it with my
current version control system

