Coding Can Wait (or how I stopped worrying and learned to love FDD)
Hi! 👋 My name is Jeffrey Fate. I've spent my entire career creating and ensuring quality code. I've taken on many roles: manual quality assurance, automated test developer, full stack engineer, devops engineer. In each position my mantra has always been the same: Quality Counts. I'm going to do my best in sharing how to develop software from that lens, starting here...
I sat staring at the next card in the queue for a few seconds. "Ok, this is pretty straightforward", I thought. Fast forward four hours and I was reverting all the code I wrote. It got really hairy really fast. My mind (and hubris) got me into trouble when I didn't think ahead and design the feature. If this sounds at all familiar, read on.
Jumping straight to coding is almost always a bad idea. It's like starting a cross country trek without planning your route or taking any supplies. Maybe you know the codebase very well, or maybe you don't. Either way, there are bound to be areas that are unfamiliar or forgotten that you need to be concerned with for the change you're contemplating. By reviewing what you need to do and designing from a higher level, you can usually bypass the troubles you get into halfway into development.
There are a handful different methodologies or patterns to guide you in this realm, but only recently did I discover the three letter acronym FDD. I already knew TDD (more on that later), but hadn't heard of FDD. It made intuitive sense though. Feature Driven Development is probably writing software from a feature mindset. I'd like to advocate for giving FDD a spin as a solution; here's the rundown:
FDD Creates Quality Code
Coming from me, this has to be the angle. I'll explain how we get there by describing the FDD activities and best practices.
Coding first feels right - to get something working - but taking an overall look at what the goal is, it becomes more clear and quicker to develop it.
- Break into groups (or as individuals) and come up with the model of each domain then come together and select the model for each
- This doesn't really jive if you are a solo development team, but you should still do the exercise because you might come up with previously hidden details
- Jump here if you're dealing with a feature - no need to rehash the entire domain model
- Decompose the domains by developing features in each area
- Each needs to be written as client/customer value in the form of: ACTION RESULT OBJECT
- Example: "Send reminder email to user"
- Plan development for each feature by splitting up the features and writing up cards to be worked on independent of each other
- These need to be broken down to the value driven phrases created in the previous step0. Feature Design
- Documentation is written by a developer (or group of developers, or you) describing (and diagramming) each feature
- Peer review these plans prior to cutting code
Build Each Feature
- With planning done, each feature can be coded and tested independently.
I'll be the first to say, all of these steps might be overkill for a lot of work we do on a daily basis. BUT, if you keep the general idea of this process in mind, the goal can be achieved repeatedly: develop the feature first, then start coding. It greatly reduces being stuck between code and a hard place after half completing features only to realize the design in your head isn't complete. Been there!
If you'd like to hear me spout my mouth off (as opposed to my keyboard) about feature design and other quality aspects of software development, check out my podcast [Discode](https://discode.dev). You can find it on any podcast aggregator like iTunes and PocketCasts.
Best Practices (not already covered)
Reviews and Visibility
Yes, this was previously mentioned, but it is best to keep in mind that this process needs to be transparent and visible at all times. Write documentation in public. Use a whiteboard so anyone can see it as they walk by. The more eyes on designs and documentation, the more likely holes or mistakes will be found early.
Try and include as many folks as is reasonable, technical and non-technical alike. In fact, it can be amazingly helpful to get some one's opinion who has no experience in software (or your software specifically) or who has no knowledge of the project at all. Getting someone else's angle can shed light on previously darkened areas of your design.
Over communicate. Actually, this is generally a good idea in life, but especially here. Announce what you're working on, what stage you are starting, what the outcome was, that you're blocked on something. Everything about the process should be communicated.
Next time you grab the next card, take hands off the keyboard and think about FDD. At the very least, make a checklist in your head that will accomplish most of what's described here. Know that following FDD helps you write better code because you're not constantly designing as you code. Everything is more cohesive and obvious as you type; no more starts and stops and redesigning halfway through. The main positive I've noticed from using FDD is the confidence in my code is higher and I worry less that the outcome is what it should be.