At the beginning of the project, ask yourself this:
do I know all relevant facts about the planned project?
what is the chance that something is wrong, because the customer didn’t think about their needs sufficiently, or forgot something, or there was a miscommunication with the customer?
what is the chance that during the project either the customer will change his mind, or the external situation will change so that the customer will need something different than originally planned?
If you are confident that you know all you need to know, and the situation is unlikely to change, then I would agree: a week of planning can save a month of coding.
Problem is that this type of situation happens frequently at school, but rarely in real life. During 15 years of my career, it happened to me twice. Those were the best projects in my life. I did some research and planning first, then wrote the software according to the plan. Relaxed pace, low stress. Those were the good times.
Unfortunately, most situations are different. Sometimes there are good reasons. Most of the time, in my opinion, someone just didn’t do their job properly, but it’s your problem anyway, because as a software developer you are at the end of the chain. You have two options: start your own company, or develop proper learned helplessness and accept the lack of analysis and planning as a fact of life.
Yes, this opinion is controversial. What happened, in my opinion, is that at first, there were good insights like “mistakes happen, circumstances change, we should program in a way that allows us to flexibly adapt”. However, when this became common knowledge, companies started using it as an excuse to not even try. Why bother doing analysis, if you can just randomly throw facts at programmers, and they are supposed to flexibly adapt? What was originally meant as a way to avoid disasters became the new normal.
Now people talk a lot about being “agile”. But if you study some agile methodologies, and then look at what companies are actually doing, you will notice that they usually choose a subset that is most convenient for the management. The parts they choose are “no big analysis” and “daily meetings”. The parts they ignore are “no deadlines” and “the team decides their own speed”. (With automated testing they usually go halfway: it is important enough so that there is no need to hire specialized testers, but it is not important enough to allocate a part of budget to actually doing it. So you end up with 5% code coverage and no testing, and if something breaks in production, it’s the developer’s fault. Or no one’s fault.) This is how you get the usual pseudo-agile, where no one makes proper analysis at the beginning, but they still specify the deadlines when the yet-unknown functionality must be completed. Now the team is free to choose which features they implement on which week, under the assumption that after six months they will implement all of them, including the ones even the management doesn’t know about yet.
Yep, I am quite burned out. Seen too much bullshit to believe the usual excuses.
Anyway, even on shorter scale it makes sense to plan first and code later. If your “sprint” takes two weeks, it still makes sense to spend the first day thinking carefully about what you are going to do. But again, the management usually prefers to see your fingers moving. Thinking without typing may result in greater productivity, but if often creates a bad impression. And where productivity is hard to measure, the impressions are everything.
At the beginning of the project, ask yourself this:
do I know all relevant facts about the planned project?
what is the chance that something is wrong, because the customer didn’t think about their needs sufficiently, or forgot something, or there was a miscommunication with the customer?
what is the chance that during the project either the customer will change his mind, or the external situation will change so that the customer will need something different than originally planned?
If you are confident that you know all you need to know, and the situation is unlikely to change, then I would agree: a week of planning can save a month of coding.
Problem is that this type of situation happens frequently at school, but rarely in real life. During 15 years of my career, it happened to me twice. Those were the best projects in my life. I did some research and planning first, then wrote the software according to the plan. Relaxed pace, low stress. Those were the good times.
Unfortunately, most situations are different. Sometimes there are good reasons. Most of the time, in my opinion, someone just didn’t do their job properly, but it’s your problem anyway, because as a software developer you are at the end of the chain. You have two options: start your own company, or develop proper learned helplessness and accept the lack of analysis and planning as a fact of life.
Yes, this opinion is controversial. What happened, in my opinion, is that at first, there were good insights like “mistakes happen, circumstances change, we should program in a way that allows us to flexibly adapt”. However, when this became common knowledge, companies started using it as an excuse to not even try. Why bother doing analysis, if you can just randomly throw facts at programmers, and they are supposed to flexibly adapt? What was originally meant as a way to avoid disasters became the new normal.
Now people talk a lot about being “agile”. But if you study some agile methodologies, and then look at what companies are actually doing, you will notice that they usually choose a subset that is most convenient for the management. The parts they choose are “no big analysis” and “daily meetings”. The parts they ignore are “no deadlines” and “the team decides their own speed”. (With automated testing they usually go halfway: it is important enough so that there is no need to hire specialized testers, but it is not important enough to allocate a part of budget to actually doing it. So you end up with 5% code coverage and no testing, and if something breaks in production, it’s the developer’s fault. Or no one’s fault.) This is how you get the usual pseudo-agile, where no one makes proper analysis at the beginning, but they still specify the deadlines when the yet-unknown functionality must be completed. Now the team is free to choose which features they implement on which week, under the assumption that after six months they will implement all of them, including the ones even the management doesn’t know about yet.
Yep, I am quite burned out. Seen too much bullshit to believe the usual excuses.
Anyway, even on shorter scale it makes sense to plan first and code later. If your “sprint” takes two weeks, it still makes sense to spend the first day thinking carefully about what you are going to do. But again, the management usually prefers to see your fingers moving. Thinking without typing may result in greater productivity, but if often creates a bad impression. And where productivity is hard to measure, the impressions are everything.