3 ms·

Do you write the plan down? Like an outline? I want to get better at what you are describing.

by jpmoyn 8y ago

edoo 8y ago
Better put you build the components with the least dependencies first after your software architecture is decided, up to and including pseudo code, to the point you are confident in the design and are not required to think about it while implementing it in real code. If a design issue comes up stop programming and fix the architecture. I'm a graph paper guy myself. Say a racetrack library. We have a 'racetrack', it has a 'list' of 'cars', they have a 'list' of 'tires', and 'list' is a custom class and we know how it is all going to fit. Now normally you might start with a 'racetrack' class, start a car class, start the list class so you can have the cars on the racetrack, start the tires class. Add functionality to the list class to get something to work. You leave a trail behind you that if you try to keep in your head can get pretty awful in big projects. If you start with the objects with least dependencies you can forget about them once you are done. 'list' has no dependencies, you can make the class (and all test code if desired) and forget about it. Now you can focus entirely on a tire (and all test code if desired), and forget about it. Then you do the car class fully, then the racetrack. At every level you have everything below it done so you can fully complete the implementation in one shot instead of bouncing all over the place . It isn't always perfect but it really cuts down on the brainpower you have to expend. This is best suited with unit testing. At first it can feel ungratifying to program this way, even scary. You could be 85% done with your planned architecture and have almost no visible behavior of your final product, with that last 15% being the actual high level abstractions that really tie everything together and the project just seems to pop into completion.

Do you write the plan down? Like an outline? I want to get better at what you are describing.

by jpmoyn 8y ago

Do you write the plan down? Like an outline? I want to get better at what you are describing.

edoo 8y ago

Better put you build the components with the least dependencies first after your software architecture is decided, up to and including pseudo code, to the point you are confident in the design and are not required to think about it while implementing it in real code. If a design issue comes up stop programming and fix the architecture. I'm a graph paper guy myself. Say a racetrack library. We have a 'racetrack', it has a 'list' of 'cars', they have a 'list' of 'tires', and 'list' is a custom class and we know how it is all going to fit. Now normally you might start with a 'racetrack' class, start a car class, start the list class so you can have the cars on the racetrack, start the tires class. Add functionality to the list class to get something to work. You leave a trail behind you that if you try to keep in your head can get pretty awful in big projects. If you start with the objects with least dependencies you can forget about them once you are done. 'list' has no dependencies, you can make the class (and all test code if desired) and forget about it. Now you can focus entirely on a tire (and all test code if desired), and forget about it. Then you do the car class fully, then the racetrack. At every level you have everything below it done so you can fully complete the implementation in one shot instead of bouncing all over the place . It isn't always perfect but it really cuts down on the brainpower you have to expend. This is best suited with unit testing. At first it can feel ungratifying to program this way, even scary. You could be 85% done with your planned architecture and have almost no visible behavior of your final product, with that last 15% being the actual high level abstractions that really tie everything together and the project just seems to pop into completion.