Agile Software Development

Know What Not to Build in Software Development

The more you can create from scratch, the more proprietary genius you get to hold up for the rest of the world to admire. But realistically, time and resources are limited in software development, and you cannot and should not try to build too much. In an article at freeCodeCamp, Jonathan Solórzano-Hamilton shares tips for how to not waste time writing the wrong code.

Focus on the Core

Trying to build too many aspects of a product from scratch incurs many problems. One of them is security; will you really always be able to keep the product up to date against new security threats? Another issue is that trying to build too much from scratch is just an inefficient use of time. Great open-source and/or off-the-shelf solutions exist to be used. If you decide to build from scratch anyway with an attitude of, “It’s a great learning opportunity,” then think again: It might be a good learning opportunity for you, but it might also be a waste of time and money for the business funding your little learning experience. Do what is right for the business and the product.

Besides, as Solórzano-Hamilton notes, third-party solutions offer several major benefits:

  • You get access to features more quickly.
  • You are signing up for automatic improvements and new features as they are released.
  • You will have chances to give back to the community, in cases of open-source packages.
  • There will be less technical debt.

The only part of a product that absolutely must be built from scratch every time is the differentiating aspect, the secret sauce that makes it valuable. Valuable products do not need to be fully custom-built; it only takes a kernel of difference to create that value. Refrain from reinventing the wheel.

Lastly, about finding and identifying packages to deliver your product, Solórzano-Hamilton recommends checking out GitHub and Stack Overflow. He also says this:

Language-specific package repositories exist as well, including NPM for JavaScript, for Ruby and Rails, and for .NET development.

Browsing the source, you will need to identify which packages will be viable for your product. The first indicator I examine is ongoing freshness. When was the last update? How many people help maintain the repository? How many of them are active?

Next, you need to make sure that the license is compatible with your product. Some licenses may impose additional obligations on you as a user of the package. The MIT License and Apache License 2.0 are usually safe choices. They impose few commitments on you (but you still have to comply with the license, however minimal).

For additional thoughts on what and what not to build, you can view the original article here:

Show More

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.