Making things just work and then improve them, or attempt to make them "perfect" from the beginning?

Question

I don't have any experience working as a programmer - I just code as a hobby so far. Some years ago, I heard a programmer say that I should focus on making my code just work despite being slow (it was for a game, so it was more noticeable if my code was slow or not) and then I would spend my time improving it to make it fast and better.

I wonder how often is that advice applied in actual working environments. Do you make something that (barely) works and then spend the rest of the time improving it, or do you make it "perfect" (or acceptable) from the very beginning without looking back?

I'm assuming that the difference between these is that one is more about writing the first solution that comes to your mind, and the other is about carefully planning and thinking what you're going to write - supposing that the latter is, well, significantly slower than the former.

Answer 1

You have heard only part of the idea. Several iterative methods, such as Test-Driven Development (TDD), recommend that you should make your code work (for TDD: pass the tests) as early as possible. The point is that you can gain feedback earlier in the programming process and adapt your design to the real needs.

In actual working environments, this pattern of making a workable but imperfect implentation, gaining information with it, and then improving and gaining new information is used heavily when you do any Agile programming. The crucial point is that you don't do it for the sake of rework, but because the requirements are not clear at the project start and there is simply no way to get an acceptable result from the start because "acceptable" isn't defined yet.

The concept has very little to do with less careful planning and thinking. It just acknowledges that planning and thinking are often quite useless when you and the user's cannot see the half-finished product and get feedback early.

Answer 2

My quick advise would be that, if you can, try to be the closest as possible from the second choice.

Though, if you are new to something, if you can get it to work first, it's already great I guess.

Why do I discourage the 'as long as it works!' way of thinking? Well … most of the time, you are the one who will have to maintain your code, to understand it even in six month without having touched to it for months, etc. So if you have to spend hours, get some headaches, just to understand your code again (and then only you'll be able to work on it again), that's a bit dumb. How way more pleasant it is when you have taken a bit more time to make something better and then you'll no longer loose your time when you'll have to work on it, etc.

And even though, it wouldn't be you who would have to work on it in the future, think to the others, as it is even harder to understand someone else's code.

And yes, coding properly is also often opposed to 'get it to work and that's it'. If your code isn't easy to understand (maybe thanks to some comments in addition) then it's more likely that it isn't that well coded at all.

Answer 3

Perfection costs a lot more money than "works", and all that money needs to be spent before the product is shipped to a customer. Many a perfect product has never been finished - never been used by real user to solve a real problem, because the developer lost interest of ran out of money before he got there. The other extreme -"make it just work" means you risk spending all your time fixing defects on a poorly structured ball of mud. Many a customer has found the developer has lost interest and/or run out of money fixing the ball of mud.

So the reality is a balance needs to be made. It needs to be good enough to be to reliable enough to be usable, and good enough to be maintainable, without being perfect. In my 30+ years experience, "perfection" is a bigger reason for product failure than "balls or mud".

Agile, TDD are considered modern methodologies that address the problem of finding that balance, by addressing the issue at the micro level (e,g, sprints), and stopping once a quality metric determines its "good enuf" and "fit for purpose" it is often assumed that the macro is also addressed (e.g. Shipping a new airline billing system). However, at the macro level, non technical (legal, business and other considerations) often prevent such an approach working as well as some evangelists promise.