SPA Conference session: The limits of tell don't ask

One-line description:What happens when we tell don't ask (TDA) all the way down?
Session format: Workshop (150 minutes) [read about the different session types]
Abstract:At some point surely everyone has been advised to refine their code with these three little words. What do they really mean, though?

We will define an extreme but very clear version of TDA and then attempt to use it in practice.

Participants will be presented with a code sample that makes use of Maps and does not adhere to TDA, and then tasked to make it so. Tests are included to assist verification of any changes made, but perhaps some of them are more useful than others.

Once we're happy that the codebase feels healthier (or at least TDA compliant), we'll try to add some more features. Participants will be invited to propose any particularly tricky ones to see how robust this approach is.

Towards the end of the session, we'll have a retrospective, in the hope of generalising some of the specific knowledge we've uncovered into more general principles.

Participants should leave this session feeling more confident in knowing when to apply TDA (and what to do when choosing not to).
Audience background:Programmers, especially those using OO languages, particularly those suffering in languages that love null and discourage lambda (i.e Java).
Benefits of participating:- An opportunity to explore the usefulness of TDA from first principles

hopefully leading to knowledge of:
- when to apply TDA
- when to stop applying TDA
- what to do at a boundary between the two
Materials provided:* Java source code in the form of a git repository
* A list of things to have installed on a laptop before turning up, viz:
- A JDK (anything from 6 to 8), and your preferred IDE.
Process:Light touch workshop - proposer will introduce the problem and then mostly leave participants to it, providing advice if necessary.

See timetable for more details.
Detailed timetable:00:00-00:20 (slides) Provide a rigorous definition of TDA. Introduce the existing code, provide background on how it came into being, and the world in which it runs.

00:20-00:25 Setup time! Participants pair up, grab the code and start hacking away at it.

00:25-02:10 Coding coding coding.

02:10-02:30 Retrospective.

We can probably share the retrospective outcomes.
History:Originally attempted as a "brown bag" at work with a less hands on approach, with TDA as a punchline (having worked through some alternative options), rather than the central theme.
1. James Byatt
2. 3.