Legacy Code TDD with Mob Programming - Revision history

Clarman at 16:23, 29 June 2015

2015-06-29T16:23:01Z

Clarman at 16:22, 29 June 2015

2015-06-29T16:22:17Z

Clarman at 16:19, 29 June 2015

2015-06-29T16:19:19Z

Clarman at 16:18, 29 June 2015

2015-06-29T16:18:08Z

Clarman at 16:17, 29 June 2015

2015-06-29T16:17:24Z

Clarman at 16:17, 29 June 2015

2015-06-29T16:17:10Z

Clarman at 16:16, 29 June 2015

2015-06-29T16:16:47Z

Clarman at 04:10, 22 June 2015

2015-06-22T04:10:57Z

Clarman at 04:07, 22 June 2015

2015-06-22T04:07:51Z

Clarman: Created page with "== Overview == 1-2 days (for most systems, if this is the first agile arch doc workshop, 2 days is more realistic; later workshops can be 1 day) In this workshop, people app..."

2015-06-22T03:55:12Z

Created page with "== Overview == 1-2 days (for most systems, if this is the first agile arch doc workshop, 2 days is more realistic; later workshops can be 1 day) In this workshop, people app..."

New page

== Overview ==
1-2 days (for most systems, if this is the first agile arch doc workshop, 2 days is more realistic; later workshops can be 1 day)

In this workshop, people apply agile modeling and documentation techniques to document their software architecture. We take an "N+1" view-model approach, creating the logical view, deployment view, and more, and also write "technical memos." This is done "at the walls" in a small teams, sketching on vast whiteboard spaces, in a wiki, and with video capture of Q&A sessions for different architectural views and technical memos. As will be seen, not only is the architecture documentation created, but the workshop is also a context for ''learning'' about the architecture. For example, different sub-groups are working in parallel on different walls, one doing the logical view, one doing the deployment view, and so forth. We practice "show and tell" visiting other walls, and in this way learn from each other. Another example: we do pair writing and pair review of different technical memos, and learn from each other.

The output is an N+1 view model of the architecture combined with technical memos, captured in wiki pages, videos of Q&A sessions related to views and technical memos, and perhaps equally important, learning and an increased shared understanding of the architecture that has been documented.

This workshop can also be combined with the definition and organization of a self-study plus Q&A mentoring system for new hires to your company, to speed and improve the architectural knowledge of your staff.

== Methods of Education ==
primarily workshop coaching "at the walls"; some minor discussion.

== Audience ==
* this can only be for one product group.
* attendees should be able to contribute to documenting the architecture (i.e., they know something in detail about it, and some people at the workshop have real breadth and/or depth of understanding)
* but not all attendees need be experts -- a mixture of knowledge-levels is useful so that some people are learning more about the existing architecture (i.e., use the agile doc workshop to increase learning in the group)

== Level ==
This is an immersive workshop. No prior knowledge is absolutely required.

== Prerequisites ==
There are not strict prerequisites. However, people who know basic UML notation or who have attended any one of the follow courses will be better prepared to take full advantage of this workshop:

* [[Applying UML and Patterns: Hands-on Mastery of OOA/D, Agile Modeling, & Patterns -- & with TDD introduction]]

== Objectives ==
This is not a course per se, but a product-specific workshop to document the existing architecture. Nevertheless, in the context of the workshop, participants will learn more about visual modeling, and new ways to model and document.

== Maximum Participants ==
30 people

== Environment - Room, Tools, Texts ==
* If this is a large group (e.g., more than 10 people), we will need an especially large modeling room with truly *massive* whiteboard areas, in which each group uses 2 of the 4 walls.

* lots of fresh black whiteboard marker pens

* whiteboard erasers

* 1 package of "flipchart" paper

* 1 roll of "painters tape" or "masking tape"

* 1-2 computer projectors and 1-2 project screens (or big white walls we can project on to)

* wiki, with all participants having access

* 1-2 video cameras with tripod, storage in each for at least 5 hours of video

* Also, read and organize for this: [[Course Environment - Workshop Style7]]

@@ Line 11: / Line 11: @@
-While working on your real code (this is not a toy exercise; we work on improving your existing production code), I coach and show the team
+While working on your real code (this is not a toy exercise; we work on improving your existing production code), I coach and show the team:
 * how to bring the legacy code under test so that they can test units in isolation
 * how apply TDD to legacy code
@@ Line 20: / Line 20: @@
-The style of learning is '''mob programming''', a great way to intensively increase the learning about the code within a team. How does mob programming work? There is computer projector and screen on which the code is displayed. There is only 1 computer. Each team member drives the computer for a short period -- usually 12 minutes. Then it rotates to the next person. Constantly during this period I am guiding the team in how to do legacy-code TDD.
+The style of learning is '''mob programming''', a great way to intensively increase the learning about the code within a team. How does mob programming work? There is computer projector and screen on which the code is displayed. There is only 1 computer. Each team member drives the computer for a short period -- usually 12 minutes. Then it rotates to the next person. Constantly during this period I am guiding the team in how to do legacy-code TDD, refactor to clean code, and improve/simplify their designs.
 == Environment - Room, Tools, Texts ==
 [[Coaching Environment - TDD]]

← Older revision		Revision as of 16:22, 29 June 2015
Line 11:		Line 11:


−	While working on your real code (this is not a toy exercise; we work on improving your existing production code), I coach and show the team how to bring the legacy code under test so that they can test units in isolation~~, and~~ apply TDD to legacy code. Developers find it tough to see how to do this without someone experienced directly coaching them, and ~~they~~ invariably say that this coaching is extremely worthwhile.	+	While working on your real code (this is not a toy exercise; we work on improving your existing production code), I coach and show the team
		+	* how to bring the legacy code under test so that they can test units in isolation
		+	* how apply TDD to legacy code
		+	* how to create and evolve to clean code
		+	* how to improve the larger design so the system is simpler
		+
		+	Developers find it tough to see how to do this without someone experienced directly coaching them, and developers find it tough to actually change their moment-to-moment coding behavior without this in-depth experience. They invariably say that this coaching is extremely worthwhile.

← Older revision		Revision as of 16:19, 29 June 2015
Line 11:		Line 11:


−	While working on your real code, I coach and show the team how to bring the legacy code under test so that they can test units in isolation, and apply TDD to legacy code. Developers find it tough to see how to do this without someone experienced directly coaching them, and they invariably say that this coaching is extremely worthwhile.	+	While working on your real code (this is not a toy exercise; we work on improving your existing production code), I coach and show the team how to bring the legacy code under test so that they can test units in isolation, and apply TDD to legacy code. Developers find it tough to see how to do this without someone experienced directly coaching them, and they invariably say that this coaching is extremely worthwhile.

← Older revision		Revision as of 16:18, 29 June 2015
Line 5:		Line 5:


−	Your Problem: A ton of legacy code (in C, Ruby, C++, Java, JavaScript, ...) without solid automated tests, and with lots of entanglements and dependencies. You want to break these dependencies, transform it to clean code, unit test the old code ("bring it under test") and also do TDD in the context of this legacy code, improve the larger design/architecture, and establish changed/better developer behaviors while coding.	+	Your Problem: A ton of messy legacy code (in C, Ruby, C++, Java, JavaScript, ...) without solid automated tests, and with lots of entanglements and dependencies and complex design. You want to break these dependencies, transform it to clean code, unit test the old code ("bring it under test") and also do TDD in the context of this legacy code, improve the larger design/architecture, and establish changed/better developer behaviors while coding.

@@ Line 9: / Line 9: @@
 Note that Legacy-code TDD is not the same process as new-code TDD, though there are similarities.
 While working on your real code, I coach and show the team how to bring the legacy code under test so that they can test units in isolation, and apply TDD to legacy code. Developers find it tough to see how to do this without someone experienced directly coaching them, and they invariably say that this coaching is extremely worthwhile.
 The style of learning is '''mob programming''', a great way to intensively increase the learning about the code within a team. How does mob programming work? There is computer projector and screen on which the code is displayed. There is only 1 computer. Each team member drives the computer for a short period -- usually 12 minutes. Then it rotates to the next person. Constantly during this period I am guiding the team in how to do legacy-code TDD.
 == Environment - Room, Tools, Texts ==
 [[Coaching Environment - TDD]]

@@ Line 1: / Line 1: @@
 == Overview ==
-Either
+Either:
 * 5 days with one team (of about 7 people, though less people is OK) for thorough and 'sticky' learning, behavior changes, and improvement of your code and designs
 * 2.5 days with one team, and then 2.5 days with another team, for an abbreviated version
 Your Problem: A ton of legacy code (in C, Ruby, C++, Java, JavaScript, ...) without solid automated tests, and with lots of entanglements and dependencies. You want to break these dependencies, transform it to clean code, unit test the old code ("bring it under test") and also do TDD in the context of this legacy code, improve the larger design/architecture, and establish changed/better developer behaviors while coding.
 Note that Legacy-code TDD is not the same process as new-code TDD, though there are similarities.

← Older revision		Revision as of 04:10, 22 June 2015
Line 14:		Line 14:

	== Environment - Room, Tools, Texts ==		== Environment - Room, Tools, Texts ==
		+	[[Coaching Environment - TDD]]

@@ Line 1: / Line 1: @@
 == Overview ==
--2 days (for most systems, if this is the first agile arch doc workshop, 2 days is more realistic; later workshops can be 1 day)
+.5 days with 1 team of about 7 people (though less people is OK). I usually do this with 2 teams over 5 days
-In this workshop, people apply agile modeling and documentation techniques to document their software architecture. We take an "N+1" view-model approach, creating the logical view, deployment view, and more, and also write "technical memos." This is done "at the walls" in a small teams, sketching on vast whiteboard spaces, in a wiki, and with video capture of Q&A sessions for different architectural views and technical memos. As will be seen, not only is the architecture documentation created, but the workshop is also a context for ''learning'' about the architecture. For example, different sub-groups are working in parallel on different walls, one doing the logical view, one doing the deployment view, and so forth. We practice "show and tell" visiting other walls, and in this way learn from each other. Another example: we do pair writing and pair review of different technical memos, and learn from each other.
+Your Problem: A ton of legacy code without solid automated tests, and with lots of entanglements and dependencies. You want to break these dependencies, unit test the old code ("bring it under test") and also do TDD in the context of this legacy code.
-The output is an N+1 view model of the architecture combined with technical memos, captured in wiki pages, videos of Q&A sessions related to views and technical memos, and perhaps equally important, learning and an increased shared understanding of the architecture that has been documented.
+While working on your real code, I coach and show the team how to bring the legacy code under test so that they can test units in isolation, and apply TDD to legacy code. Developers find it tough to see how to do this without someone experienced directly coaching them, and they invariably say that this coaching is extremely worthwhile.
 == Environment - Room, Tools, Texts ==