How to write software for your programmer.
Writing software is a technical activity. Most persons who identify a problem they want to solve will start, “I know what I want, but am not a tech person”. So they pass off the responsibility to a programmer. They’ve done so without describing what needs to be done. Programmers charge a lot of money to people they think don’t know what they are doing. Learn to describe your solution properly and you will have better, cheaper relationships with programmers as they help build your solution.
I spent a couple of years learning by doing in my own startup and this article sums up what I keep saying to first time founders looking for coders, over and over again.
Do not think about a programmer yet, first describe your solution
After you have defined the problem you are solving. Write out everything in essay format describing your customer’s journey. EVERYTHING.
Create general subheadings for the steps.
Take the subheadings and do a flowchart chart or a swim lane chart to understand the different departments or users of your solution, both on the customer side and the different roles on the supply side. Figure 1. shows an example of what a flowchart of a process would look like ideally.
Research flow chart to get the symbols and then swim lane charts to understand the layout.
The symbol for predefined process (See figure 2) should be used to describe the subheadings. Every time you use this, you will have to reference where i can find this process in illustrated in more detail in your plan.
In the 'subprocesses' you should also describe what happens when the user enters wrong information or incomplete information in addition to the correct information. Use the ‘swimlanes’ to determine which role is involved in this sub-process. Describe the sub-process in a document you will call ‘User Stories’ in this format :
As a <user defined in swimlane> I want <some goal or objective> so that <benefit or value realised>
Start making notes on what someone would need to know in order to build this solve this problem. It become easy at this point to ask for help at this point from an expert for his/her opinion or read broadly and scrapbook on the topic and title this heading ‘Requirements’
Make notes about what is expected out of each process when the right and wrong kind of information goes in, this way an engineer can use this instruction to test his code before he brings it back to you. Label this heading ‘Acceptance criteria’
As you work through your requirements you will find that some user stories are bigger than you first thought. This is fine. Repeat the process above, down to this point to break down a complex user story into smaller ones. You can then prioritize the order in which the stories are implemented.
Write out all the types information in your process note the ones that change and the ones that stay constant for each user or object they interact with in the process. The programmer will need this list from you when defining his database. Use a spreadsheet to do this and name the file ‘Data dictionary’
Make sketches of each screen and how the user would move from one screen to the other (See Figure 3). Do versions of each screen when they fill out fields press buttons and try to match back to your list of information elements in your data dictionary to say what changes when the user interacts with the screens.
So we got to the point where it is not technical as it is detail oriented. This is a lot of work for one person to do. It is recommended this exercise be done as a team. A diverse multidisciplinary team is better than a group of programmers. Work with your team to define the requirements of your project and then you will be able to provide so much information on the project you could practically code it yourself.
Leave a comment requesting more details if you are interested in attending a product development webinar.
