Lesson Outline

Planning and prototyping

We will be using Test Driven Development to develop the application. Although it is not strictly important that the TDD methodology specifically is used for the Agile software development process, I do strongly believe that any "serious" application (i.e. one that is going to exist for more than a short period of time) should include a testing strategy. The great thing about the TDD approach specifically is that it combines well with the Agile approach. Each user story becomes an E2E test, which serves as an entry point to building that feature, and it ensures we have good test coverage (with tests that are actually testing the key value we are trying to provide).

There is built-in scope for maneuverability within the Agile methodology, so it is not important that we know everything up front. However, there are some big guesses/assumptions that we have made in the initial meeting (a lot of these assumptions will probably just be rattling around in your brain). Although we could just formalise our user stories and start along our TDD path and adapt as we go, I prefer to create a quick throwaway prototype to confirm particular assumptions or to investigate whether something is possible. If there is nothing novel in the application, then I most likely wouldn't bother with a prototype.

The prototype

We won't create tests for this prototype or employ any particular project management strategy, we will just create it as quickly and roughly as we can to verify our assumptions. The key point is that this prototype will be thrown away. When we start the actual project, we will not use this as a base. You might reference it when you are properly implementing features in the application with tests and using the appropriate project management strategy, but we will not use it directly. We will not be following good practices in creating this quick prototype, and we certainly don't want to have that as the foundation for our application.

Prototypes are kind of dangerous because it is tempting to use them, but don't. I would also highly advise against showing the prototype to the client, unless you very seriously consider it. You can get what seems like an impressive chunk of work done in a rough prototype, and it can set some unrealistic expectations for the client if they don't understand why this thing is being thrown away and your are spending way more time just redoing what you already did. This isn't a weekend hackathon, we want to deliver high quality software to the client that will be stable and maintainable for a long time.

In addition to the notes I shared with you from the meeting in the last lesson, these are some additional notes I took on things to follow up on:

• Will Google Sheets support the functions required? Simple, but limited, but good to have data protected behind Google auth
• How will the external client interaction work (e.g. surveys/feedback)
• If clients are able to access the application externally (e.g. for survey beforehand/after) it adds complexity. This potentially adds authorisation functionality
• How will survey questions be updated?

Research

Following up from these questions I had, I started doing a bit of research. I began by investigating the Google Sheets API to see how feasible using that as a secure storage mechanism would be.