- Identify the primary reason for the software, and the flow of how it works
- Identify any 'fringe' things (GUI, file IO, etc) that are usually already developed as other tools in some capacity, yet will need to be integrated in
- Develop a proof of concept for (1), with plenty of debug statements.
- Iterate over the flow, using refactoring techniques, until the primary purpose of the software is complete and efficient. Create plenty of hooks, even unused ones, that allow flexibility in control of when methods are called (getter methods, calculate methods).
- Develop the structure and control of the main program that the user will see, if it's meant for someone else.
- Develop fringe things. Basic GUI, FileIO to save settings, etc. This is actually the most time-consuming and least-fun part, yet it's typically what the end-user complains the most about.
For example, I'm developing a (soon-to-be) open source scheduling algorithm that is supposed to be flexible enough to schedule matches for FLL, FTC, and FRC. Its primary purpose is to develop a schedule subject to parameters such as # of teams per alliance, # of alliances, & min/max match spacing. Honestly, if match spacing wasn't an issue it'd be trivial to make a scheduling algorithm ><. The fringe features are "Alliance Insertion" (pair up titans versus titans, subject to their consent) & scheduling for judging after the match schedule is done. It will have FileIO in case the program quits in the middle of a competition, and a GUI with which to interact.