That was a good read, and some much needed advice. Nowadays, I find increasingly difficult to start a project, worrying about the "big picture" and "overall design" and spend too much time thinking about it before even writing a single piece of code.
It is difficult to guage how much planning to put in, just the right amount.
I had the same problem. I don't like to start writing without having th complete knowledge of the problem, and of all the known solutions etc. My advice is, read a bit of stuff, then start a quick prototype, choose a prototyping language so you won't use that code in the final C++ product anyways (to avoid the prototry resign pattern). Hopefully the prototype will show you early problems in the design you was thinking of, and so you can think more, do another proto etc... This does not save you entirely from having a bad design in the end, you have always to iterate, but at least a first exploratory phase helps you choose the right direction. I think it's an art, and in art discipline does help, but still you don't have to be too rigid, so I won't give "my" list of steps to perform (also because I don't have any).
February 9, 2008 at 2:02 PM
The idea of building software by gathering requirements, doing a monolithic design, and then implementing, is dead. And this is no news. Expecially, in games, where the requirements are constantly changing, due to the very nature of game design. Agile methods are not the solution to every problem, but they can't be ignored.
But I have to notice, that most of the times we, computer scientists, are too versed in the idea of building the optimal design from grounds up. We want to achieve the best possibile solution, the most clean, most elegant, most performant one by seeking the perfect design, and we can't start implementing things if we haven't reached this level of knowledge and enlightment about our problem.
The thing is that our design, whatever it was, is going to fail. And we will need to change it. And we don't want, because it was beautiful, we are emotionally linked to it, so we start patching, we start trying to reduce every problem so it fits in our original vision. And this is the beginning of the end...
We have to learn more about artists, about painters (or sculptors). We have to learn to sketch, then to paint in the major volumes, tweak, trash, redo, paint with large brushes always keeping the whole picture present, always having a "working" coarse grained version of our vision. Then refine. Change maybe our mind about some parts. Refine again. Start nailing in the details. It's very useful.
In the old days of computer paining, pixel art, this was not done. Many artists started from a corner, and pixel by pixel composed diretly the high-detail version of the picture. Now we have too many pixels, and possible colours, and noone works like that anymore. We have to learn to do the same. It's the complexity of the problems and the fact that you can't really foresee the final product from the very start, the reason to work in a iterative fashion. In fact, that's the same difference between drawing and painting, and you can easily see those different ways of working in different artist, i.e. Shiele and Klimt versus Caravaggio and Picasso.
Prototype. Iterate. Refactor. Don't be afraid of deleting parts of your code.
Overengineering is not better than underengineering. It is as bad, plus more wasted time.
"Kill your darlings"
2 Comments -
That was a good read, and some much needed advice. Nowadays, I find increasingly difficult to start a project, worrying about the "big picture" and "overall design" and spend too much time thinking about it before even writing a single piece of code.
It is difficult to guage how much planning to put in, just the right amount.
February 9, 2008 at 4:29 AM
I had the same problem. I don't like to start writing without having th complete knowledge of the problem, and of all the known solutions etc. My advice is, read a bit of stuff, then start a quick prototype, choose a prototyping language so you won't use that code in the final C++ product anyways (to avoid the prototry resign pattern). Hopefully the prototype will show you early problems in the design you was thinking of, and so you can think more, do another proto etc... This does not save you entirely from having a bad design in the end, you have always to iterate, but at least a first exploratory phase helps you choose the right direction. I think it's an art, and in art discipline does help, but still you don't have to be too rigid, so I won't give "my" list of steps to perform (also because I don't have any).
February 9, 2008 at 2:02 PM