It seems like you are using an ad blocker. To enhance your experience and support our website, please consider:

  1. Signing in to disable ads on our site.
  2. Sign up if you don't have an account yet.
  3. Or, disable your ad blocker by doing this:
    • Click on the ad blocker icon in your browser's toolbar.
    • Select "Pause on this site" or a similar option for lancecourse.com.

4 Considerations to build strong software

zooboole

Published By zooboole

Clients love strong software. Everyone loves stable software. And strong software does what it's meant to do. Strong software never breaks once in use and reacts less even its environment undergoes minor changes. Strong software is maintainable, extensible, and scalable.

My clients know I always meet such standards in building products. And I do the same for my products. I have met a few developers who would work on software and leave lacunas to win other deals behind. I love building a strong living tree to avoid the stress of clients calling me and complaining. I value my mental peace more than a fee, and that brings me more income.

Well, because of that most friends used to ask me how I go about doing that. Usually, when I am tasked to build software I set goals. Achieving those goals helps me in the planning stage. And, all the goals must lead to one thing: build software I or someone else can easily control at any moment in time.

The Four Goals:

1. Language Agnostic

All languages in the same family should be able to help me develop the project. All languages have their strengths in specific areas. You can't use HTML for backend development, but you could well use C, PHP, Nodejs, Python, Ruby, etc. These are groups I call languages of the same family. For a given project, they can be used interchangeably. For that, I have the choice to use the one I am most comfortable with. An Obvious Choice. I apply this to all aspects of the project: front or back end, Databases, etc.

Tip: I always pick the tech stack I am more comfortable with. This way, the technology will not get on the way of your mental processes.

2. The Next Team or The Next Me

Once the tech stack is selected, I have to think of the next team in the future. I must confirm if my choices are viable for the farthest future possible.

What I meant is to make sure my choices live the longest possible. I need to confirm whether the languages I chose can still be in good use for at least the next five to ten years without any worry. Also, to that, I must make sure that during all this time, anyone should be able to continue the work without any issues.

Tip: Make sure the tech stack can withstand time, and there always be developers who can code in the stack.

3. Architecture & Flip-Flopping

To achieve the goal of making various team work on the same project over time requires great organization. For this, I always go for the simplest organization possible. Never, never overload.

The reason is simple. As the first team on a project, you are only doing the scaffolding. Your architecture should be the foundation for the next team. Here, even the next "you" would usually be better than the "you" today. "He" would, in the near future, have a better solution for most of the things "you" has done today.

In the worst case, the next team should be able to make a replacement of what needs to be replaced without being forced to break every other part. Or, even if they have to get rid of your entire code, the logic that has been your foundation should always be reusable. And your whole organization shouldn't be hard to get rid of.

Tip: Simplest architecture possible. This also supports CLEAN CODE.

4. Longevity

Since I target such a long time I need to make sure the software remains relevant. To achieve that, simplicity plays a considerable role here again. The environment can influence the life of the software. So, you need to go for tools that are mostly cross-environment or environment-agnostic. Another important thing to target is to build bug-free software. Once the software reaches a stable release, it should not misbehave in any way.

Tip: Test a lot to build bug-free software. Then get the right environment for it to avoid misbehavior.