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.

5 Quick Considerations to build strong software

zooboole

Published By zooboole

Clients ( and everyone) love strong software. Strong software does what it is meant to do. Strong software never breaks once in use and reacts less even if its environment chacks a bit. Strong software is maintainable, extensible, and scalable.

Most people(clients) know me to love such 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 to build a strong and living tree to avoid the stress from a client who would be calling me and complaining. All options are a matter of business model though. I value more my mental peace than a fee, and I believe that that creates more funds for me ahead. I do respect other people's options as well anyway.

Well, because of that most friends use to ask me how I go about doing that. Because, once I launch my websites, they remain alive until I decide to upgrade them in some way. And that has never been a headache or any complicated task. And the marriage between the existing application and new upgrades is usually a joyful moment.

Usually, when I am tasked to design software I set goals that I must achieve to satisfy both my client and their users which help me in my planning stages. My main goal is to always build software I or someone else can easily control at any moment in time. Then come other sub-goals such as:

1. Language-agnostic

All languages in the same family should be able to help develop the project. All languages have their strength in specific areas. You can't use HTML for backend development, but you could well use C, PHP, Nodejs, Python, Ruby, etc. Those are what I call languages of the same family because for a given project they can be used interchangeably. For that, I have the choice to use the one that I am the most comfortable with. An Obvious Choice. Or at least people testified the efficiency of a particular one on my specific need. I apply this same rule on all sides of the project: front or back end, DBMS, etc.

2. The Next Team or The Next Me

Once I take into consideration the language I am most comfortable with, I have to think of the next team in time. I must confirm if my choices are viable for the most distant future possible. What I mean is to make sure my choices live the longest possible. I need to confirm if, with the trends, the languages I choose can still be in good use for at least the next five to ten years without any worry. In addition to that, I must make sure that during all this time, anyone should be able to continue the work without any issue.

3. Architecture & Flip-Flopping

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

The reason is simply that 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/She" would in the nearest future have a better solution for most of the things "you" has done today.

Try to be futuristic, think of what the software could become or how it could be used later.a

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 other parts. Or even if they have to get rid of your entire code, the logic that has been your foundation should always be reusable. And worst of all your whole organization shouldn't be hard to get rid of.

4. Durability

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. Since the environment influences a lot the life of the software, you need to go for tools that can be or are mostly cross-environment. Another most important goal to target is that once the software in production it should not bug. Maybe for the first days of use. Once those bugs fixed, the software should be free from any misbehavior.

5. Time Allocation

Dedicate enough time to your thinking. From the beginning to the end of the work. Make sure you go through the majority of possibilities for every situation. It's important to do so to achieve the goals above. Do not blame or condemn yourself for not getting a solution yet. Keep thinking of it and explore as many as possible possibilities. In case nothing serious comes out and you need to get something done, use simple implementations that can always and easily be replaced incognito.