Outline: Growing Software From Seed

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
  1. Value your skills not simply as a technical knowledge base but also as a generalized problem solver
  2. Offer these skills to those who make decisions so you can help collaborate at more and more levels of pure business problem-solving
  3. Use development as a way to "bubble up" domain and business questions/problems (hypotheses) that will drive experimental software development
  4. 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

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

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

Process

1. 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!
2. 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
3. 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"
4. 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
5. verify with client / stakeholders
   • show them what you're doing
   • great moment to wireframe interfaces representing the states in the simple story
6. 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.