Quote:
Originally Posted by Noodle Wazlib
general best practices question: is it advisable to write a lot of code that you know will have to be changed later?
for example, completely styling a website wrong, that you will need to completely redo later, just for the sake of it not looking ugly during development
good? bad? neutral?
It depends. I'm a "back end" developer but over my life I've been more of a full stack dev in many occaisons, and even now I will often make some kind of front end to demonstrate backend work, to prove to myself and others that the backend supplies everything that would be needed for a front end.
I almost always start with a completely stupid front end. Black and white, no css, no javascript, text, tables and links. Zero frills. This is partly because I am almost never able to visualize the features I want until I start working. To me if you start with the interface you box in everything else too much.
However, I recently came across a principle which is, no one likes to look at ugly prototypes. Kind of like if you sell a house you have to paint it all white even if you know the first thing the buyer will do is repaint everything. Because people don't visualize themselves buying a house if it's ugly. So, people like your demos and become excited about your project if it is nice and slick, even if it doesn't do much or isn't much like what the final project will be like.
So in closing, programming is a land of contrasts.
Personally my prototyping principle is - make it work first, no matter how ugly. Prove it works with tight testing. Then start refactoring into something nice, while still meeting all your tests. It's an extension of the general advice to avoid premature optimization. Like in C++ when I start a project it's all public functions, no const, try to keep the algorithms as obvious and stupid as possible, etc, etc. Once it works I almost start over again.