While each problem is unique, I've noticed some reoccurring patterns in how I've solved them. Taking a step back and looking at the big picture, I can summarize my software development problem-solving process.
Whether given a set of requirements or a vision statement, my first step is to absorb all the information I can get my hands on.
Often, what is being asked for is only the surface-level description of the problem. One must dig deeper to understand why this problem is trying to be solved. Without understanding the true underlying problem, any solution is doomed to fail.
On the solution side, there will be existing constraints and infrastructure unless it is a greenfield project. The most important thing at this point isn't to pick a solution but to explore all the possible solutions. If it seems blindingly clear there is only one possible solution; this is a bad sign. Spend more time challenging assumptions, and don't get cornered into a suboptimal solution.
When my brain is filled to capacity, I start getting bored or tired. This is when it is time to move on to the next step, sleeping on it. I don't mean going for a walk, playing video games, or working on other things. I mean, literally sleeping in a bed overnight.
I often come up with better ideas after sleeping on a problem. I suspect my brain is organizing all the information I've gathered.
At this point, I still don't quite understand the problem or the solution, but I do have some vague ideas about both.
These vague ideas are enough for me to build a terrible strawman prototype. I know I will throw away this prototype, so I don't try to make it nice. The whole point of the prototype is to give me feedback to see if I understand the problem and solution space. If I'm lucky, it would be functional and may even fulfill all the requirements, but don't be tempted to ship this.
There will be a few false starts, but eventually, I can get the prototype "working" end to end. I've succeeded if the prototype is ugly, slow, and hard to use.
After building the prototype, I literally go to bed again. I let my brain organize my thoughts on the prototype. While the prototype will mostly be terrible, parts of it will be a gem in the rough. Sleep on it helps me find these gems.
The prototype will reveal some ambiguities in the problem and must be addressed before moving forward.
Once I have a firm grasp of the problem, I start detailed documentation. I would write down all the refined requirements we have discovered, map out the API (user interfaces or web services are both APIs in my mind) and use case flows.
I might need to build some smaller prototypes for areas with too much uncertainty.
I use the terrible prototype as the backdrop when comparing any potential designs. This avoids armchair analysis of just how great a possible solution could be when you can see what it actually takes even to build a terrible prototype. This makes debate far more grounded in reality.
At the end of this, I would have a design document.
Designing things takes mental effort, and I am not doing my best work at some point. After completing the design document, I would sleep on it. This ensures my brain has the time to pour over the details and catch any gaps.
I want to get quick feedback on the design, and the fastest way I've found is to implement a functional but incomplete solution. I focus my effort on getting to an unpolished end-to-end demo.
I want people to be able to play with a working system and see how well their designs actually work.
While there should be little to no surprises at this point, there is still a chance for unexpected issues to crop up. Sometimes while working on the solution, there is a nagging feeling of something being wrong. This could be a missing requirement or just a bad design. Sleeping on it ensures my brain can point out what is wrong.
The final step is to polish both the API and the code itself. Some things are hard to describe in a design document on what makes an API amazing to use. Unfortunately, one needs to develop their sense of taste to be genuinely effective here.
Be wary of skipping this step. Bad APIs take far more effort to change once they are out in the wild; by definition, they will need to be changed as they are bad.
Do you want to learn how to solve any problem? You're in luck, Battlefy is hiring.
