Congratulations 🎉! You have completed the first two modules!
Up to this point, you have access to 10.5 hours of software development video content, which by our estimation would translate to a maximum of 2 days of work in an office environment.
We ended up with 80 commits so far. As you may have gathered, we are fond of small, frequent commits that contain meaningful messages and provide accurate feedback. By taking a minute or two to author a good commit message not only we help out our future self to understand what our thoughts behind the committed changes were, but we also provide documentation for other team members that might get involved in the project. We can assure you that these long commit messages weren’t because the project is open source or a course; we take real pride by doing it in our everyday operations.
As we did throughout the case study, we recommend you to gather as much information as possible about the system you want/need to build before starting to code.
To do so in a Lean/Agile fashion, we recommend you to focus on delivering customer value in small iterations with fast feedback. In collaboration with other parts of the business, you can ask “what features the customers of the app would like to have?” and come up with lean solutions (help the business deliver simpler versions of the feature, learn and improve iteratively). In functional teams, you won’t have to *imply,* what the customers need instead learn through customer research exercises. Many developers don’t participate in customer research and consequently, feature planning. When you don’t participate, it’s much harder to come up with achievable features, estimations, and deadlines, so conflicts with the business might occur. As a proactive professional, you can join those activities and bring your expertise to help the nontechnical colleagues plan and deliver better software products. The collected information will then help us draft BDD-like scenarios and Use Cases.
In our case study, after we were confident of the primary customer experience features, we then dived into a more technical level and started outlining some use cases, expressing the scenarios at a component level.
Finally, we drew the modules we could think of at the time, based on the information we had, in an architecture diagram. This initial diagram is a rough scaffolding for the feature (we’re sure it’ll change over time), and it shouldn’t take more than 10 minutes to come up with. When not feeling confident about how to structure the feature yet, we can even skip this step and spike/play around with code first and come up with the design as we go (evolutionary design) by following our development process disciplines.
We followed a disciplined test-first approach as a mechanism for implementing and validating the Scenarios and Use Cases drafted in the requirements analysis phase. Such automated tests give us the confidence to move fast. We talked extensively about the value of a fast, reliable and expressive test suite brings to the team and the business that’s why we tried our best to make the tests as precise as possible and as decoupled as possible to ensure they only test the behavior of the system instead of depending on too many implementation details.
Moreover, perhaps you’ve noticed that we never named the architecture we ended up using. This was no accident from our part. We are interested in solving our specific challenges, instead of prematurely letting an architecture design pattern/template dictate where we’re going. Although we may end up with an architecture that matches a common design pattern, we are not interested in a specific architecture template; rather we are interested in solving the presented problem as efficiently as possible, taking care of the project’s short but long-term needs as well. We achieved that by using a clear separation of concerns, establishing proper boundaries and utilizing dependency inversion whenever necessary.
Finally, we also made sure to set up an automated Continuous Integration pipeline to improve the code integration (merge) process and feedback. Along with our initially proposed modular architecture and reliable tests, automation enables us to happily build modules, components, and features in parallel with other developers (independent development and deployment), maximizing the team output.
We’re now ready to start the next module!