The Art of Software Engineering

What makes a good software engineer? How does a software engineer make a lasting impression in such an unstable and fast paced industry? Modern consumers are enraptured by technology and constantly scramble to get the latest cutting edge update. Software engineering was created as a means of supplying this constant demand and is maintained through refinement and consistent, stipulated quality.

Technology evolves quickly with fundamental advances but also tends to be unstable at its inception. Cell phones are a good example of changing technology. The state of the art in cell phones has quickly evolved from the simple brick phone, to flip phone, to QWERTY phone, to smartphone within a few years. Each new release seems to be quicker and quicker as market pressures force brands to compete for buyers. Each release also pressures competitors to increase their production rate and the technology that is publicly available.

It is disappointing if the latest gadget is of lesser quality than its predecessor. As we continue to develop technology and make new discoveries, it is important for us to take a step back from the burn down charts and the weekly deadlines and take a moment to understand the big picture.

Quality is the driving force to lasting customer loyalty. Engineering is the act of working artfully to bring quality in a measurable and consistent manner.

Engineering is an art refined over time

Civil and software are both branches of engineering. What we learn from one can be applied to the other. The walls around a fort are built so that if one fails or is compromised the next wall is still standing up.

The same applies from a security point of view to software architecture. We also use the same principles when we eliminate single points of failure from an overall software architecture perspective.

Unlike technology, engineering evolves slowly and develops permanent advances in ways of working — sometimes called best practices. It focuses on accurate measurements, and yields consistency and continuous improvement. Design patterns in software are a good example of engineering. Design patterns are generic solutions to problems that software developers have faced during software development. These solutions were obtained by trial and error by numerous software developers over quite a substantial period of time.

Engineering is Quality and Punctuality

While engineering has and will continue to mature over time, an engineering project needs to be delivered with a pre-agreed quality and within a pre-specified time. For example, a bridge is designed and built to handle a certain wind load, vehicle load, seismic strength — and is delivered within a pre-specified time period, typically between 1 to 3 years. Similarly, engineers of a software product agree to satisfy certain technical requirements to their clients or stakeholders and give a time by which to deliver the product.

In contrast, scientists need to aim for very high quality, while the timelines can be elusive. The covid vaccine is a good example of great quality without a pre-specified timeline commitment.

The vaccine has helped mankind see the light at the end of the tunnel. However, to achieve this, the vaccine developers were not able to set a specific timeline at the beginning of their research, given that there was no established way to determine the completion time. They also did not have a preset efficacy rate that the vaccine must reach, but rather had to aim for the highest percentage they could with their given tools. Software engineering, like civil engineering, is about delivering pre-agreed quality within a pre-specified timeline, both factors which differ from research and development.

Software Engineering Goals

While timely deliveries are a priority, they are not what makes a product noteworthy. Meeting deadlines may improve your chances of getting new customers but it will not ensure that they return. As a result, in addition to prompt deliveries, software engineers need to be mindful of and should regularly strive to work on the following:

  1. Writing accurate, bug free code
  2. Verifying that the code is efficient and runs quickly
  3. Setting up systems to ensure that the code is easy to maintain
  4. Designing the software such that the service is available for use without interruption
  5. Creating modular and reusable code — this increases the efficiency in which updates can be delivered
  6. Designing security systems to hide sensitive information
  7. Developing systems that are easy to expand to include additional functionality
  8. Periodically upgrading to latest stable version of code libraries and technological components — this is also a good security practice

Key Components of Software Engineering in the Industry


Scalability refers to how many users can be serviced simultaneously; for software engineering, this is measured in transactions per second (TPS). This is an important part of creating your product and making sure that it can be scaled up for a potentially greater user base. A pertinent example of how important this is, occurred when the US government attempted to set up a website for people to sign up for a healthcare program, but the site was not built to handle traffic of that size so it crashed. Thousands of people were unable to get access to healthcare because the software was not built to account for scalability.

Horizontal vs Vertical Scaling

Another pertinent example for scalability is this. If you are in charge of running a pizza restaurant then you have one of two options: upgrading your current oven to be larger or getting more pizza ovens of the same size. In this scenario, getting a bigger oven is known as vertical scaling, whereas getting more ovens is known as horizontal scaling. The upside for vertical scaling is that you might be able to produce more pizzas from one oven but a downside is if the oven breaks, your entire operation is jeopardized. The positive of horizontal scaling is that you can have more variant pizzas at different settings in different ovens running at the same time. However, maintaining it is more difficult due to the quantity and you may need more cooks to make it work.

In software terms, you would want reasonably sized individual server pods (ovens in this example) and several of them for horizontal scaling. More server pods yield better availability so if one stops working or needs maintenance, the others are available. It also saves money, additional pods can be used as and when required.

Enforcing Limits

If the dataset that can be held in memory per server cannot exceed a specific size, limit input to that. Failing to do so will make a server run out of memory and crash only when the actual dataset in production is large. The image shows a height restriction barrier — one more example of a concept in civil engineering that can be taken into software engineering.

Build systems that chunk the data set into smaller sizes and can process the complete data set. Networks do this constantly by breaking up data into smaller packets so that a network system can more easily manage the data that it is receiving. The same concept is used in streaming parsers (compared to DOM parsers) in software. This is over and above rate limiting the requests per customer.

Appropriate Technology

Is the software built using appropriate technology? With sharper technology one can easily meet customer expectations, but there is a trade off. If you go overboard, the time and money spent in setting up superior technology may not yield the right commercial return.

For example, in certain cases what can be done using big data technology can also be accomplished using databases, especially when the data size is not huge. Your organization needs to spend money setting up or leasing the infrastructure and pay a small army of engineers to understand it fully. Until the data reaches that critical point, the cost of big data might not be justified.

Engineers are always discussing the most efficient and ideal technology to use for their situation. The ideal solution considers all the previous points made as well, such as scalability but also the cost of continuously maintaining the technology.

Total Time Spent

This is the time it takes for a person to complete all interactions from the time they start using the program. The goal of most applications is to minimize the amount of time that the customer spends on it. This ties into the concept of having a “black box” for the consumer, where they are shown the minimal information they need in order to use the product.

The functional flow of the software needs to be such that it does all background tasks while the user is filling out the next detail. Background tasks could be identity verification, credit score checks as well as loan eligibility calculations; this ensures the user is not waiting for processing.

However, one must also consider that if the user decides to close the application preemptively, then the time spent processing earlier was wasted. A good engineer incorporates background processing at the correct steps to make sure that unnecessary processing does not occur while minimizing time.

User Expectation Management

If you are creating a loan application processing product that checks your credit score with a credit bureau as part of the workflow, yet if the bureau’s processing service is currently down how do you want to handle that?

The right technical answer might be to use the circuit breaker pattern to weed out the failed bureau and switch to a different way to do the credit processing instead.

What does that mean from a user perspective while the situation is handled? Here are some possibilities:

A) Let the user wait, show a loading icon until then, this may go on indefinitely.

B) Shut off the loan processing application.

C) Tell the user you have contacted the credit bureau, it’s taking time, check back later.

D) Use an alternate credit bureau. Record that as part of the processing log. Message the user that the outcome is subject to review.

If you choose wisely, you would have serviced customers well in a less than ideal situation.

Between choices A, B and C, C is the most desirable when an alternate source cannot be used per business rules.

The benefit of choosing option C is that there is transparency with the customer and they feel more confident about receiving an update. Whenever a business need is denied to the customer, it’s best to show transparency and inform them that the issue is not occurring on your side and that your credit bureau is working on it from their end. This will further help to make sure the customer does not lose their trust in you.

Choice D is recommended if an alternate source can be used. You must also keep in mind that having an alternate source would also be more costly since you are paying for two services rather than one.

Final Thoughts

Software engineers need to have a background in science, use appropriate technology, have a focus on quality and deliver their products on time.

Software needs to be built with an acceptable quality and within a predictable timeline. The benefit of mastering the different facets of engineering is to maintain a consistent and positive relationship with your consumers and clients. It ensures confidence in your work and is more likely to attract future customers. It is something that has been honed and slowly perfected in small advances because it is robust and gives certain guarantees that makes products and their creation process reliable.