Averrous Saloom
Being an Engineer by Averrous

Being an Engineer by Averrous

Software Engineering in a nutshell

Software Engineering in a nutshell

Averrous Saloom's photo
Averrous Saloom
·Apr 21, 2022·

3 min read

Subscribe to my newsletter and never miss my upcoming articles

softwares, from author’s recent apps list

Software engineering is different from programming. It does consist of programming tasks but it is scaled in time, space, and human resources it needs. Programming is creating rules or procedures so that a specific goal is achieved. Software engineering knit these programs with selective techniques so that it fulfil the software requirements. Which are usually a combination of verbs and its quality behavior. We can see an example of these requirements:

  • respond ___ in below 100ms
  • save ____ without any loss but take storage less than 2 MB

Achieving this verbs and its quality behavior takes multiple tradeoffs. To make an app respond to a request in below 100ms, an engineer can choose to make sure each user request sent to a server that has maximum 2000 Kilometers distance to the user position. This choice can cost the engineer huge pile of cloud credits as they have to established server in every region. So, as any rational engineer do, she will try to find other method to achieve the requirement, e.g. by classifying which are the most important information in the payload and serve those in a distributed cache. This choice will cost the engineer more development time. She has to do a trade-offs between these two possible choices, and try to pulled out the best.

The choices in real world system are more than two. Which means there has to be an analysis tools so that we can take the best out of all. This tool can be an evaluation function (inducting value), takes perfomances as parameters and return its value for the projects. Or, it can be a pattern (deducting value), which has been tuned up for specific types of purpose.

Inducting if a system is good can be done by computing some parameters. One example is cohesion and coupling. Here, a software engineer has to analyze if components in the system have low coupling and high cohesion. With low coupling and high cohesion, probability of a system break when there is a change in a component is getting lower.

Deducting if a system good can be done by patterns and rules. One example of pattern is Observer pattern. In the observer pattern, there are components that are publisher and there are components that is subscribers. With this type of pattern, functionality like social media timeline can be achieved. Usually, patterns have had deep documentation about how to design and implement the system with best practice. This also helps other engineers to understand our system better.

Examples of rules are DRY (Don’t Repeat Yourself), KISS (Keep it simple stupid), and many else. These rules are useful to keep the system and the codebase under a certain standard.

Software engineering is programming scaled up. It is harder as it requires lateral thinking. A software engineer has to think widely and deeply about the problem and its solutions.

Sign up for our Free Weekly Newsletter. Fresh content from developers all over the world, fresh and direct from the field! Don’t forget to follow our publication The Dev Project.

 
Share this