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.


10 Answers 10


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:

  • The time spent is taken from adding, testing or improving necessary functionality.
  • The new features must be debugged, documented, and supported.
  • Any new feature imposes constraints on what can be done in the future, so an unnecessary feature now may prevent implementing a necessary feature later.
  • Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work correctly, even if it eventually is needed.
  • 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.
  • Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a snowball effect towards creeping featurism.

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.

  • 4
    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. Commented Jun 2, 2011 at 17:45
  • 1
    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
    Commented Jun 2, 2011 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
    Commented Jun 3, 2011 at 6:07
  • 1
    @JackLeo I think the point is that once you reach a certain level of experience there stops being a difference between "code I worked hard on" and "code I just wrote."
    – Ant P
    Commented Aug 14, 2017 at 11:33
  • @AntP Indeed. It's interesting to reflect on this question 6 years later :)
    – JackLeo
    Commented Aug 14, 2017 at 11:58

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

  • 2
    +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
    Commented Jun 2, 2011 at 18:21
  • 1
    @maple_shaft: yes, "throw away" is metaphorically, as in "don't necessarily try to refactor it, plan on rewriting it" Commented Jun 2, 2011 at 18:58
  • 2
    I say be lazy and write it well the first time so you don't have to go back and revisit it later.
    – Blrfl
    Commented Jun 2, 2011 at 22:10
  • 3rd sentence made my day. Commented Aug 14, 2017 at 19:59

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.)

  • +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
    Commented Jun 3, 2011 at 5:51
  • "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'd say is the other way around: "We never have time to do it right but we always have time to do it over". Commented Aug 14, 2017 at 20:01

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.

  • Very good point, thats for showing different types of prototyping, I haven't thought about it :) Food for a though for me here :)
    – JackLeo
    Commented Jun 3, 2011 at 6:17
  • Agree with the point! Commented May 15, 2015 at 16:37
  • Big risk of disposable prototype is that management will have trouble understanding why the production version should take so long compared to the prototype and why the work on the prototype should be “wasted”. Of course if it's your own might-be-startup, there is no such management, so that makes it much easier.
    – Jan Hudec
    Commented Aug 14, 2017 at 11:04

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.

  • 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. Commented Jun 2, 2011 at 23:38
  • 1
    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
    Commented Jun 3, 2011 at 6:11

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.


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.

  • this post is rather hard to read (wall of text). Would you mind editing it into a better shape?
    – gnat
    Commented Jun 16, 2013 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
    Commented Jun 16, 2013 at 20:17

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.


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.


I tend to say that extremes are almost always bad.

I advise to keep the balance between clean, well documented and prototyping. When you develop for a library or platform you don't have experience with I go more into the prototyping direction. That's especially true at the beginning and for platforms, e.g. Android or containers, that put you into their corset. That means that you implement their interfaces and they call you.

From my own experience most of the code doesn't live very long. That said, get going fast by implementing your feature. When sooner or later (most of the time sooner) you need to rework/refactor your existing code because of the next feature you tidy up especially parts that are complicated working with. Pay attention to have proper automated tests to make hassle-free refactoring possible. Pertaining the above mentioned platforms like Android: often they make automated testing not as easy because of close coupling and no design for testability. Then you can lift your test base to a higher level, e.g. integration testing.

I wrote an article that might give some hints about starting: https://medium.com/@ewaldbenes/start-lean-why-its-best-to-split-your-next-coding-project-by-feature-70019290036d

Not the answer you're looking for? Browse other questions tagged or ask your own question.