At some point a program is in development. Features are being added or removed or changed all the time. Every version is nothing but a prototype.
So I don't waste much time on writing super clean code at that point because I never know how long something lasts. Of course I try to keep the code quality to certain standards, but time is always an issue.
Then comes the point where the program is finished and the decision maker(s) say "that's it". I do have a working prototype at this point, but the code inside is a bit messy from all the back and forth during the development phase. I am expected to start testing/final debugging but my gut says I should now somehow clean up and or rewrite stuff to give it proper architecture that makes maintenance etc easier.
Once stuff has been tested and approved, it makes no sense to rewrite then.
On a regular basis I am standing there with a working 'finished' prototype and I get a bug during testing and I see that it is a result of not-smart coding which is a result of the whole development process.
I am in the middle of testing and the bugfix would be a rewrite… it's a mess!
There are better/textbook ways, I am sure. But i have to work in a real work environment where not everything is textbook.
So how do I transition my working prototype to a release version with a stable code base ?
Maybe I should not consider the development finished once I do and actually see it as the clean-up phase… I don't know, I need help here.
EDIT
I want to clarify a few things.
-
I am 100% on the side of doing it right before and not after, code clean and readable.
But i also have to get things done and can't dream about the beauty of code all clean and shiny. I have to find a compromise. -
often a new feature is really just something that we want to try out and see if it makes sense to implement something like this. (esp. in mobile apps, to get a real look-and-feel on an actual device)
So it is something small that (imho) does not justify too much work in a first "let's see" iteration. However sometimes the question arises WHEN do i pay this tech.debt ? That's what this question is all about.
If I know that half of the features will be dropped one day later (enough experience in our company by now) I really find it hard to believe that the best way to approach my problem is to nonetheless invest extra time to write everything clean even if most of it will be dropped shortly after. It feels to me that I will save time if I do one big cleanup once the thing is solid, hence my question.
Best Answer
Not knowing how long something lasts should never be an excuse for sloppiness - quite the opposite. The cleanest code is IMHO the one which does not come into your way when you have to change something. So my recommendation is: always try to write the cleanest code you can - especially when coding a prototype. Because it will be much easier to adapt it when something has to be changed (which surely will happen).
Don't get me wrong - my understanding of "the cleanest code" has nothing to do with making code beautiful for the sake of beauty. That is indeed something which can slow you down. In my point of view, clean code is code which is mostly self-explaining (no need to write so much docs - causes speedup), easy to understand (less errors, so less debugging needed - speedup, less time needed to find the correct place to alter - speedup), solves the given problem with the least amount of necessary code (less code to debug - obvious speedup), is DRY (only one place to change when something has to be changed - speedup - and less risk to introduce new bugs by forgetting to change a second place), follows coding standards (less cumbersome things to think about - speedup), uses small, reusable building blocks (which can be reused for many features or even prototypes - speedup), and so on.
Doing "cleanup" afterwards never works. Consider you cleanup before you implement a new feature, or when starting to implement it, but not afterwards. For example, whenever you start to touch a method for a feature, and you notice it gets longer than 10 lines, consider to refactor it into smaller methods - immediately, before getting the feature complete. Whenever you detect an existing variable or function name you do not know exactly what it means, find out what it is good for and rename the thing before doing anything else. If you do this regularly, you keep your code at least in a "clean enough" state. And you start saving time - because you need much less time for debugging.
... which is the actual proof for what I wrote above: being "dirty" haunts immediately back on you when you start debugging your code and will make you slower.
You can avoid this almost completely if you do the cleanup immediately. Then bug fixes will mostly mean small changes to the code, but never a major architectural change. If you really detect evidence for an architectural improvement during testing, delay it, put it into your issue tracking system, and implement it the next time you have to implement a feature which benefits from that change (before you start with that feature).
This takes some discipline, and some coding experience, of course. It is a similar idea like the idea behind "test driven development", doing these things beforehand instead of doing them afterwards (TDD can help, too, but what I wrote works even when you do not use TDD). When you do this consequently, you will not need any special "clean-up phase" before releasing.