Understanding Software: More Than Just Code
By Luis Carmona | 10/08/2023
"Software does not exist without the hardware"
When I started to learn about software, I heard this quote. At face value, it appears accurate, but there's a nuance to consider. Let’s try to understand what is a software before talking about this. So, what is software? The word was first coined by American statistician John Wilder Tukey in 1952. The Cambridge Dictionary defines it as "the instructions that control what a computer does; computer programs".
So, where is the subtle lie? Software, as a concept, can exist independently of hardware. It's a set of instructions or data. However, for software to be executed or to function as intended, hardware is essential. In other words, while software can be conceived, designed, and written without any specific piece of hardware in mind, it requires hardware to be realized and operational.
What makes a good Software?
There is a list of principles that we have to follow when writing software, this is to maintain consistency and scalability, two main things in computer science. The list of principles we must follow is this:
- Maintainability: A software may evolve and must solve all the changing needs of the clients. This is fundamental, because changes in the software are inevitable in an ever-changing environment
- Dependability and Information Security: A good software must include a range of features including reliability, information security, and safety. Reliable software should not cause physical or economic harm in the event of a system failure. Malicious users should not be able to access or damage the systems.
- Efficiency: The software should not waste system resources, such as memory and processing power. Efficiency therefore includes response time, processing time, memory use, disk use, etc.
- Acceptability: The software should be acceptable to the type of user for whom it is designed. This means it should be understandable, useful, and compatible with other systems used by the user.
There are 2 more key principles (Portability and Reusability), but they are included in this last principle - they are crucial for better efficiency. Let's see this principles in practice with 2 examples:
(a) Example of a good code
(b) Example of a bad code
Can you spot what makes (a) a good software and what makes (b) a bad software?
Well Written Code
- Object-oriented approach separating concerns.
- Uses hashed passwords for security.
- Clear distinction and relationship between User and UserManager.
- Provides meaningful error messages.
Bad Written Code
- Uses global variables which can lead to unpredictable side effects.
- Stores password as plain text - a severe security risk.
- The data structure for users is a tuple, which is hard to modify and understand.
- No error handling or validation.
Keep in mind that this is a basic example. In real-world applications, many more considerations, such as database integration, third-party libraries, and scalability issues, would come into play. Good Code must also be Readable, Simple (following the KISS principle), Modular, DRY (Don't Repeat Yourself) and must Handle Errors (instead of crashing).
Software development process
When developing software, we can typically break it into these steps:
Specification
Design and Implementation
Validation and Verification
Evolution
Specification: The goal here is to understand and define what services are required for the system, as well as identify constraints on its operation and development.
Design and Implementation: The objective in this process is to convert the system specification into an executable system.
Validation and Verification: The goal of validation and verification (V&V) is to demonstrate that a system complies with its specifications and meets the system client's requirements:
- Validation: Are we building the right product?
- Verification: Are we building the product correctly?
This step involves process review and system testing. System testing involves running the system with test cases derived from the specification of the real data to be processed by the system.
Evolution: Software is inherently flexible and can change. As requirements change due to changing business circumstances, the software that supports the business must also evolve and change.
Models of operations
In the context of software development, we have various operational models that have evolved over time. This operational models dictate how software is built, deployed, and maintained. Lets understand them a little better.
| Development Model | Release Model | Architecture Model | Hosting Model | Model Orientation | Organizational Model |
|---|---|---|---|---|---|
| Waterfall | Discrete (yearly, monthly,…) | Monolith | Physical Datacenter | Process | Hierarchical Organization |
| Agile/DevOps | Continuous delivery | N-tier, Microservices | Virtual Machines, Cloud and Containers | Product Value Stream | Product line organization, squads and swarming |
Waterfall: A traditional project management and software development approach where phases occur in a linear sequence. Each phase must be completed before the next one begins, making it less flexible to changes.
Agile: A flexible software development methodology that emphasizes collaboration, customer feedback, and rapid iteration. Unlike Waterfall, Agile allows for frequent adjustments based on changing requirements and feedback.
DevOps: A cultural and technical movement that emphasizes collaboration between development and IT operations teams. Its goal is to automate and streamline the software development and infrastructure management processes to deliver faster and more reliable software.
Architecture Model - Monolith: A software architecture where all components and functionalities are combined into a single codebase and application. This approach can be simple to develop initially, but can become complex and hard to scale over time.
Architecture Model - N-tier: A software architecture that segregates application functionality into multiple, logical layers or tiers, such as presentation, business logic, and data storage. This separation allows for improved scalability and maintainability.
Architecture Model - Microservices: A software architecture that breaks down an application into small, loosely coupled services that operate independently. Each service is responsible for a specific functionality, enabling better scalability, maintainability, and resilience.
Model Orientation - Process: This orientation emphasizes the methods and sequences used to produce a result. It often focuses on standardizing work, minimizing variability, and ensuring predictability. Organizations that follow a process-oriented model prioritize workflows, tasks, and procedural adherence.
Model Orientation - Product Value Stream: This orientation centers on the end-to-end journey of a product or service, from concept through to delivery and its value to the customer. It emphasizes optimizing the flow of value and reducing waste throughout the product lifecycle.
Hierarchical Organization: A traditional organizational structure where roles and responsibilities are clearly defined in a top-down manner. It's characterized by a pyramid-like setup with clear lines of authority, moving from senior management at the top to lower-level employees at the bottom.
Product line organization, squads and swarming: This model organizes teams around products or features rather than functions. Squads are small cross-functional teams responsible for specific product aspects, enabling faster and more agile responses. Swarming is a collaborative approach where multiple team members come together to solve a problem or address an issue, promoting quick resolution and knowledge sharing.
This wraps up the basics of software development. This will lay the foundation for the texts I will later write and for the projects I post.