Craft Day #2 Thoughts - characterize production code
4 views
Skip to first unread message
John Marx
Jan 24, 2011, 4:55:19 PM1/24/11
to gale-agile-l...@googlegroups.com
Thanks again to all those who helped out with the craft day, I thought it was great.
I am wondering if we could actually characterize real production code as a breakout session for the next craft day. I'll submit may favorite dead body of them all as example, "EnterProductHandler.java". My concerns are that it's too much like "real" work, and that it perhaps should be handled in the team room. However, I love the idea of exposing this monster to others, and getting 100% practical results. I'm not sure, any thoughts?
John
I am wondering if we could actually characterize real production code as a breakout session for the next craft day. I'll submit may favorite dead body of them all as example, "EnterProductHandler.java". My concerns are that it's too much like "real" work, and that it perhaps should be handled in the team room. However, I love the idea of exposing this monster to others, and getting 100% practical results. I'm not sure, any thoughts?
John
Erik Przekop
Jan 24, 2011, 5:10:24 PM1/24/11
to Gale Agile Learning Group
My main concern would be time. It may take so long for most of us to
grok that piece of code that the session is over before we write the
first test.
That said, Mike Seiler suggested something similar. We could work on
something that we could actually check in (i.e., break it down into
multiple stories, and some of them might be built by the end of the
day). I thought he was on crack, but he said he'd seen it work at a
conference when Uncle Bob did it with an open source project.
grok that piece of code that the session is over before we write the
first test.
That said, Mike Seiler suggested something similar. We could work on
something that we could actually check in (i.e., break it down into
multiple stories, and some of them might be built by the end of the
day). I thought he was on crack, but he said he'd seen it work at a
conference when Uncle Bob did it with an open source project.
Karen
Jan 24, 2011, 5:54:15 PM1/24/11
to Gale Agile Learning Group
I think it would be interesting to try. We you picturing the randori
format we used for the "calculator" exercise?
It could work, especially if we have a subject matter expert to lead
us through the code. That will keep us from spinning too long trying
to understand its purpose. I think it'd be best with a small-ish
group, 10 or so. Maybe have it side-by-side with a different dev
session, so we will have a smaller team experimenting with it.
Let's give it a try, and see if it turns out well. If so, we can
employ the same efforts on other pieces of code. If not, well it'd
still be an interesting exercise.
Karen
format we used for the "calculator" exercise?
It could work, especially if we have a subject matter expert to lead
us through the code. That will keep us from spinning too long trying
to understand its purpose. I think it'd be best with a small-ish
group, 10 or so. Maybe have it side-by-side with a different dev
session, so we will have a smaller team experimenting with it.
Let's give it a try, and see if it turns out well. If so, we can
employ the same efforts on other pieces of code. If not, well it'd
still be an interesting exercise.
Karen
Mike Seiler
Jan 24, 2011, 9:31:12 PM1/24/11
to Gale Agile Learning Group
Several options could work. A randoori with 4-8 people would work.
With more people we could split into small teams and split up the code
based on packages. Some direct business value would be harvested (not
bad). People would get to see code in the wild. True fear of code
modification in sticky areas. At Agile 2009 Uncle Bob did a session
using open source code. After the randori the code was peer reviewed
in an open space session on the pairing stations and then checked in.
Another option to get to more "real" would be to take pattern work
and build on it to yield real code but in a safe environment. Code
retreat style would work as long as someone in each pair had prior
knowledge. System Health pattern would allow for building probes.
Would explore issues with integration tests, System Health pattern,
and mocking. Or take affinity model and build on that (some
developers are interested in it but product teams will likely never
allow for incubation).
A third option is take some sexy topic and let people play in the
technology. I was going to suggest building next book apps. Code
retreat style. Each station has someone that has code that can handle
the data already (so the retreat would be build a NextBook interface
on a Gale code base you know). Dave Kaye and I will be having some
wiki and brown bag sessions in early february showing what NextBook
is, how it works, the framework, and two samples (Course Reader and
BIG).
Mike
With more people we could split into small teams and split up the code
based on packages. Some direct business value would be harvested (not
bad). People would get to see code in the wild. True fear of code
modification in sticky areas. At Agile 2009 Uncle Bob did a session
using open source code. After the randori the code was peer reviewed
in an open space session on the pairing stations and then checked in.
Another option to get to more "real" would be to take pattern work
and build on it to yield real code but in a safe environment. Code
retreat style would work as long as someone in each pair had prior
knowledge. System Health pattern would allow for building probes.
Would explore issues with integration tests, System Health pattern,
and mocking. Or take affinity model and build on that (some
developers are interested in it but product teams will likely never
allow for incubation).
A third option is take some sexy topic and let people play in the
technology. I was going to suggest building next book apps. Code
retreat style. Each station has someone that has code that can handle
the data already (so the retreat would be build a NextBook interface
on a Gale code base you know). Dave Kaye and I will be having some
wiki and brown bag sessions in early february showing what NextBook
is, how it works, the framework, and two samples (Course Reader and
BIG).
Mike
AimmeKeener
Jan 25, 2011, 5:43:57 AM1/25/11
to Gale Agile Learning Group
One of the items that we spoke about early on in the Craftsmanship
meetings was what we were trying to accomplish. One item was making
the lessons learned personal/relevant to each person. So, a real
world example from the team room would be great.
My only concern is getting people up to speed on the problem domain.
I am sure that every team room has areas or pieces of code that need
to be refactored. What about one refactoring per room or code base?
This might be another way to get more people involved since the team
gets to pick the topic and someone from the team room would need to
organize it.
meetings was what we were trying to accomplish. One item was making
the lessons learned personal/relevant to each person. So, a real
world example from the team room would be great.
My only concern is getting people up to speed on the problem domain.
I am sure that every team room has areas or pieces of code that need
to be refactored. What about one refactoring per room or code base?
This might be another way to get more people involved since the team
gets to pick the topic and someone from the team room would need to
organize it.
Peter Murasky
Jan 25, 2011, 7:20:54 AM1/25/11
to Gale Agile Learning Group
Craft day was awesome again!!!
One of the things I would like to see on craft day is to go through
the development life-cycle of a story.
For example writing a story test (JBehave), TDDing (including include
Mockito and maybe Jasmine) and selenium test. I was thinking a good
example could be a calculator porlet. We could split off into small
teams and each team could do an operator (+,-,*,/,^...). I think by
doing this, it will reinforce things developers should be doing for
stories.
One of the things I would like to see on craft day is to go through
the development life-cycle of a story.
For example writing a story test (JBehave), TDDing (including include
Mockito and maybe Jasmine) and selenium test. I was thinking a good
example could be a calculator porlet. We could split off into small
teams and each team could do an operator (+,-,*,/,^...). I think by
doing this, it will reinforce things developers should be doing for
stories.
John
Jan 25, 2011, 1:09:22 PM1/25/11
to Gale Agile Learning Group
I was thinking of doing in it in a randori style session, and I do
think it makes sense to keep the group small. I like Aimme's idea to
have each team room submit a piece of code that we could use. It's
likely then everyone would have some familiarity with one of the
chosen code bases to characterize.
think it makes sense to keep the group small. I like Aimme's idea to
have each team room submit a piece of code that we could use. It's
likely then everyone would have some familiarity with one of the
chosen code bases to characterize.
Reply all
Reply to author
Forward
0 new messages