# Development from Scratch

DevFeed: [Development from Scratch](<https://devfeed.tech/articles/development-from-scratch-30317.md>)

Original publisher: [Read original article](<https://www.mdubakov.com/posts/development-from-scratch/>)

Published: 2006-07-21T15:41:57Z

Content type: article

Language: en

Sources: [Blog by Michael Dubakov](<https://devfeed.tech/sources/blog-by-michael-dubakov.md>)

Topics: [Development](<https://devfeed.tech/topics/development.md>), [Refactoring](<https://devfeed.tech/topics/refactoring.md>), [bug](<https://devfeed.tech/topics/bug.md>), [test](<https://devfeed.tech/topics/test.md>), [issue tracker](<https://devfeed.tech/topics/issue-tracker.md>), [Code](<https://devfeed.tech/topics/code.md>), [developer tooling](<https://devfeed.tech/topics/developer-tooling.md>)

Tags: [article](<https://devfeed.tech/tags/article.md>), [bug](<https://devfeed.tech/tags/bug.md>), [bugs](<https://devfeed.tech/tags/bugs.md>), [code](<https://devfeed.tech/tags/code.md>), [development](<https://devfeed.tech/tags/development.md>), [development-tools](<https://devfeed.tech/tags/development-tools.md>), [refactoring](<https://devfeed.tech/tags/refactoring.md>), [test](<https://devfeed.tech/tags/test.md>)

## AI overview

The article examines problems that can arise when developing a new product version from scratch instead of refactoring an existing product. It recommends using pilot projects when adopting unfamiliar technologies, carrying forward bug and test-case knowledge, and refactoring reusable code before incorporating it.

## Source excerpt

When you developing new version of a product you usually think about rewriting from scratch instead of refactoring and adding new functionality with help of hummer and nails. Lets skip questions "why we should" and "when we should" because each of them is a topic for separate article. We will discuss potential problems and possible solutions for "development from scratch" mode. Usually, the first problem is development environment change and new development tools. When you move from one programming language to another or change technologies, third party libraries or something else there is always a risk of potential problems with it. That is why you shouldn't start using new technology/language before you have at least few experts in it. In general the idea to learn new technology/language by developing a real important project is bad. Pilot project should go first and in pilot project you may resolve all potential technical problems. It is better to blog about pilot project progress and problems, in this case you can always obtain list of problems/solution. The second problem (and the most significant) is that development from scratch leads to repeating bugs and issues that were already fixed in previous product. The simplest way to solve this problem is try to repeat all issues from previous version of product in current version It's possible if you used Bug Tracking practice, but if not, you are in troubles. And in any way it will be hard, because there can be thousands of issues. Also it doesn't insure against new issues in a new product. Another way is usage of Test Cases from previous project. If project was developed accurately then every idea, every business rule, every potential issue was reflected in proper Test Case. Usage of Test Cases from previous product version helps control quality from the start. The third problem is should you use or not some parts of code from previous project. On the one hand you save time by reuse already developed and tested c