The Cult of Scoping
How often have you seen a development lecture, or a post warning against scope creep and for heavily scoping your project?
I'm going to guess probably far more than the number of people recommending against this. Actually... I'd be curious to hear how many people have heard people recommending against this advice as it is almost a sacred cow nowadays.
By heavily scoping your projects, you do get a few advantages. You get the advantage of deciding from the get-go what is and isn't worth your time and what you don't want to work on. There's probably plenty of things you don't want to work on, and want to minimise having to work on, so you can scope as to cut these out. In fact... perhaps it's worthwhile working with your strengths and joys as to cut these parts to a minimum(though in every project there will always be a bit of grunt work that's tedious and miserable).
There is also scoping with the amount of time until you have to get to market and release your project. Work expands to fill the amount of time allotted for it. Knowing this, instead you can go harsher on the deadlines, and if you miss them... no big loss, you're constraining the work to fit in that time, and if it doesn't then you at least made a good effort and you understand the work better now.
However, often what I see with scope, is scoping early into a project, before you've had a chance to find your feet, see what works, what's good and what's not good... Your Ideas are like your children, and by scoping early, you are effectively shooting their legs off and expecting them to breathe and work well. Well pardon me if people find your work mediocre, but you've already killed off anything unique and intriguing about it before it ever got started.
I'd argue instead, if you have the chance to... to implement the ideas you have, experiment with them and see what works and what doesn't. It reminds me of this talk Jonathan Blow gave that I return to occasionally.
One quote that stands out:
"The universe has an unlimited supply of generosity and surprise, and we as designers only need to keep our eyes open to what is here."
How this "Keeping your eyes open" works, depends on what you're working on. For many games, I think a developer test room that is a "Playground" for you to muck around with the different things you've implemented and to find emergent and interesting behaviour is the way to go. Then with that behaviour, try to make things that highlight it.
The reason that I call scoping a cult, as I have in the title, is the advice of scoping is given a lot. To the point that I suspect it is a sort of "groupthink". It's easy to express the advantages of it, but the disadvantages of cutting away the limbs of your ideas before they could possibly bear fruit is a huge disadvantage.
I think a common example of scoping being to the negative of a project, is between programmers and artists interacting. Quite often an artist will have a cool idea, and the programmer(preferring Elegance of implementation, laziness, or pressures elsewhere, usually time and other people) will say it can't be done. Pulling on this thread... the answer is usually that it can be done, but with some compromises(because a programmer will often give you "almost" what you asked for, but not exactly, simply because it's easier to implement). As a result, this mindset of scoping ends up with you shooting down all the interesting ideas.
And if you're both the developer and artist, you will inevitably see the above play out, just in an internal struggle. Timothy Cain made an excellent video on this topic where the excessive caution shoots down any new or fun spin on ideas before they've had a chance to breathe.
This is all a lot of words to simply say that scoping can be good, especially if it's to give creative constraints or simply to avoid well known extremely time-consuming quagmires in development(anything 3D takes longer, anything multiplayer takes longer)... but you have to be careful not to kill all your babies.