In the past year or so I have answered questions or had conversations with developers about the steps I take or path I follow from start to finish when writing an application. I tend to dodge this question by essentially saying that it depends on way too many things to answer.  However, I have realized that this is a copout. If someone asked me how I got home from work, I would not tell them it depends on way too many factors to answer definitively. Rather, I would describe to them what you might call my default path, and it would be understood that hundreds of “what if” situations could cause me to alter my path. What if you are in a hurry, what if traffic is backed up, what if it is snowing, what if it rained all day and flooded the river bottoms by your house, what if, what if, what if? 

 

So I decided I would list my default path here regardless of the type of application, with no preconceived notions, and I’ll try my best to not say “if” or “it depends.”

  • Take rough notes as I have high-level discussions about the business and the software the stakeholders are dreaming about for that business.
  • Explain up front my expectations for the design and implementation of the software (Stakeholders constantly design with me, standardized language, evolving software, building simplest thing that works with solid design that allows easier change, upgrades, and maintenance).
  • Get a high-level summary from everyone involved regarding accessibility, maintenance, support, performance, environmental constraints, etc as much as deemed needed. Still at a rather high level. Just write something down as a bare minimum.
  • If the system replaces an existing application or manual process, observe the users.
  • Identify subsystems as discussions about the overall system get more detailed.
  • Work with everyone involved to define the simplest subsystems that could be built that provide value. This results in requirements and the identification of  bells and whistles, requirement priorities, etc.
  • Flesh out the requirements for the simplest-thing-we-could-build-that-provides-value by producing use cases, user stories, scenarios, pictures on whiteboards, napkin drawings, etc.
  • At every point after the initial conversation update a domain model of the objects involved and make sure it is available to everyone.
  • Identify the most interesting, difficult, and/or risky business logic.
  • Start producing the software, letting the user stories and testing drive the design of our objects and their responsibilities
  • Observe users using software to see how the software is actually getting used and then make necessary adjustments.
  • Create documentation for the most interesting, difficult, or risky business logic and how the domain objects and services will complete a need. Make sure to note any design decisions that involved any lengthy discussion or back and forth comparisons.
  • Address storage concerns for any data that requires permanent storage, and dynamic data needed for easy configuration
  • Refactor anything that smells (really done along the way as tests are written and run)
  • Rinse and Repeat