Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

So what did we learn? There are 2 major take aways here:

  1. Keep Things Simple. If we can keep things as simple as possible (architecture, design, implementation) it will save a lot of hassle as we continue to develop. Instead of slamming some “future proof” framework into everyone’s face and forcing them to work with it, let’s start with the basics and continue to build, slowing introducing complexity as we require.

    Although, complexity is sometimes still required, for example, we are still not willing to give up not supporting multiple board packages and flight frames because those issues are immediate and it would be a poor choice to lock us into that type of design. So what we can do is have a really good team discussion, come up with solutions, and document those solutions so everyone knows what is going on.

  2. Incremental Development (aka Milestones). Building off the last point, if we keep things simple at first and gradually increase complexity with defined goals in mind, we will set up ourselves for success.

    Last time, we wanted to do everything at once, implement this complex (and quite frankly, unnecessary) framework immediately without having set the groundwork. Now, in industry where everyone is working 8 hours a day, this is possible, but for a design team, it is a stretch. To circumvent this, we would like to introduce milestones, which are a set of goals (that should be completed in order) meant to keep us on track and allow each completed milestone to be a fallback in case the next milestone gets iffy. Basically a “save your progress” button in a game.

    The first couple of milestones should not be too complex, but each milestone after that will introduce new features and concepts that may increase complexity but allow us to work off of something that we know is working (the previous milestone).

Introduction

WIP

Milestones

Milestone are something that is meant to keep us on track, prevent us from looking too far into the future, and give us a safety net to fall back on in case we royally mess up the next milestone and want to start again.

The idea here is that, as a team we will always be working on the next milestone. Once we can definitively say we have reached that milestone through testing and results, we will save that progress (either a tag on a commit or just branch off and never touch that branch). By doing this, we have our sights set on the next goal, giving us a clear sense of priority. Additionally, since we are “saving our progress” each milestone, we have something that we can fall back on or use as the groundwork for the next milestones since we know the previous one is confirmed to be working.

Currently, you can check out our milestones in this meeting minutes doc: Los Discussion 2 and the current progress on the Asana.

Design

WIP