Slow productivity when working with larger programs
I'm pretty bad at keeping tabs of everything when working with larger programs. It's always easy working with just 100-200 loc, but getting to 500 significantly slows down my progress if the logic is dense. Compartmentalization and coding one thing at a time works but still feels overwhelming. Is there some sort of method when developing larger programs or book recommendation regarding this topic?
Last edited on
of course.
there are tools for this; we have a tool that keeps a 'backlog' of things that need doing, and every few weeks we assign the highest priority items from that to various developers and they work it. These vary from bug fixes, performance tune, new features, etc. The tool is a giant tree structure, the whole big project has sub projects which have something else which has yet another one which has the work that I have to do. I just see it at the 'leaf' level most of the time, where the actual work gets done.
There are many tools out there for this. Ours is called 'agile central'.
I think GIT has a way to track what needs doing and who is doing it; the opensource community has a way to track things that works in their more chaotic environment (where the priority is somewhat ignored in favor of random selection of work chunks).
one thing at a time is the way to go. Anything else becomes a worse and worse idea the bigger the code is. If 2 issues are in the same function, the person organizing work can put them into one work block for you, but you need to be very, very careful when testing it to get both problems tested and tracked. If you fix one well and the other not so good, ... you see, its better to have them split up... its hard to track and manage them if grouped.
there are tools for this; we have a tool that keeps a 'backlog' of things that need doing, and every few weeks we assign the highest priority items from that to various developers and they work it. These vary from bug fixes, performance tune, new features, etc. The tool is a giant tree structure, the whole big project has sub projects which have something else which has yet another one which has the work that I have to do. I just see it at the 'leaf' level most of the time, where the actual work gets done.
There are many tools out there for this. Ours is called 'agile central'.
I think GIT has a way to track what needs doing and who is doing it; the opensource community has a way to track things that works in their more chaotic environment (where the priority is somewhat ignored in favor of random selection of work chunks).
one thing at a time is the way to go. Anything else becomes a worse and worse idea the bigger the code is. If 2 issues are in the same function, the person organizing work can put them into one work block for you, but you need to be very, very careful when testing it to get both problems tested and tracked. If you fix one well and the other not so good, ... you see, its better to have them split up... its hard to track and manage them if grouped.
Last edited on
Be sure that you design the software before you start coding it. For projects like what you're talking about (a few hundred to a few thousand lines of code), you can work on the class interfaces - the header files. Write these. Document what each data member is, and what each method does. Maybe write some pseudo-code for how each one works. Resist the temptation to dive down into the details. Do just enough work to convince yourself that you can write the code. Work through the use cases.
You'll probably find yourself making lots of changes. Don't be surprised if you throw away some classes and start again. You may even find that you throw away the whole design and start again. This is perfectly normal.
Eventually you should have classes that you're convinced will get the job done. That's when you can start writing code.
You'll probably find yourself making lots of changes. Don't be surprised if you throw away some classes and start again. You may even find that you throw away the whole design and start again. This is perfectly normal.
Eventually you should have classes that you're convinced will get the job done. That's when you can start writing code.
https://en.wikipedia.org/wiki/Software_development is a large branch of computer science, one which you must have at least introductory exposure to in order to gain a CS BS / equivalent.
Designing your software is the very first thing you should do, before you even power up your code editor. This can involve quite a lot, but for small programs (anything under 1000-5000 LOC is a small program, sorry), you can treat yourself as the end user and do a lot of requirements discovery yourself.
R E Q U I R E M E N T S D I S C O V E R Y
Sounds fancy, but it is exactly what it says on the tin. You need to identify, at minimum:
• what problem are you trying to solve?
• what will your UI look & behave like?
Identifying those two things will help you organize your program’s structure. Get out a piece of paper, and draw pictures. Write notes to describe to yourself what each part of the UI does, how the UI responds, etc.
If necessary, show the pictures to potential end users, or to friends and family, and ask them to identify what they would do to use your program, and what they would expect the program to do. Good drawings or other mockups are essential here. Again, for small programs, you may find yourself being your primary end user, but it is always a good idea to get additional input at some point.
Incomplete Example:
Yep, lots of thought. For a simple, dumber than Notepad editor.
Part of your requirements discovery includes finding appropriate libraries to help you with your job. For example, you could choose to use Qt for the application framework, or wxWidgets, or go straight to something like Scintilla for the editor widget and do everything else yourself.
M O C K U P
It may be worth your time to create a mockup application, a throwaway designed only to get an idea of how things work. You can do this in any language you wish. Sometimes something quick and easy like Tcl/Tk or Python will get you pretty far. Sometimes you can create your mockup in your target language (C++) and modify/reuse components in the final program.
Even if your mockup does not offer the full functionality of your final program (such as allowing actual file editing), playing with stuff to read and write files, move the cursor around, etc, will help you flesh out details you need to be aware of when coding the final project.
The mockup is also the place to spend time thinking about the final application’s appearance. Create icons/images/etc here.
I T E R A T E
Whether you use a mockup or not, in both the mockup and the final application, make sure to identify waypoints where you can actually execute the application and see something happen.
For example, for the Super Extra Teeny Tiny Plain Text Editor, you can write the code that does nothing but display a window and allow you to close it. Add the text editor component and test the basic editing that it comes with. Add the menu bar and load/save programs, complete with OS-specific dialogue boxes to do so. Test each step as you go. Begin adding the key & key sequence commands you wish to have. Add the ability to cut/copy data. Add the ability to paste data. Etc. At each step, you are only focusing on one specific thing.
R E V I S I O N C O N T R O L
You absolutely need some form of revision control. Download and use a local git if you wish. Or just keep zips of every milestone so that you can go back and either restore from a total screw up or get stuff you threw away but want anyway.
Yes, a lot of steps, organization, etc. But, remember, it is an organic process as well. Half the fun in programming is designing what you intend to code.
Hope this helps.
Designing your software is the very first thing you should do, before you even power up your code editor. This can involve quite a lot, but for small programs (anything under 1000-5000 LOC is a small program, sorry), you can treat yourself as the end user and do a lot of requirements discovery yourself.
R E Q U I R E M E N T S D I S C O V E R Y
Sounds fancy, but it is exactly what it says on the tin. You need to identify, at minimum:
• what problem are you trying to solve?
• what will your UI look & behave like?
Identifying those two things will help you organize your program’s structure. Get out a piece of paper, and draw pictures. Write notes to describe to yourself what each part of the UI does, how the UI responds, etc.
If necessary, show the pictures to potential end users, or to friends and family, and ask them to identify what they would do to use your program, and what they would expect the program to do. Good drawings or other mockups are essential here. Again, for small programs, you may find yourself being your primary end user, but it is always a good idea to get additional input at some point.
Incomplete Example:
| A Super Extra Teeny Tiny Plain Text Editor: Visual Requirements • a menu bar with "Open", "Save As", "Quit", "About" • a text box with a cursor • work with Unicode (BMP only) System Requirements • must work identically on Windows and Linux (meaning, no weird stuff interfering with OS-specific user expectations) Functional Requirements • must load and save a text file to/from memory/local storage ("disk") • must allow editing (all arrow and Home, PgUp, etc — be specific and list every recognized key & key combination and what it does to either move the cursor, manipulate the edit text, or command the editor) • must provide undo history • must reasonably protect edits from being lost in case of failure (by auto save to temporary every 5 minutes?) • I/O must handle UTF-8 encoded files • Cut/Copy/Paste from the system Clipboard (Windows) / Selection (Linux) |
Yep, lots of thought. For a simple, dumber than Notepad editor.
Part of your requirements discovery includes finding appropriate libraries to help you with your job. For example, you could choose to use Qt for the application framework, or wxWidgets, or go straight to something like Scintilla for the editor widget and do everything else yourself.
M O C K U P
It may be worth your time to create a mockup application, a throwaway designed only to get an idea of how things work. You can do this in any language you wish. Sometimes something quick and easy like Tcl/Tk or Python will get you pretty far. Sometimes you can create your mockup in your target language (C++) and modify/reuse components in the final program.
Even if your mockup does not offer the full functionality of your final program (such as allowing actual file editing), playing with stuff to read and write files, move the cursor around, etc, will help you flesh out details you need to be aware of when coding the final project.
The mockup is also the place to spend time thinking about the final application’s appearance. Create icons/images/etc here.
I T E R A T E
Whether you use a mockup or not, in both the mockup and the final application, make sure to identify waypoints where you can actually execute the application and see something happen.
For example, for the Super Extra Teeny Tiny Plain Text Editor, you can write the code that does nothing but display a window and allow you to close it. Add the text editor component and test the basic editing that it comes with. Add the menu bar and load/save programs, complete with OS-specific dialogue boxes to do so. Test each step as you go. Begin adding the key & key sequence commands you wish to have. Add the ability to cut/copy data. Add the ability to paste data. Etc. At each step, you are only focusing on one specific thing.
R E V I S I O N C O N T R O L
You absolutely need some form of revision control. Download and use a local git if you wish. Or just keep zips of every milestone so that you can go back and either restore from a total screw up or get stuff you threw away but want anyway.
Yes, a lot of steps, organization, etc. But, remember, it is an organic process as well. Half the fun in programming is designing what you intend to code.
Hope this helps.
Thank you very much everyone for the useful feedback and a glimpse of the thought process. Seems like the design process takes up a lot of development time rather the time for coding from the descriptions above. I will be sure to practice more and improve myself :) (You guys rock!)
Last edited on
design is coding. If you don't design your code first, nothing good will happen when you reach your threshold. Your threshold is bigger if you have experience but everyone has one. A novice can get lost in 5 files and a couple hundred lines of code, a vet maybe in 10k+ lines, but eventually the code-first approach will leave you in a bad place. Vets get away with more, as much as not, by just having a set of designs in their heads from having done before -- so even their code-first work has a partial design under it.
Last edited on
Topic archived. No new replies allowed.