Prototyping vs. Clean Code at the early stages

Question

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.

Answer 1

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.

Answer 2

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

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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