WIP: Starting book proposal

book/proposal/proposal.md

@@ -0,0 +1,85 @@
+# Proposal for Design Think for Developers
+### By: Cory Gwin
+
+## Overview
+The agile manifesto states we should prefer customer collaboration over contract negotiation. As developers we often leave the customer collaboration to others in our organization, leaving only short user stories or issues to gather context. This leads to a number of problems including:
+
+- Downstream communication issues.
+- Misunderstood requirements.
+- Incorrect implementations.
+- Developer frustration.
+- Scope change or creep. 
+- Lost context over time.
+- Code that does not properly convey intent.
+- Unintended consequence of poorly modeled data.
+- Incorrect prioritization.
+
+Our workflows and structures create communication barriers we must break down in order to move our implementations closer to their domains. As developers, our goals should include moving code closer to the vocabulary of the domain. This requires understanding not only the problem being solved by a feature but also, more broadly an understanding of the field we are working in.
+
+Design thinking offers a toolset for gathering insight into the domain that can not only help engineers understand a user's problem more fundamentally, it can also offer byproducts such as:
+
+- Providing a better understanding of the entire domain.
+- A clearer path to a domain language.
+- Understanding problem nuance.
+- Gaining lessons learned of the user.
+- Clear prioritization of tasks.
+- Indetifying focused solutions.
+- Providing insight into how an implementation may evolve.
+
+Following the path of a team replacing a legacy application with a new application this book will explore tools that can be utilized to break down a domain and better communicate with domain experts. The book will introduce a number of design thinking exercises and explain how they can be applied in different scenarios to help agile developers craft clearer implementations.
+
+## What this book will cover:
+
+- Introduce the concept of design thinking.
+- Introduce the following design thinking methodologies from the perspective of the developer:
+	- Stakeholder mapping.
+	- Interviewing.
+	- Job shadowing.
+	- Rose Bud Thorn.
+	- Affinity Mapping.
+	- Experience diagramming.
+	- Importance/Difficulty matrix.
+	- Feature Voting.
+	- Creative matrixes.
+	- Technical prototyping.
+	- Story boarding UI's
+	- Stakeholder validation.
+- Introduce domain driven design concepts:
+	- Ubiquitous language.
+	- Context bounding.
+	- Domain events.
+- Outline effective tools for using design thinking to create ubiqoutous language, bounded contexts and domain events.
+- Outline rules for effective design thinking on agile teams.
+- Discuss ideas for bringing these methods into teams that are not familiar with design thinking.
+
+## Audience:
+This book is suitable for developers, managers, product manager, project managers, designers and anyone looking for methods to bring implementation closer to a domain.
+
+## Why is your book different?
+
+Design thinking books are often aimed at hard D design. This book will focus instead on using design thinking tools to create a different sort of outcome then is 
+
+
+## Why we should get excited about your topic:
+
+In the Cathedral and the Bazaar a number of important ideas where set forth related to working closer with our stakeholder:
+
+1. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
+1. Release early. Release often. And listen to your customers.
+1. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
+1. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
+1. The next best thing to having good ideas is recognizing good ideas from your users. 
+1. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
+1. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away. (Attributed to Antoine de Saint-Exupéry)
+1. To solve an interesting problem, start by finding a problem that is interesting to you.
+1. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
+
+Interestingly it contridicts itself pointing out a major issue with the way we develop software:
+
+1. Every good work of software starts by scratching a developer's personal itch.
+
+The implication here is that we do not know how to collaborate with our users in the same way as when we develop to solve our own problems. 
+
+This book makes a case that in order to solve problems we need to move the solution architects closer to the domain space. I believe in order to replicate the success of the open source movement in a broader way, we need to find ways to bring domain experts together with solution architects to create a new way of interacting. If one is to believe "We are as gods and might as well get good at it" then we need to focus on creating tools for others in a manner we ourselves would accept.
+
+