Take the 2-minute tour ×

I'm planning to work/start on a few personal projects that could end up as my daily job. It made me think, which way should I start?

  • Just prototype—write just working basic code that could cost me tons of time optimizing and refactoring for easy expansion.

  • Write clean, optimized and documented code from the very beginning, keeping in mind that if after some time it won't be cost-effective, it will be dropped.

Update: Combining YAGNI with sunpech and M.Sameer answers makes perfect sense to me :) thank you everyone for help.

share|improve this question
see also: When to refactor –  gnat Apr 30 '13 at 22:39
add comment

9 Answers

up vote 31 down vote accepted

There is a third option ... write clean code via test driven development to implement the requirements that are needed today because YAGNI.

The temptation to write code that isn't necessary at the moment but might be in the future suffers from several disadvantages ... from You ain't gonna need it:

  • It leads to code bloat; the software becomes larger and more complicated. Unless there are specifications and some kind of revision control, the feature may not be known to programmers who could make use of it.

As a result, you should not just prototype ... nor should you write clean, optimized and documented code from very beginning, having in mind that if under some time it won't be cost-effective - it will be dropped.

Write the code that you need now knowing that you are then able to best meet the needs of today and tomorrow.

share|improve this answer
While I'm not a fan of full-blown TDD, this is always good advice since following TDD will force you to write clean, well-documented code. –  Wayne M Jun 2 '11 at 17:45
I think what he meant was he would drop the entire project if it doesn't pan out. If that is true then this answer doesn't seem different from "write clean code". –  Jeremy Jun 2 '11 at 19:07
@Jeremy, you're assumption right on my answer. But this answer is not that same. It is based on strict programming way where other one is based on experience, sure they look in some cases similar, but it's not the same :) well at least from the point i see it :) –  JackLeo Jun 3 '11 at 6:07
add comment

A colleague of mine enthusiastically endorses repeated prototyping, with the caveat that one must have enough discipline to throw each prototype away and write again from scratch - and not only that, ensure that one isn't influenced by the implementation details decided on last time round, as what one then ends up doing is writing the same prototype in a trivially different style several times. He semi-seriously suggested that if you were really attached to some brilliant piece of code that you couldn't possibly discard, that you should print it out, delete the source control repository, and post the printout to yourself - it'll be gone long enough that it can't infiltrate the next iteration.

share|improve this answer
this post is rather hard to read (wall of text). Would you mind editing it into a better shape? –  gnat Jun 16 '13 at 10:48
Can you suggest what you think the problem is? Perhaps the sentences are too long, as I've just noticed there are only two of them. Anything else? –  Tom W Jun 16 '13 at 20:17
add comment

Both are good. Both I like. They don't contradict each other.

I like to prototype. Prototyping is developing my creativity skills. I'm testing many possible solutions. Doing it quick gives me a possibility to test a lot of possible ways to solve problem.

I like to write clean, good tested code. It develops my core skills. I usually choose one of the prototypes, and either improve it, or rewrite from scratch.

But you should never mistake the prototype from the production code. Prototype should never go into production. It should be always marked as prototype. At best do all prototyping in your own branch.

share|improve this answer
add comment

There are two types of prototyping :

  • Evolutionary prototype which keeps evolving via enhancements and fixes to become the end product.
  • Disposable prototype which exists only to make requirements gathering and customer feed back more effective in early project stages and then get entirely dropped and the development of the end product begins from scratch.

According to Capers Jones, evolutionary prototypes produce low quality end products that will require much more effort and longer time to reach stability.

So if you are thinking about prototyping so the customer can see something as quickly as possible to help you get better idea and more details about the requirements, it's better to be a disposable prototype and have the development done on clean code later. If you cannot afford that, write clean code from the beginning and maintain it carefully but as others have suggested do not over-optimize and do not add things till you need them.

share|improve this answer
Very good point, thats for showing different types of prototyping, I haven't thought about it :) Food for a though for me here :) –  JackLeo Jun 3 '11 at 6:17
add comment

Write clean, optimized and documented code from the very beginning. I am incapable of doing that myself and it's a real problem. I'm not a coder, but I've worked for software development companies in customer facing management roles a fair amount and since they give me a lot of good ideas I occasionally build a prototype for something. Nearly every time that prototype then got handed to a developer who "cleaned it up" and turned it into a shipping product. When I check out the source, it will still be 80-90% my crappy code.

share|improve this answer
add comment

I'm reluctant to excuse dirty coding for any reason. In my experience, people who claim quick & dirty as an excuse for prototyping have that attitude towards any code, including production. If somebody creates a messy prototype, he creates mess in any code. Prototyping doesn't mean dirty coding, it means simplified assumptions to test the most important use cases. The code may not be formally tested, or take care of all details, but it should be still well designed, and well implemented. Cleanness is a sign of competence, competent programmers feel natural disgust towards messy code, no matter what its purpose.

share|improve this answer
Just one thing I forgot to mention. I've seen it again and again people were writing quick & dirty for "prototyping" purposes and it became painful & ugly for production purposes. Since once it's done and working, people keep adding bandages to it, piling mess upon mess. –  Gene Bushuyev Jun 2 '11 at 23:38
You got good point - "why re-write if it works?" is a problem for a lot of young companies, i see it even in my current job position when huge companies uses 10 year old CMS that is painful to upgrade to todays standards... Thats why I'm asking such question, I don't want to do a mistake here. Although your answer is mainly saying that i'm searching for an excuse to write sloppy code. No. sunpech and M.Sameer got my point. Prototype is to make something to see how world will react to it. If it works - make it good. –  JackLeo Jun 3 '11 at 6:11
add comment

If you are prototyping, why are you thinking about clean code? The very idea of prototyping is that it's meant to prove a concept or idea, and to be thrown away afterwards.

I'm going to disagree with most everyone here by saying that if you are already thinking about the choice between writing clean code or getting something done quickly for prototyping, choose the latter. Especially when you're talking about early stage development. I'm not saying don't ever write clean code, I'm saying get the idea out, see that it's the direction to go, then go back clean it up-- refactor.

As software developers, we get so caught up on doing things right and clean the first time, that we fail to realize that it's not code we're delivering, it's a solution to a problem.

I think of coding as I would writing a paper:

When writing a paper, we start somewhere, sketch out ideas, outlines, etc. It won't contain all the details or have any finished look to it-- it's essentially a first draft, followed by a second, and so forth. Much will be rewritten, replaced, and/or even removed along the way to a more refined and finished paper. (Obviously this analogy doesn't go so far as to say that code is ever truly ever finished or final like a paper.)

share|improve this answer
+1 Very good answer :) it happened a lot to me in early days so jumping on big projects can cause the same... thats what i'm afraid of. –  JackLeo Jun 3 '11 at 5:51
add comment

as usual...

It Depends

If you are prototyping to mitigate a risk or expose an unknown, just code it and expect to throw it away when you're done

If you are prototyping for iterative refinement, just code it and expect to modify and refactor it frequently

If you are starting to write the actual product but calling it prototyping so you can be lazy, then don't be lazy, and write it well the first time

share|improve this answer
+1 Great Post! I would add that while it may seem useless after you have developed that feature, NEVER throw away your prototypes. I always source control every prototype I work on because sometimes I refer back to them for tips and hints. –  maple_shaft Jun 2 '11 at 18:21
@maple_shaft: yes, "throw away" is metaphorically, as in "don't necessarily try to refactor it, plan on rewriting it" –  Steven A. Lowe Jun 2 '11 at 18:58
I say be lazy and write it well the first time so you don't have to go back and revisit it later. –  Blrfl Jun 2 '11 at 22:10
add comment

You can always start by making it work (at all), then revise it to make it clean, and then make it fast/small if it makes economic sense to do that. I would start with some experiments you throw away, then TDD it back into existence when you have a handle on what works.

share|improve this answer
add comment

Your Answer


