General programming discussion • Re: what should I first do to make a good app.

Plan!

Here is the basics of what I used during my software career:

1. Start with some form of Specification, describing (usually in natural language) what you want the program to do from the user's point of view.
2. Translate the Specification into Requirements, which are smaller units of functionality more aligned to how they might be programmed.
3. Depending on (1), choose your language (or, for large projects, possibly languages).
4. You may want to write some throw-away "proof of concept" code to satisfy yourself that you can do the necessary functions in that language.
5. Work out what libraries you need for particular functional areas, or possibly decide you are writing everything from scratch.
6. Analyse the Requirements to get a structure for your software, grouping related functionality together and separating unrelated things, for example keep the User Interface, the data storage, and different data processing functions separate. The aim is that, later on, you should be able to re-write one part without affecting any others. Don't forget your internal services, such as error reporting and logging systems.
7. Professionally, we would make a first attempt at defining interfaces between different parts of the software, and particularly any calls into your software from other programs. This is particularly important in big systems where different parts are going to be written by different people.
8. When you can't make any more progress just by thinking and describing interfaces and structure (that is, you reach "analysis paralysis"), you can start writing real code.
9. Document your code as you go -- plenty of comments (so you can recall several years later what you were thinking when you wrote the code) and possibly a written description of each section of code.
10. Test, test, test. Test each section, if necessary, writing a "test harness" that can exercise all the functions and options of a part of the code. Test against the Requirements, and eventually against the Specification.
11. At any stage, if you get stuck, or have new ideas, you can go back as many steps as necessary and re-work the affected parts from there on. Don't be tempted to add things without going back far enough.
12. Enjoy!

This process can be reduced or expanded depending on the size of the project -- I worked in projects that took a team of programmers a year or two to complete, but the flow is important for anything more than a trivial (one night) program.

This outline works very well with "Object Orientated" methods of analysis and development. Learning to use a thorough process will be very important if you want to become a professional software developer. You may want to look at various formal ways of drawing diagrams of software structures and functions -- we used UML extensively, though some parts are more useful than others (partly that depends on what you are writing).

Statistics: Posted by davidcoton — Mon Dec 15, 2025 10:39 pm

---