1. First, write some use case scenarios/specs in order to get a better understanding of the problem (for libraries this is README.md, for user-facing programs i

1. First, write some use case scenarios/specs in order to get a better understanding of the problem (for libraries this is README.md, for user-facing programs its the user's problem and the solution's workflow) 2. Write the code the way you would ideally want it to work, top-down. Imagine that you're in fantasy land. Don't worry about it being wrong or impossible to do that way. That will be corrected later. Use classes to express blueprints for tiny worker machines that work on data, not the data itself. Use classes to simulate entities. A user is not the user's personal information - thats a data structure. A user class makes sense in a testing framework where you want to simulate the process of a user visiting a website. A button is a worker machine that can detect a set of inputs and call attached functions. A list is a worker machine that can keep items and update the screen based on its scroll position. A stream is a worker that can be customized to process incomming data packets in a certain way, and its output can be connected to another stream. Think of classes as tiny single-purpose computers or simulators. 3. Express details about the desired outputs of that top-down code as tests. 4. This is a good time to write all the data structures to represent your data. You can use relational modeling here even if you're not using a relational database (or any kind of database), but you can also use pointers/references instead of foreign keys. Model the data structures for all data (including computed data), not just input or stored data. You can also do this before step 2. but in that case you will be tempted to write your code to operate directly on the lowest level data structures, instead of making it look clean and simple. 5. Try to make the tests pass. 6. If its impossible to implement or you realize its not a good idea to implement it that way, tweak the test a bit then change your code and data structures as you get a better understanding of the problem. 7. Once you're satisfied with the test, you can stop. 8. If the future of the program requires you to adapt it, keep working like that over the existing code. The tests give you some reasonable assurance that it still solves the old variant of the problem, while new tests will ensure that the code sanely solves newer problems too.