Introduction
Discovery is the first phase of any successful project, as it lays the groundwork for planning and execution. In some cases, discovery may involve considering tools and technologies to use in a fresh project - while in others this time will be spent studying existing codebases and documentation. In either situation, the goal is to become more comfortable with the project and its requirements.
There is no universal approach to discovery, as each project is unique. However, in all cases the aim of this time is to build a mental model of the problem at hand. When we feel lost or overwhelmed by code, it is almost always because our mental model is incomplete. A small application is easy to keep in mind, but as apps grow in size and complexity it can become difficult or even impossible to hold the entire thing in our heads at once. A senior developer is comfortable with this feeling of uncertainty, and knows how to work through it.
Asking Questions
During discovery it is important to ask questions and engage in dialogue with our client or team. Expecting our client to provide all the answers is a common mistake that can lead to frustration and wasted time. If our client had all the fine details, they would not need to hire us! Instead, we should be prepared to ask questions and seek clarification when needed. This is a skill that takes time to develop, but it is essential for success in the tech industry.
Here are some useful questions to consider during discovery:
- What is the core purpose of the project?
- Who is the target audience?
- Where are the limits of the project?
- How much time do we have?
- What are the client’s expectations?
- Are there limitations on the tools or technologies we can use?
- Who will be working on the project?
- How will the project be managed?
Notice that few of these questions involve hard skills such as programming languages or frameworks. Instead, they focus on the bigger picture. This is because the goal of discovery is to understand the problem, not to solve it. Once we have a clear understanding of the problem, we can begin to think about solutions.
Legacy Code
In some cases, we may be asked to work on an existing codebase. This can be intimidating, especially if the code is poorly written or undocumented. However, it is important to remember that all code is written by humans, and humans make mistakes, especially when under pressure. A mature and calm approach to a legacy codebase involves asking questions and seeking clarification. It is also important to remember that the codebase is not the problem - it is the solution to the problem. We may be able to engineer a cleaner or more efficient replacement, but we should think carefully about attempting to fix something that is not broken.
In most cases working with legacy code is a matter of adding new features or fixing bugs. In these situations, it is important to understand the existing codebase and how it works. This is a good opportunity to think of additional improvements or feature suggestions that our client may be interested in.
Concept Demo
In cases where we will be expected to field unfamiliar technologies, it can be useful to practice with these tools by creating a small demo project. This is especially useful when working with a team, as it allows us to become familiar with the tools and to identify any potential issues before the project begins. For example, if the project requirements mention Tailwind and Svelte, a day spent creating a small demo project using one or more of these tools can be a good investment of time. In the event that there is a compatibility issue, we can raise this with our client and discuss alternatives before the project begins.
Tools and Technologies
The project discovery phase is also the perfect time to evaluate the tools and technologies that will be best suited for your project. This involves examining the specific project requirements and constraints to determine the best fit. Remember, the latest or most popular technology may not necessarily be the best choice for your particular project. It is essential to consider factors like the team’s experience, scalability needs, maintenance considerations, and client preferences.
Here are some key aspects to consider while evaluating tools and technologies:
- Technical Fit: Does the technology meet the technical requirements of the project?
- Skillset: Does the team have the necessary skills to work with the chosen technology?
- Scalability: Can the technology scale as per the expected growth of the project?
- Long-term Support: Will the technology continue to be supported in the long-term?
- Performance: How does the technology perform under load?
- Integration: How easily does the technology integrate with other parts of the client’s technology stack?
Documentation
Whether you are joining an existing project or starting your own, documentation is an essential part of the discovery process. In the case that we are working on a fresh project, defining which documents will need to be created and maintained is an important part of the planning process. In the case of an existing project, we should take the time to read through the documentation and familiarize ourselves with the project structure and any existing processes.
If there is a lack of documentation for an existing project, it is best to let the client know as soon as possible. In some cases, the client may be willing to pay for the creation of documentation. In other cases, the client may be willing to provide additional time for the creation of documentation. Working without any documentation is risky and not the behaviour of a professional developer.
Conclusion
During the discovery phase we may play, experiment, read and ask questions in order to become more comfortable with the problem at hand. This is an important part of the development process, and leads to a smoother and more enjoyable experience for everyone involved. Remember, the goal of discovery is to understand the problem, not to solve it. Once we have a clear understanding of the problem, we can begin to think about solutions.