Don't Fall For Reusable Code Promises

Founders often ask me, “If there are so many lines of code already created, why not reuse it and save on development?” It's a fair question and the answer is both yes and no. Let me explain.

Yes, reusable code can simplify development, especially when there's relevant experience and common features involved.Many features tend to logically repeat across projects, and a variety of services now offer REST APIs, which eliminate the need to reinvent the wheel. After all, a REST API is essentially pre-written code that we’re reusing. This can be especially useful when the goal is to quickly put together an MVP (Minimum Viable Product). In such cases, you might pull together code from various sources to get something up and running quickly. However, keep in mind that you’ll often need to rewrite everything from scratch as the project evolves.

Let’s consider an example: Imagine you’re building an e-commerce platform. You might use a REST API to handle payment processing. Instead of writing a payment gateway from scratch, you integrate a well-known API like Stripe. This API is essentially reusable code that takes care of all the complex logic of processing payments, fraud detection, and even handling multiple currencies. It saves you development time and ensures you’re using a reliable, tested solution. But even in this case, you’ll need to customize the integration to fit your platform’s specific needs, such as aligning with your UI, handling unique transaction flows, or integrating with your database architecture.

That said, there are a few key reasons why the notion that 70% of the code can be reused doesn't hold up in most cases:

1. Code Ownership: Code from previous projects is typically the intellectual property of the client. This means it can’t be used in other projects, even if it seems like it could fit. For example, if you previously developed a custom inventory management system for one client, you can’t just copy that code into a new project for a different client, even if they need something similar. Intellectual property rights are taken seriously in custom app development, and the reuse of client-specific code without permission isn’t just unethical—it’s illegal.

2. Project Uniqueness: Even when projects share similar functionalities, each one is inherently unique due to differences in infrastructure, project architecture, database architecture, and technologies used. For instance, suppose you previously built a recommendation engine for a streaming service. You might be tempted to reuse the core logic in a new project for an e-commerce site. However, the streaming service’s recommendation algorithm was tailored to media content and user behavior, while the e-commerce platform might need something entirely different, such as product recommendations based on purchase history, which involves different data structures and business logic. Customization will be required to adapt the code to fit the new context.

3. Customization Needs: When using open-source code or code snippets from external sources, you still have to rewrite about 70% of it to fit the specific needs of your project. For example, let’s say you decide to use an open-source library to add a chat feature to your app. While the library provides a solid foundation—handling the basics of sending, receiving, and storing messages—you’ll likely need to modify it extensively. You might need to change the user interface, integrate it with your existing authentication system, or adjust how messages are stored to align with your app’s security requirements. While the core algorithm for messaging is in place, adapting it to your project can be a significant task.

So, while reusing code can be a time-saver in some cases, it’s not a magic bullet that will drastically cut down development time. Each project is distinct, and the custom nature of app development means that most of the code will need to be written with that specific project in mind. Yes, experience and existing code can provide a foundation, but there’s no avoiding the hard work of crafting something unique for each new project.

In the end, the goal isn’t just to save time but to build something that works reliably and effectively for the specific needs of your project. Quality, security, and performance should never be sacrificed for the sake of convenience. So, while reusable code has its place, it’s just one part of a much larger process.