I'm a programmer who likes games, and wants to make games for a living. At the same time, there are some really cool non-game things I want to work on -- especially if they use C or C++.
The key is, indeed, to know when to say no. That doesn't mean "always say no". It means to be judicious. You wrote this article as though your only options are scope explosion or iron-fisted scope control, but that's just not the case. If you know exactly and explicitly what you need to make, you can stick to this advice. But, in practice, even if yout think you know, you don't. You always have to make changes and update what you thought you knew.
You are right. But if we are aware of what we are doing and the costs of our choices, we will get better. My aim with this article was to increase awareness of developers.
I'm a programmer who likes games, and wants to make games for a living. At the same time, there are some really cool non-game things I want to work on -- especially if they use C or C++.
Fair enough! My only concern is that a junior developer will read this and take from it the bad idea of refusing all scope increases. I agree that scope creep is a bad thing in general, but there are times when it makes perfect sense.
For example, let's continue on the example of the email client. Sure, it can send and receive emails, and that's the barebones requirements. But now, every email you get is all in the same list, whether they're racist forwards from your "I'm not racist, but..." uncle or from that big new client you just netted. So clearly, some sort of filtering is useful. Even though that's an increase in scope, it's still worth it to add, because that's a vital feature.
That's what I meant by "that's just not the case" -- sure, you might think you know exactly what you're making, but even the most detailed specs can't account for everything.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The key is, indeed, to know when to say no. That doesn't mean "always say no". It means to be judicious. You wrote this article as though your only options are scope explosion or iron-fisted scope control, but that's just not the case. If you know exactly and explicitly what you need to make, you can stick to this advice. But, in practice, even if yout think you know, you don't. You always have to make changes and update what you thought you knew.
You are right. But if we are aware of what we are doing and the costs of our choices, we will get better. My aim with this article was to increase awareness of developers.
Fair enough! My only concern is that a junior developer will read this and take from it the bad idea of refusing all scope increases. I agree that scope creep is a bad thing in general, but there are times when it makes perfect sense.
For example, let's continue on the example of the email client. Sure, it can send and receive emails, and that's the barebones requirements. But now, every email you get is all in the same list, whether they're racist forwards from your "I'm not racist, but..." uncle or from that big new client you just netted. So clearly, some sort of filtering is useful. Even though that's an increase in scope, it's still worth it to add, because that's a vital feature.
That's what I meant by "that's just not the case" -- sure, you might think you know exactly what you're making, but even the most detailed specs can't account for everything.