I have been wondering if I should plan ahead everything I code in advance since I tend to figure out a program as I go. When I do anything frontend, I plan how I want the CSS image or the web page to look like before I even start to code though but apart from that, I pretty much jump into it right away. I admit it would probably have saved me some time if I had just sat back and planned out the desired outcome more before I started coding.
Here is an interesting excerpt on the topic from Hackers and Painters by Paul Graham:
For example, I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.
For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do.
Do you follow a particular structure while you code? Do you plan ahead or figure out programs as you are writing them?
Top comments (43)
My answer is... YES!
It really depends on context. Am I doing something exploratory, where I don't necessarily know what the end product is going to look like? Then code as you go. You can always come back and refactor later, but for now, focus on getting things to work.
If I'm building something and I know what it ought to look like, then I should try to minimize the refactoring required - take time to design and think through the structure ahead of time.
This is the one way that I see Software Engineering as being different from other types of Engineering... we don't always have to know the end goal before we start building.
Yeah, I think this is one of those things where there are virtues to either and people and teams get misguided if they stray too far in one direction or the other.
In the team context in particular, of course we need ample planning to be effective as a unit, but too much planning dramatically reduces outcomes. In this case I think certain principals need to be in place of the wrong type of planning. You can't just wing it, but you can agree on things which help in the future where too much planning slows things down to a crawl.
pretty cool to see someone admit they just hack through it too - honestly i always end up making tweaks on the fly anyway. you think figuring stuff out as you go can actually lead to better ideas, or does it just slow things down?
Hehe 😁
I have no idea. One should think that a little bit of planning would save some time but I do not know.
for me....
Here’s the workflow I follow:
Use ChatGPT for brainstorming ideas — the what, how, and why.
Start wireframing with pen and paper as soon as I have a rough concept.
Move to Uizard.ai (Figma isn’t my thing) and recreate the wireframe digitally. Then I use Uizard’s AI to enhance it.
Finally, I follow that UI and start writing the actual code.
Honestly it's hard for me to imagine all the things I know I'm going to want in my project and how I'm going to do them and it's even harder for me to stick to a static plan, so I mostly start my project with very basic image I had in my head and adopt it as time passes, though this approach of mine is not really that much of a nice one when it's about something like a game dev project, for example when I'm working on a development board, I have a basic image in my head about stuff I'm going to do and I figure how I'm gonna do them and how I can add futures I like when I'm sitting in front of my monitor, but when it's a project like developing a game, since nearly each decision effects over all game quality big time, I wouldn't really freestyle much in situations like that
Based on what works for me, the answer is a decisive nes... yo? Whatever, point is both but neither.
Planning evertything before even writing the first line of code sets you up for unforseen problems that require either a complete redesign or trying to fit things together however you can. Either way, you lose time.
Going in completely blind and just building the program can get you the same problems, just in a different way: the danger there is finding problems only as you get to that part of the program, after you've already built large parts of it that you now need to change.
The middle ground is the way to go: Start writing code, but not as a final implementation; explore the problem domain in code and figure out the fuzzy parts. Then build the real thing and re-use the code that is good enough after some refactoring while re-writing the parts that were only there to support your experiments.
Sometimes this can be done iteratively, sometimes it's a bit more "step by step", but there's almost always a benefit to exploring your options with a prototype rather than as an abstract design.
EDIT: After posting this, I kind of realise this is basically just the same idea Paul Graham described in that quote. I wouldn't have picked "Sketching" as a word for it, because to me it feels more like a process of exploration. Loke walking around and poking at things. Except the "poking at things" means writing snippets of code and seeing how they work out.
as with all things, it depends.
if I’m working on something small, it’s time to hack and slash my way through it. but if it’s remotely complex or I’m working with others, there’s at least 1 flow chart and some breakdown of work (usually using GitHub’s product management tools).
10 minutes of planning up front can save hours of work later
You can't plan what you've never done before so you must try coding it first.
You perfectly code without planning what you have done many times before.
Hence, you both plan and try coding those partially known.
None and both, actually your problem is on chosing either evolutionary or waterfall style. So choose non of them, instead use what RUP designers created to choose both.
You need to distinguish between development disciplines and project phases and then take an iterative approach. In every iteration ideally fit in a sprint, which may or may not result in a release, you pass almost every discipline but the product only subtly changes toward final matured product.
In your case, you only identified planning and implementation, but real world projects may identify other disciplines such as test, design, analysis, deployment. Also the projects phases are inception, elaboration, construction and transition.
Also it should be noted that most people think of scrum or other agile methodologies as competitor to RUP, but they are wrong. Since RUP is a meta process model framework, and any agile is a tailored version of RUP. Usually agile replaces modelling as a pre-implementation discipline with mental model of team members build and shared by excessive communication.
I think I do something similar to Paul Graham's method of planning. It kinda depends on what I'm doing though... in other words, if the program I'm working on (likely) won't ever need to be refactored/maintained, I spew more than I plan.
I don't particularly like TDD, but I do love some of the philosophies it's built on top of. One of which is the idea of just building your program, one feature at a time. Instead of planning ahead, you go for the most obvious solution, then once you have it working, you can spend some time to clean up your code, and In TDD's case, you'll be leaning on your tests as you clean up to make sure you don't break anything.
The "planning ahead" they're talking about from school is where you figure out the entire project from start to finish, figure out every single feature in that project, and figure out every single class and property you will want to have (using UML), then you build the actual code. Almost nobody does this sort of thing anymore. Classes are too low-level of a building block to be trying to map out from the start.
I still technically do some planning ahead. If I know I'll eventually need something to work a certain way, or be organized a certain way, then sure, I'll make that happen from the start. But for the most part, it's better to let your projects grow organically. If one class or module gets really complex, look for a highly coupled subset of code and extract that out into its own class or module. Organizing a program by "coupled-ness" is the best way to go, but requires the code to first be written so you can get a feel for how coupled different parts are.
There's exceptions. There always are. Just do what feels right to you and don't fret too much about what you think the industry thinks is right.
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more