This process is not complicated, but it is still very difficult. Without project planning experience, established workflows, or an existing codebase, it is easy to fall into bad habits which hinder progress and cause problems down the road. One set of habits I often see beginners exhibit are all related to trying to build the entire application all at once, rather than building the application step-by-step, feature-by-feature. Good planning and adherence to the plan once development work starts are the best ways to avoid it.
What does this phenomenon look like? Here are some symptoms that might indicate you've fallen into this pattern, and what to do instead:
You find yourself writing feature tickets like "build a RequestsList module" or "Form for adding serviceRequest" that describe code rather than app behavior.
The biggest problem with this way of thinking about your code is that you are skipping the "what does my app need to do?" part of the planning process. Tickets that describe code rather than describe functionality usually include too many assumptions about how to solve the problem. The tickets need only describe the problem to be solved, and how to determine when the problem has been solved, not also solve it. Especially when other features in the app will have already been built when the developer works on this feature, presuming that certain code needs to be written to solve a problem is very limiting, and causes the author of the ticket to include the wrong requirements.
Instead: Describe features in terms of user stories and acceptance criteria. You can use the “As a [kind of user], I [want to], [so that I can…].” and the Given-When-Then formats.
For example:
“As a service technician, I want to view the open service requests, so that I can see which requests are assigned to me and claim unclaimed requests.”
GIVEN I am a logged in service technician
WHEN I click on the “Service Requests” link in the nav bar
THEN I will be presented with a list of cards representing the open service requests
You find yourself "scaffolding" out all of your project's components when initially setting it up, but none of them actually work.
This is the “Frankenstein’s Monster” approach: build the body first (often out of spare parts), and then bring it to life afterwards. This is a very common mistake that beginners make, and comes with a number of drawbacks. First, it is very hard to debug this code. You have no idea why half of it is there (you were probably just guessing at what you were going to need for the components), so there are a bunch of vestiges from other projects throwing errors that you can't even find. Second, you probably did a lot of work that you don't need to do because, again, you were guessing at what you might need in the future rather than what you need right now. See: YAGNI (You Aren’t Gonna Need It).
Instead, try the following:
You find yourself throwing a bunch of features in together with the feature you were supposedly working on, because the feature depends on those other features.
First, it’s possible that you have prioritized your feature development incorrectly, and should have worked on these other features first. Careful attention is required during project planning to prioritize your work so that you are able to add features one at a time.
Despite careful planning, sometimes it is not possible to completely avoid dependencies, but that shouldn’t stop you from working. Two ways to mitigate this problem are:
Breaking all three of these habits boils down to this: You are building applications for people to use to solve business problems. Have their needs, and the functionality that goes with those needs, drive how you build your software, and build it such that you can test that it fulfills those needs every step of the way.
If you or someone you know are ready to start your journey towards a career in web development, discover how NSS can help you get there by checking out our upcoming programs!