Overcoming Mental Hurdles to Software Development

Facing Too Many Unknowns 

Facing many unknowns and working on a new API can be overwhelming. Even if you have the physical and mental energy to work, you can get stuck. I faced this challenge in a recent project. I decided to tackle this by doing an easy task. I copied the basic Bootstrap 4.1 table with hard-coded data and rendered the view in the web app. I was able to see something real, think through vague requirements and asked the stake holder the right questions. If you have a client who only has a vague idea of what they need, it becomes a challenge to gain understanding with minimum amount of code.

Gaining Momentum

I was able to gain momentum by tackling simple tasks related to that feature. Refined the requirements and the user's flow over a few days to come up with more followup questions to finalize the requirements. Once the requirements became clear, I was not coding based on some phantom requirements and designing the complicated database structure that was not even required. The time spent on solving problems that did not exist was very energy draining. I had already spent time on analyzing the flow that could vary due to three variables. This made the solution very complex due to the amount of variations. The code was becoming a big mess.

Focusing on the Core

I drew simple diagrams with boxes and arrows to show the user's flow for different use cases. Discussion with the stakeholder had a structure because we focused only on one use case at a time.  There was no discussion of technology during this conversation. Only golden path scenario was discussed to clarify the requirements. We can add the alternate scenarios later. We can ask questions based on the existing diagrams, reason about what should happen and draw the alternate scenarios separately.

Gaining Business Context

I made the mistake of copying the similar features of other existing products. I realized it was a mistake later because the business context was different. During the conversation based on simple diagrams I was able to understand the business context. I had narrowed the scope of the problem to be solved.  I also pushed back on some requirements and asked the stakeholder to justify why it should be included in version 1. Some of the things might happen once every 3 months does not justify automation and was removed from the stated requirements.

Building a Prototype First

I did not build a prototype because it was a lot easy to use Bootstrap 4.1 with Rails to build the screens with hard coded data. I saved the time to learn a prototyping tool. I was able to focus on learning new AWS APIs that was required to build the product.

Being Agile and Lean

The client was remote and was able to chat via What's app and email few times a week. The requirements were in the emails and were not well thought out to write the test first. Clarify First, Test Later. I did not automate the infrastructure management because at this point I am not sure if I can get 99 clients who will find this product useful without any customization. It has been custom built for this particular client. Reading the lean startup articles, I was confident that I was targeting the right segment in the adoption curve.

Lessons Learned

• Do not write production level code before understanding the business. 
• Draw simple diagrams with technical details to gain business context first.
• Narrow down the scope of the problem before starting to code.
• It's ok to start the first few versions of the screen with existing products from similar domains.
• Remember, these screens need to refined once the business context knowledge is acquired.
• If the complexity of the solution is getting out of control, go back and see if you can push back on the requirements.