What does Software Engineering (SWE) actually mean and (looks like)?
When setting out on a journey to solve a problem using "The Tech", you're likely to get encountered by one. Happy Journey!
Understand what “Software”, “Development” and “Engineering” is?
Finally you’ve heard that Software Development / Software Engineering looks like the dream job that allows you to work from the comfort of Air Conditioner cooled lavish work spaces and earn hefty bucks?
Well think again and it might not be what you’ve been thinking up until now.
Software Engineering and Software Development are very broad terms that are used in the tech industry and their breakdown is not that simple.
Let’s understand each of the above words at atomic level because when paired up with one another it is very easy to use them interchangeably
which is something someone who doesn’t have enough awareness would do
(someone I don’t want you to be):
What is a “Software”?
Software refers to the collection of instructions, or code, that tells a computer what to do. It's the intangible blueprint that makes the computer perform specific tasks.
What is “Engineering”?
Engineering is the discipline of applying scientific principles to design, develop, and build things. It involves solving problems by creating structures and systems that meet specific needs.
What is “Development”?
Development is the process of of creating or improving something. Something already exists and it needs to be improved on a regular / need to basis to meet the ever changing requirement.
Awesome! Now add the word “Software” before the words “Engineering” and “Development” and see how the definitions change due the added word and context:
Software Engineering: The Concise Definition
Software engineering process / collection processes that focuses on the why and the big picture. It involves applying engineering principles to ensure the software is well-designed, scalable, maintainable, and meets the overall project goals.
Software Development: The Concise Definition
Software development focuses on the what and how of building software. It's the hands-on coding, testing, debugging, and implementation.
Thus we can say that the Software Engineering is a broader, bigger term and Software Development seems like the subset of it.
Where do you work matters! Really? Oh Yeah!
Whether I’m a Software Development Intern [SDE Intern] or Software Engineering Intern [SWE Intern] (if there exists such term) depends a lot on where do I work. Not the physical location, but the type of organization and what are my responsibilities.
The following are the 4 types of organizations:
Is a Startup, Functions like a Startup.
Is a Startup, Functions like a Company.
Is a Company, Functions like a Startup.
Is a Company, Functions like a Company.
The organization I intern at, fall into the 3rd type and I love it.
Since, I can’t get into the details of the project due to the confidentiality, I’ll give you the simplest explanation of what I’m doing currently.
There’s a client that already has a product. Now this product has a few sub-products that are linked with each other.
My job is to introduce a new sub-product that will be linked with other sub-products within that on product.
At this point, I could call myself SDE Intern if my only tasks was to code, debug, test and deploy.
But I also have the additional responsibility to ensure that the new sub-product works seamlessly with other sub-product and the product functions even better because it has become feature rich than before.
This will require me think about domain knowledge, product development, design patterns and much more.
Hence, I would call myself a SWE Intern now, rather than simply SDE Intern.
The Foundations Stay The Same . . . ALWAYS ! ! !
Building a sub-product or even a product from scratch is not a piece of cake.
If it was, everyone would be doing it!– Shrinivas, and many such Developers 😆
Regardless of the difficulty of the product, we could always simplify the process of development or the journey to the destination.
In the world Software Engineering of SDLC does the same by providing us a proper framework to manage our tasks as per different phases.
The Software Development Lifecycle (SDLC) is a step-by-step process that helps development teams efficiently build the highest quality software at the lowest cost.
If you browse the internet and check out various resources, you might minor tweaks here and there. A phase present in one article, might be absent in some other blog and vice-versa.
What I want you to focus on is the overall idea and the solution that SLDC offers to the Software Developers rather than bother by nitty-gritty details.
Let’s understand phases in an SDLC with an example:
The Stages in the SDLC for the above software would look something as follows:
1. REQUIREMENT GATHERING
DEFINITION:
This phase involves gathering and documenting both technical and non-technical requirements for the software.
This includes understanding the needs of the stakeholders and end-users.
1.1 Technical Requirements:
DEFINITION:
These requirements are specific technical functionalities or constraints that the software must meet.
EXAMPLE:
The software must support multi-platform compatibility, including web browsers, iOS, and Android devices.
Integration with existing systems such as payment gateways or inventory management software.
1.2 Non-Technical Requirements:
DEFINITION:
These are descriptions of the system's behaviour, usability, and performance that are not directly related to the underlying technology.
EXAMPLE:
The software should provide real-time notifications to staff when new orders are placed.
The interface should be visually appealing and reflect the artistic ambiance of the cafe.
2. DESIGNING
DEFINITION:
In this phase, the system architecture and interface designs are planned based on the gathered requirements.
This includes defining the overall structure of the software and its components.
The Design can be categorized into two parts:
The Front-End Design – Something that client sees.
The Back-End Architecture (Design) – Hidden from user that happens on the server side.
EXAMPLE:
Design a scalable architecture that can handle a potential increase in the number of concurrent users during peak hours.
Define the data model and database schema to efficiently store and retrieve customer information.
Design user workflows that minimize the number of steps required to place an order or provide feedback.
Create wireframes and mockups to visualize the user interface and gather feedback from stakeholders.
System Design? Design System? Huh?
In the realm of Tech, you’d often here the words System Design and Design System ( if you’ve worked with creative designers ).
When we as software engineers, are talking about System Design we’re talking about the primarily talking about the traditional system design which focuses on the back-end architectural design.
The focus on the Design of distributed systems including servers, databases, and communication between them.
The scope is defined as the broad view of the entire system architecture.
But there also exists front-end system design which focuses on the interface that are built on the client-side.
The focus is on the design of the front-end application itself, user interface components, data fetching and manipulation, and API interaction.
The scope on the client-side and its interaction with the back-end.
Okay, enough of System Design! What about Design System?
This is going to make sense for you if you’re working more on the front-end or / and very closely with the UI / UX Designers.
Either way, here it goes:
A design system is a complete set of standards intended to manage design at scale using reusable components and patterns.
This completely with respect to UI / UX and Product Design and has nothing to do with the Engineering team ( at the least not directly. )
It is like a log book that serves as a single source of truth for all the designs that the designers designs which will later then be handed over to the Engineers.
The Design System is used and build by UI / UX Designers or Product Designers and referred by Designers as well as Front-End Developers.
Point being, if you ever hear word “System Design”, most probably they’re referring to traditional system design which focuses on the back-end architectural design, not the sadly no the front-end system design.
It’s just that, typically in the Software Engineering’s spectrum, Design System won’t be referred to as much as the System Design won’t be referred in the UI / UX Design spectrum.
3. DEVELOPMENT
DEFINITION:
In this phase, the actual coding of the software takes place based on the design specifications.
Developers write code according to the defined architecture and requirements. Not every technology, framework, library, runtime for any project.
Hence, it’s developers job to decided the best tools for the job and convert the designs into the the working, usable product.
EXAMPLE:
You would start coding the software based on the design documents.
This involves writing code for features like customer registration, feedback submission forms, and data storage.
The development process might involve using programming languages like Python, JavaScript, or Java, depending on the technology stack best suited and chosen for the project.
4. TESTING
DEFINITION:
When the product is built, there are chances that it might seem right in the first glance, but might end-up giving up unexpected result or behaviour or nothing at all.
Thus, the software is tested in order to identify and fix any defects or bugs. This ensures that the software meets the specified requirements and functions correctly.
The 2 types of testing are:
Manual Testing: Involves a human tester interacting with the software application to identify bugs and issues.
Automated testing: Leverages software tools and scripts written by the testers write scripts that simulate user actions and compare the application's behaviour to expected results.
EXAMPLE:
You would conduct various types of testing, such as unit testing, integration testing, and user acceptance testing.
For example, you might test the registration feature to ensure that new customers can sign up successfully and that their data is stored accurately.
Any issues found during testing would be addressed and fixed before proceeding to deployment.
5. DEPLOYMENT
DEFINITION:
In the Deployment phase, the focus is on moving the software from the development or testing environment to the production environment where it will be used by end-users.
Cloud computing plays a significant role in the Deployment phase by providing scalable and flexible infrastructure resources.
This phase involves several key activities to ensure a successful transition and availability of the software:
Infrastructure Setup
Environment Configuration
Deployment Process
Testing and Validation
Rollout Strategy
EXAMPLE:
Set up servers and configure the necessary infrastructure to host the software.
Deploy the software to Jennifer's cafe, ensuring a smooth transition from development to production.
6. MAINTENANCE
DEFINITION:
In this phase, the software is monitored for any issues or performance degradation, and updates or fixes are applied as needed.
Additionally, new features or enhancements may be implemented based on user feedback or changing requirements.
DevOps principles emphasize collaboration between development and operations teams to improve efficiency, reliability, and speed of software delivery.
CI/CD pipelines automate the build, testing, and deployment of code changes, enabling rapid and frequent updates to the software while maintaining quality and stability.
EXAMPLE:
Monitor system performance and identify opportunities for optimization, such as database indexing or caching strategies.
Apply security patches and updates to address newly discovered vulnerabilities and ensure compliance with industry standards.
What’s In It For You?
No matter what you’re doing building, whether it is a product or a service, whether is tech or non-tech, there’s must be a standard set of procedures or protocols that facilitate to you overall journey.
There’s a certain adventure to messing things up and learning from the mistakes. In fact, the mistakes are really good stimuli for learning and I myself highly encourage messing things up.
But don’t make this a habit because it will turn into you second nature in no time. Thus, maintain healthy boundaries to messing so that you maximise you learning and not waste time.
SDLC is to Software Engineers what Google Maps is to Travellers. Something that gives us the direction so that we don’t lost in the journey of reaching the destination.
After all you really wouldn’t want to build and fully functional dynamic and dynamite product or a service that was built without caring about client’s and user’s requirements in the first place.
If you think that my content is valuable or have any feedback,
do let me by reaching out to my following social media handles that you'll discover in my profile and the follows:
Twitter (X): https://twitter.com/shrinivasv73
Instagram: https://www.instagram.com/shrinivasv73/
Email: shrinivasv73@gmail.com
🫡 This is Shrinivas, Signing Off!