jeremy6d/outline.md

## outline.md

      
    Raw
  

              outline.md
            
          
    Growing Software from Seed

Inspiration


Jacques Fuentes' pushodoro.rb
The Agile Manifesto
the #noestimates debate (Neil Killick, Vasco Duarte)
Dan Milstein's No Deadlines For You! Software Dev Without Estimates, Specs or Other Lies blog post
Uncle Bob's "Rails is not your app" talk (Architecture: The Lost Years)

Philosophy

A methodology that subordinates delivering software artifacts to discovering and understanding the domain usefully

sees software chiefly as a learning tool for discovering business value and gathering business intelligence
what about "shipping it"?

what should be delivered is not obvious up front
best way to figure out options is to build experiments that help settle outstanding questions
better to deal with details of interface, persistence, etc. once you better understand the domain and the challenges (Uncle Bob)
learning should yield the prototypes, prototypes become the product, but business values drives all of it
delivery is one byproduct of discovery


keep focused on what it means to succeed

"pop the why stack" to arrive at testable hypotheses
keep communication and feedback as fluid as possible as the definition of success must change often


we report things we learn to decision makers

this should be what we are valued for!
programming gets us thinking creatively about problems, and this can be leveraged in other domains such as the business itself!


Goals of talk

Inspire developers to put business questions at the center of their work

Dan Milstein put it best: "The core idea is: put uncertainty and risk at the center of a conversation between the developers and the rest of the business (instead of everyone pretending such nasty things don’t exist). Doing so allows the entire business to tackle those genuine challenges together."
give developers concrete approaches for putting business value first
convince developers of their inherent business competency

Value your skills not simply as a technical knowledge base but also as a generalized problem solver
Offer these skills to those who make decisions so you can help collaborate at more and more levels of pure business problem-solving
Use development as a way to "bubble up" domain and business questions/problems (hypotheses) that will drive experimental software development
Focus on your communication skills more.  These are overlooked too fucking often.


helping developers more effectively prototype

stop thinking of MVP as simply the first version that gets to market
Perhaps better concept: smallest possible feature

it's an experiment on a unit of value
build the least amount of software to confirm
once you figure out how useful it is and what it needs more of, you can decide to iterate on the feature or create a new feature
it does not have to be ready for primetime, it just has to be useable enough to determine value (an admittedly squishy condition)


Questions


Can developers use their expertise in building software to give business intelligence to decision makers?
Can the business provide quick enough feedback?
Does the business want to learn about the domain?
How can we think of development as a process of experimenting with features to discover user value?
Can software really be built like this?

Use building a simple app from scratch as an example in talk
Process


capture your user story

interview stakeholder, figure out what their biggest challenge is
can you deliver something in IRB in a day that can help the situation?
sometimes this yields the insight that software is not needed at all
try to think what unknown domain information this feature would answer, i.e. "what question do we have about where to go next that this feature answers?"
you won't approach the development task with a learning-first mentality if you don't intend to learn anything from your work
keep an open mind!


write a single user scenario based on the acceptance criteria

first one should focus on happy path
focus on what it would mean to deliver the least-effort, most-useful value possible


open a simple container class

could be a simple container named after the app

this may be where all new features start getting coded


could be a new use case separate from the app class
best if it's one ruby file alone
Think of invoking it in IRB as your "first interface"


write a feature method on the class

implement the smallest possible feature (SPF)
name should describe first story
keep the internals as simple as possible

no persistence -- use arrays on the class
no models -- use openstruct / hashes
no fancy layouts -- use #inspect
no logging -- just do #puts instead


focus on determining where the right conceptual boundaries are for the constructs you're creating

what arguments one provides determine what data the user eventually provides
where it makes sense, make helper methods out of high-level concepts like validating data or saving
when appropriate, factor into roles or biz objs


use Hamburger Method to take smallest slice of a feature

list tech steps in process vertically
list horizontally for each step a variety of tech approaches

try to get a good mix of different complexity items
"skip it" can be an option if the feature can add value without it


take the smallest slice at first, keep pulling off more and more complex slices


verify with client / stakeholders

show them what you're doing
great moment to wireframe interfaces representing the states in the simple story


decide what the next most important problem is

if a completely new feature, go back to #1
if augmenting an existing feature

go back to #2 and describe a new scenario
take another slice of the hamburger
build just enough software to roughly implement


if behavior has become complicated enough to require testing, factor it out

first instance will probably be the use case object from the app object
think carefully about boundaries
use test cases to drive
focus on biz value at each layer


As you move forward, concentrate shared functionality in modules / mixins / DCI roles.