Road to Software Engineering

Software engineering is a form of art which is not a very common practice among new developers yet. To be a software engineer, you have to start thinking critically.

We often tend to jump into coding instead of thinking about it. We think that the faster I start coding the faster the project will be finished. Trust me this is never the case. The faster you jump to code the faster you are going to mess up the whole project.

Most of the time the requirements are misunderstood. Best way to be sure that you understand the requirements, you should talk with your team and explain what you understood, this way not only you but also your team get to fix any misunderstanding in the requirements. It’s always a good idea to start with a prototype, it can be as simple as a sketch. With the sketch everyone can visualize what they need to build an reach a common ground of understanding.

Once you know what you are going to make you need to start thinking about how you are going to make it. Think about the critical points. Not some login mechanism or registration. Think about the unique parts of your project and try to make a model in your head that you can call a kernel/core . That’s going to be the heart and everything you make should be able to just be plugged into the core/kernel. Now plan how the kernel should be. It has to be robust and very dynamic. Because it should be able to understand new features that it has no clue about at this time.

What kernel does is, it gives you a standard for future features. It kinda guides you to how the features should be developed. Without this restriction you would have developed features that isn’t smart enough to co-exist. This image should be able to explain this problem better.

This happens if you start coding a feature without thinking about other features.

So it’s really important to have a grasp of the whole project before you jump into coding otherwise you will end up like that bridge. The only solution for issues like that is to break down one side and rebuild which basically adds development time which you wanted to avoid in the first place.

Think out of the box.

It’s very common to get change request later. If you didn’t develop a standard core/kernel that can be configured to add a new feature, you are pretty much screwed. If you have to rewrite another feature just to add a new feature, you won’t be able to go much further with the project. It will start looking a lot more like Frankenstein’s monster.

At some point you will just declare that this code base can’t be updated any further without breaking something else.

Always think about the future. Sometimes when brainstorming it becomes very obvious that there will be these kinds of change request. So plan ahead. Because “A Stitch in Time Saves Nine”.