Forem: xh1m

The Architect’s Manifesto 2026: Engineering in the Age of Autonomy 🌐

xh1m — Sat, 14 Mar 2026 15:09:06 +0000

For years, software engineering was a game of control. We controlled the state, the memory, and the flow. But as we move deeper into 2026, the industry is pivoting toward Orchestration. We are no longer just writing instructions; we are managing ecosystems of autonomous agents and distributed data.

1. The Decentralisation of Logic:

Edge Computing & SLMs
The "Cloud First" era is being challenged by the "Edge Native" movement. In your early units, you likely learned about the Client-Server model. You send data to a massive data centre (The Cloud), it processes, and sends it back.

The 2026 Shift:
We are moving the "Brain" closer to the user. This is Edge Computing.

The Problem:
Sending massive amounts of data to a central server creates Latency and High Bandwidth Costs.

The Solution:
Small Language Models (SLMs).

While the massive LLMs require an entire farm of GPUs, SLMs are small, distilled versions of AI that can run on standard hardware. When considering my Dell Vostro, that’s a game-changer. While my integrated AMD graphics might struggle to handle the 70 billion parameter LLM, it should be perfectly fine for the highly specialized 3 billion parameter “Micro-LLM.”

2. From DevOps to AI-Native SDLC ⚙️

You’ve probably covered the Waterfall vs. Agile debate in your Professional Practice units. But in 2026, we are talking about the AI-Native Software Development Life Cycle (SDLC).

This is where "Agentic Engineering" becomes the norm. Instead of a single "AI Assistant" that helps you write a function, you are managing a Fleet of Agents:

The Feature Architect:
Drafts the structural logic and interface definitions.

The Test Generator:
Automatically creates property-based and edge-case tests.

The Security Auditor:
Constant scanning for vulnerabilities and "hallucinated" dependencies.

The Documentation Agent:
Ensures the README.md and technical specs are updated in real-time.

Your Role:
You are the Human-in-the-Loop (HITL). Your job isn't to write the for loop anymore; it’s to provide the Governance. You are the one who decides if the agent's proposal matches the Business Requirements.

3. The "Shift Up": High-Level Design Takes Focus 🏗️

As we leave the tedium of syntax fixes to the AI, the engineering world is shifting our focus upwards in abstraction.

In your Object-Oriented Programming (OOP) section, you still learn about encapsulation and inheritance. They are important concepts, yet by 2026, we are applying these concepts to systems, not just to code.

Micro Frontends:
Break down the web application into independent, self-contained units.

Micro Services:
Break down the backend to the point where if "Payment Agent" fails, "User Profile Agent" will not fail.

To achieve a Distinction grade for your Graded Unit, you must demonstrate the modularity of your system. Showing the ability to replace a single component of your system without affecting the other components demonstrates your achievement of Professional-Level Architecture.

4. Sustainable Software Engineering: The Green Code Mandate 🌿

It’s an area that students may not pay enough attention to, but for 2026 recruiters, it’s a highly desirable skill. Why? Well, software has a footprint, and the truth is that training and executing massive AI models consumes a tremendous amount of power. In the HND, your Professional Practice and Emerging Technologies modules now incorporate a ‘Sustainability’ perspective. Green coding principles to keep in mind:

Computational Efficiency:
O(1) isn’t just fast; it’s battery life. An inefficient O(N^2) algorithm on a billion mobile devices is an ecological catastrophe.

Carbon Aware Computing:
Design software that runs computationally intensive jobs when the power grid is renewable, using tools such as the Carbon Aware SDK.

Asset Optimisation:
Reduce the weight of your webpage and use efficient caching to reduce the load on the data center.

5. Cybersecurity: The New Battlefront of Agentic Attacks 🛡️

Cybersecurity is more than simply fighting "SQL Injections" (though that’s important knowledge for your Database section). By 2026, the threat is no longer the "script kiddie" or the cyber-terrorist. It’s the Autonomous Adversary.

The New Threats:

Shadow AI:
Employees use unauthorized external AI models that leak confidential company information.

Prompt Injection:
Cyber attackers exploit your AI agent to bypass security protocols and access the content of your database.

Supply Chain Hallucination:
Cyber attackers insert malware into open-source software that your AI might use as a solution.

The Solution:
DevSecOps. You have to shift security left. Every action your agentic system takes should be logged, explained, and reversible.

6. Strategy for Your Graded Unit: The Roadmap to Distinction 🎓

While you’re waiting for the feedback and you have some time in the Block Week, here is the plan of action on how you can transform these ideas into a good project.

Explain the “Why”:
Explain the Decision Matrix. Explain why you used Python instead of C# for the AI part of the project. Explain why you used a certain database normalization scheme.

Show the Guardrails:
If you used AI in your project, show the Safety Layer. Explain how you prevent the AI from running a DROP TABLE command.

Sustainability Statement:
Explain how you made the project more sustainable in terms of resources. It is a small part of the project that shows you are a professional.

Unit Testing is Non-Negotiable:
As previously discussed, unit testing is the best way to impress the tutor or the recruiter.

The "Vibe Coding" Reality Check: Are You Actually Engineering or Just Prompting? 🚀

xh1m — Sat, 14 Mar 2026 14:46:01 +0000

The term "Vibe Coding" is often used by developers. It means that the developer uses their big AI tools in a way that they are "describing the vibes" of an app and are able to make large amounts of code instantaneously. This is great for getting the app to market, but it leaves open the possibility that code that looks right is not architecturally correct.

The Foundations vs. The Shortcuts 🧠

In the professional development process, how we deal with logic changes in steps:

The Syntax Phase:
This is where we learn the syntax of the language, how to write a for loop in Java, how to connect to Oracle SQL, etc. At this stage, the role of the AI is that of a super smart autocomplete.

The Architecture Phase:
This is where the real engineering takes place. It’s where we reason about why we prefer one way over another. If we have an app that’s super “slick” and “vibe-coded” but uses a transitive dependency that violates Database Normalisation, then the app remains shaky even though it looks nice on the outside.

Why Vibes Don’t Cut It in Production🏗️

The problem with relying solely on auto-generated code is that it does not reveal how it’s generated. While an executable code is essential in production, the real challenge lies in making it maintainable.

The Vibe trap is real. The tendency of AI code is to only work on the “happy path.” The “happy path” is where everything goes right.

Vibes-only coding might get you a login screen that works.

An engineer might build a login screen that’s not only functional but also includes BCrypt for password hashing, try-catch for database timeouts, and an MVC structure with validation.

The Plan: Augment, Don’t Replace 🛠️

To use AI to improve our engineering advantage, we should strive to establish a consistent and disciplined process:

Pseudocode First:
Before we ask the AI, let’s try to write the logic out in plain English or with a basic flowchart. If the logic is indescribable, then we’re unlikely to engineer it well.

The Line-by-Line Rule:
Don’t write code that you can’t describe in excruciating detail. If the generated lambda is confusing, then take a moment to understand how it works at a basic level.

Architectural Refactoring:
AI tools seem to favor “monolithic” code blocks. Use the principle of Separation of Concerns to divide the code into separate, more digestible parts.

Final Thought: Keep the Architect in the Loop 🏢

The idea is to work smarter, not harder. Let AI handle the boilerplates and repetitive tasks, but retain ownership of System Design and Architectural Strategy. This way, your portfolio - and your career rests on actual engineering prowess rather than your ability to quickly prompt AI.

Sleep Better at Night: Why Unit Testing is Your Secret Weapon for Graded Units 🛡️

xh1m — Thu, 12 Mar 2026 15:56:58 +0000

Let’s be frank: Most students treat Unit Testing as much as the terms and conditions of a software project - presented to be there, to be ignored, to be quickly scanned to the end in hopes that something good is to be found.

When you are studying Software Engineering or Quality Assurance courses, testing is what separates a Pass from a Distinction. Why? Anyone can write code that works as long as everything is aligned. A Lead Developer is someone who writes code that still works as long as a user decides to type their name in a field labeled “Phone Number.”

What is Unit Testing?
Unit testing is testing a small piece of code, called a unit or a function. For us Java programmers, we use JUnit to accomplish this.

Rather than running the entire application, logging in, and manually clicking through to verify that the CRUD wrapper is working (which is a slow and flaky process), you write a script that does all these tests for you in a matter of milliseconds.

Three Ways to Show Distinction 🏆

When you write the Graded Unit, instead of just showing a single test, you must show a “Test Suite” with three different cases:

1. The Happy Path (Works)
The happy path is where everything works. So, if I pass a StudentID to deleteUser(), does it return true?

What to achieve with the test:
Test if the core function works.

2. The Edge Case (What If)
What if I pass a null or empty StudentID? Does it crash with a NullPointerException, or does it handle it well?

What to achieve with the test:
Test if the code is robust.

3. The Fail Case (Wrong Type)
What if I pass a string to a function expecting an integer? Does the exception handling work well?

What to achieve with the test:
Test if the guardrails are in place.

The Java Example: Testing Your CRUD Wrapper 💻

Let’s take a look at how you would write a simple test for the Java CRUD Wrapper, a topic we discussed earlier in this post and in detail on another post.

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

public class DatabaseTest {

    // 1. Happy Path
    @Test
    void testConnectionSuccess() {
        DatabaseWrapper db = new DatabaseWrapper();
        assertTrue(db.connect(), "Database should connect successfully with valid credentials.");
    }

    // 2. Edge Case
    @Test
    void testEmptyQuery() {
        DatabaseWrapper db = new DatabaseWrapper();
        assertThrows(IllegalArgumentException.class, () -> {
            db.executeQuery(""); // Should not allow empty strings
        });
    }

    // 3. Fail Case
    @Test
    void testInvalidUserDelete() {
        DatabaseWrapper db = new DatabaseWrapper();
        // Testing a non-existent ID should return false, not crash
        assertFalse(db.deleteUser(-1), "Should return false for non-existent IDs.");
    }
}

Why Tutors Lecturers Love This 🎓

If your tutor spots a test folder within your project, you've already won half the battle. This shows you're interested in Maintainability.

If you decide to refactor your code (for instance, from a local Oracle DB to a Cloud-based one), you can run your tests to ensure your logic is working correctly. This is called 'Lead Dev' thinking. This converts your documentation from a list of features to a Technical Report that shows your application is ready for production.

Building Your First Simple AI Agent in Python: An Introduction Guide to Intelligent Logic 🤖

xh1m — Thu, 12 Mar 2026 15:10:40 +0000

Don’t chase the hype. If you’ve spent the last two or three years of your studies creating CRUD applications, then you already have the basic building blocks. An AI Agent isn’t magical – it’s simply a smart wrapper around the code you already know how to write.

Think about it. Your Visual Studio and NetBeans projects have already been creating Reactive systems. A user clicks on a button and some function is called. But an AI Agent is Proactive. It doesn’t just call the function - it decides which function to call based on the goal that’s been set.

The Architecture of an AI Agent
Perception ➡️ Thought ➡️ Action 🧠

In the professional world, the flow of an AI Agent’s activities is called a loop. This is basic Software Engineering and directly maps to the rubric of the unit on System Analysis and the unit on Advanced Programming.

The Brain (The LLM):
This is your Large Language Model (LLM), similar to GPT-4 or Llama 3. This isn’t something that “knows” anything - it’s simply logic.

The Tools (Your Functions):
This is the set of Python functions that you’ve learned how to program. A function to access an Oracle SQL database, a function to check the weather, or a function to send an email.

The Loop (The Agentic Cycle):
This is the “While Loop” that the AI Agent will execute until the goal is met.

The Student Level Use Case: The Smart Library Assistant 📚

Here is a simple example of a basic "Library Management System".

The Traditional CRUD Process:
A user enters the word "Peaceful" into the search box. Your SQL code will be executed as follows: SELECT * FROM Books WHERE Title LIKE '%Peaceful%'. If no book contains the word "Peaceful" in the title, the user will be presented with no search results.

The AI Agent
The user says to the AI Agent: "I've had a really stressful day at college. Find me something to help me relax."

The Agentic Process - Perception
The AI Agent "sees" the user's input.

Thought
The "Brain" of the AI recognises that the user is stressed and needs to be presented with topics related to "relaxation."

Action
The AI Agent will execute your search_database() function using its own set of keywords, such as "Meditation," "Nature Photography," or "Fiction."

The Tech Stack: Lead Dev Approved 🛠️

You don’t need to use high-end hardware for the Artificial Intelligence and Data Science unit. A standard setup, such as a Dell Vostro which I use, with lightweight APIs is fine.

Python:
This is the main industry standard for AI.

Claude/OpenAPI:
This is the “Brain.” Using an API prevents a bottleneck from my AMD integrated graphics.

LangChain:
This is a library to help you link ideas together. This library handles prompt engineering and tool calling logic, allowing you to focus on the structure.

The Code: Defining Your First Tool 💻

In an agent-based system, your tools are just Python functions with a clear description. This is an important part, as the LLM reads this to determine when to use the function.

#a standard college level function (the tool)
def query_library_database(search_term: str):
    """
    Queries the library SQL database for books based on a keyword.
    Use this when the user is looking for specific reading material.
    """
    # Imagine your Oracle SQL connection logic here
    print(f"Searching database for: {search_term}")
    return ["The Art of Stillness", "Nature Walks in Scotland"]

Why this is important for your Graded Unit 🎓

When you write this for your project, you are not just writing “I used AI.” What you are doing is showing Abstraction. What you are doing is applying the Single Responsibility Principle by keeping the “Reasoning” part separate from the “Execution” part.

If the user wants to search for books, the LLM is responsible for the goal, and your Python is responsible for the data, keeping your application secure and predictable.

Beyond the Logic: Transitioning from Software Dev to AI & Data Science 🤖

xh1m — Thu, 12 Mar 2026 14:10:09 +0000

If you have spent the last couple of years of HNC/HND studies honing your skills in OOP, MVC, and the art of building standard CRUD applications, chances are good that you are familiar with a world of "If/Then" logic.

You define the rules, and the computer follows them. However, as you begin your journey in Data Science, the script changes. Suddenly, instead of defining the rules and feeding them into the computer, you are feeding the computer the data and letting it discover the rules on its own.

As an HND student, the transition from traditional programming into AI does not require a PhD in Mathematics; it requires a paradigm shift in how you perceive the data.

The Shift: From Static Databases to Predictive Models 📊

In a standard HND project, your SQL Database is a storage locker: you put stuff in; you get stuff out. In Data Science, the exact same database becomes a goldmine of hidden patterns.

Software Development: You write a function to determine a discount if a user has a "Premium" status in the database.

AI/Data Science: You feed a model thousands of past transactions and have it predict which users will likely be "Premium" next month.

Core HND Concepts in the AI World 🧠

The good news is that you don’t have to forget everything you have learned in your units. In fact, your HND background is probably your greatest strength.

OOP (Object Oriented Programming): Most of the work in Artificial Intelligence programming happens in Python. Your understanding of Classes and Objects becomes crucial as you start using libraries like Scikit-Learn or PyTorch.

CRUD & Data Integrity: You can’t have Artificial Intelligence with Bad Data. Your understanding of Database Normalization and SQL ensures that the data fed into an Artificial Intelligence model is good, clean, and consistent.

Algorithms: Do you remember Big O Notation? Well, in Artificial Intelligence programming, the only thing that matters is efficiency above all else. If you are trying to process a dataset with millions of rows of data, it needs to be an O(n) operation. If your data preprocessing script runs at an O(n²) operation, forget about training the model in a reasonable time - it’ll take days rather than minutes!

Getting Started: The Python & SQL Power Couple 🛠️

If your academic path is meandering into Data Science, your best bet is to learn the Python ecosystem. You may be comfortable with languages like C# or Java from your current coursework, but Python is the lingua franca of AI.

Pandas: Think of this as "SQL for Python." It allows you to manipulate data frames as effortlessly as you query an Oracle table.

NumPy: This is where you perform the heavy-duty math operations (Linear Algebra) that are happening behind the scenes of every AI model.

_Matplotlib/Seaborn: _This is where raw data comes alive as the visualizations that Lead Developers and Stakeholders care about.

Final Academic Advice 🎓

When you begin your HND Graded Unit or your final projects, try to incorporate a "Predictive" element into your project. Instead of simply creating a library management system that tracks books (CRUD operations), could you incorporate a Python script that recommends a book to a user based on their history? That is how you become a Software Developer turned Data Scientist.

From ERD to SQL: Implementing a Normalised Database Step-by-Step

xh1m — Thu, 12 Mar 2026 13:54:25 +0000

If you’re working towards a Degree in Computer Science or Software Development, I bet you have looked at a messy spreadsheet and have heard someone say, “Normalise it.” It might sound like some boring academic exercise, but it is, in fact, the most important skill in a Database Developer’s arsenal.

The biggest challenge seems to be when you go from designing a diagram (ERD) into an actual SQL database. You get the general idea, but making it into solid SQL statements with all the appropriate Primary and Foreign Keys can be like trying to assemble a jigsaw puzzle without all the pieces.

Today, we’re going to cut through all the technical jargon and show, in very basic steps, how we can take a messy data sample and turn it into a beautiful, clean, 3NF-compliant Oracle SQL Database.

The "Messy" Starting Point: Unnormalised Form (UNF) 🗑️

Imagine we are building a database for a local college. We start with a flat file or a spreadsheet that looks like this:

This is a nightmare. We have Redundancy (John Smith’s name is repeated) and Update Anomalies (If Dr. Brown leaves, we have to change the name in every single row).

Step 1: 1NF (Atomic Values & Unique Keys) ⚛️

To reach First Normal Form (1NF), we must ensure every cell contains a single value (atomicity) and that every row is unique.

Rule: No repeating groups or multi-valued attributes.

Result: Our table is technically in 1NF because each cell has one value, but the redundancy is still there. We identify our Composite Primary Key: StudentID + CourseID.

Step 2: 2NF (Removing Partial Dependencies) ✂️

This is where students often struggle and where I did when i first learned the concept. Second Normal Form (2NF) is about making sure every non-key column depends on the entire Primary Key.

In our 1NF table, StudentName only depends on StudentID. It doesn't care about the CourseID. This is a Partial Dependency.

Action: We break the table apart.

Table 1 (Student): StudentID (PK), StudentName.

Table 2 (Course_Enrollment): StudentID (FK), CourseID (FK), Grade.

Step 3: 3NF (Removing Transitive Dependencies) 🧹

Now we look at Third Normal Form (3NF). Here, we remove Transitive Dependencies. This means a non-key column shouldn't depend on another non-key column.

In our current structure, LecturerName depends on CourseID, but CourseName also depends on CourseID. If the lecturer is tied to the course, we need to move them out to keep the data clean.

Final Entities:

Student: ID, Name.

Course: ID, Title, LecturerID.

Lecturer: ID, Name.

Enrollment: StudentID, CourseID, Grade.

The Translation: From Logic to SQL 🛠️

Now that we have our clean, 3NF logic, we need to write the Oracle SQL to build it. As a Lead Developer, I expect to see strict constraints to protect Data Integrity.

1. The Student Table

CREATE TABLE Student (
    StudentID INT PRIMARY KEY,
    StudentName VARCHAR2(100) NOT NULL
);

2. The Lecturer Table

CREATE TABLE Lecturer (
    LecturerID INT PRIMARY KEY,
    LecturerName VARCHAR2(100) NOT NULL
);

3. The Course Table (Linking to Lecturer)

CREATE TABLE Course (
    CourseID VARCHAR2(10) PRIMARY KEY,
    CourseName VARCHAR2(100) NOT NULL,
    LecturerID INT,
    CONSTRAINT fk_lecturer 
        FOREIGN KEY (LecturerID) 
        REFERENCES Lecturer(LecturerID)
);

4. The Enrollment Table (The "Bridge" Table)

This table handles the Many-to-Many relationship between Students and Courses.

CREATE TABLE Enrollment (
    StudentID INT,
    CourseID VARCHAR2(10),
    Grade CHAR(1),
    PRIMARY KEY (StudentID, CourseID), -- Composite PK
    CONSTRAINT fk_student 
        FOREIGN KEY (StudentID) 
        REFERENCES Student(StudentID),
    CONSTRAINT fk_course 
        FOREIGN KEY (CourseID) 
        REFERENCES Course(CourseID)
);

Why This Matters for Your Project 🎓

When you submit your Database unit, don't just hand in the SQL. Show the transition.

Show the Messy Data: Prove you identified the problems.

Show the ERD: Use a tool like LucidChart to visualize the 3NF structure.

Explain the Constraints!

In your report, mention why you used NOT NULL or REFERENCES. This shows you aren't just copy-pasting code; you’re managing Referential Integrity.

By following this step-by-step pipeline, you ensure that your database is efficient, scalable, and - most importantly - easy to query using CRUD operations.

Why Your Code is Slow: A Practical Guide to Algorithms and Big O Notation

xh1m — Thu, 12 Mar 2026 13:32:21 +0000

If you’re a Software Development student and they’ve given you the Algorithms unit to work on, then you’re probably having a problem by now. It’s not enough to simply get your code working to pass a unit assessment. You may have a simple CRUD application that works fine with ten records in your Oracle database. But as you add more records, your application slows down. It’s not a hardware problem; it’s a problem of your code getting more expensive to run. In other words, it’s a Big O Notation problem.

The Academic Barrier: Why Big O Matters 🎓

In class, Big O Notation is often explained as a series of math proofs that put students to sleep. You see O(n log n) or O(2^n) scribbled on a blackboard, and your eyes glaze over. But as someone who just completed the unit, I’m here to tell you that Big O Notation is simply a way of measuring how your code gets slower as your input gets larger. Think of it as a “Scale Grade.” If your code is Grade A, it means it remains speedy even as your input reaches a million records. But if your code is Grade F, it means it may work for your assignment but will kill your server if you’re a real-world developer.

Getting your loop wrong doesn’t just mean your code is slow; it means your code is a failure.

The Bottleneck: The O(N²) Nightmare 🐌

Students of HND level or higher often make the same mistake: a nested loop. Here is a simple example: finding duplicates in an array.

Let's think of a list of user IDs; we want to check if there are any IDs that are repeated. A new programmer might use a Brute Force approach. They take the first ID and compare it to all other IDs. They take the second ID and compare it to all other IDs.

In Java code:

// The O(N^2) "Brute Force" approach
public boolean hasDuplicate(int[] nums) {
    for (int i = 0; i < nums.length; i++) {
        for (int j = i + 1; j < nums.length; j++) {
            if (nums[i] == nums[j]) {
                return true; // Duplicate found
            }
        }
    }
    return false;
}

What makes this a disaster?

It’s an O(n^2) algorithm. If you have an array of 10 items, it does 100 comparisons. If you have an array of 1,000 items, it does 1,000,000 comparisons. If you have an array of 100,000 records, your program does 10 billion operations. It maxes out the CPU and RAM.

The Solution: Make it O(N) Efficient ⚡

To solve this problem, stop comparing every item with every other item. Think of a more intelligent data structure. If you’re an object-oriented programmer, you can use a Hash Set or a Dictionary in Python. It’s a data structure that lets us remember what we have seen so far. We only need one loop.

The Python code looks like this:

# The O(N) Optimised approach
def has_duplicate(nums):
    seen = set() # Create a Hash Set
    for num in nums:
        if num in seen:
            return True # Duplicate found in "Constant Time"
        seen.add(num)
    return False

The Transformation:

This runs in O(n), or linear time. What this means is that if you are working with 100,000 pieces of data, the computer is working through 100,000 operations. What used to take you minutes now takes less than a second to accomplish.

Real World Application: CRUD and SQL 🗄️

This is not just about loops. Loops are important in Database Development as well. Have you ever written a SQL query without an index? What happens is that you are performing an O(n) problem. What about if you are working with two unindexed tables? Suddenly you are working with an O(n × m) problem, or a problem equivalent to a nested loop. Remember to always ask yourself in your projects: “What happens if I add 10,000 more pieces of data to my application?”

Final Thoughts: Don’t Over-Engineer 🛠️

Efficiency is great, but don’t get caught up in micro-optimizations. If your list is only ever going to have 5 items, an O(n^2) loop is perfectly acceptable if it’s easier to read. In your Unit Graded Assessment, you need to demonstrate your understanding of this. Tell your lecturer that you picked a HashMap/HashSet because you had thought about Computational Complexity. This is what separates a “coder” from an “engineer.”

Waterfall is Dead? When to Choose Agile Methodologies in Software Projects 🚀

xh1m — Thu, 12 Mar 2026 13:16:37 +0000

In the realm of Software Development Life Cycles (SDLC), people have two broad ideas: Waterfall with its linear steps or Agile with its flexible changes. Students in HND projects need to get the right idea because it's not only about getting something done, but something useful.

Rigid vs. Adaptive

The ability to use these techniques is crucial for a Lead Developer.

Waterfall (The Linear Giant): It's a linear process: Requirements, Design, Implementation, Testing, and Maintenance. It's good for projects where safety is a concern or the project scope won't change. If a design flaw happens in Waterfall, it'll be costly during the testing phase.

Agile (The Iterative Ninja): It's good for modern applications like CRUD-based applications or e-commerce applications because the project requirements may change over time.

Professional verdict: Waterfall should be used if the project's ultimate goal is clear and static. Agile should be used if the project requires flexibility and dynamic updates.

Practical Agile Workflow

Junior developers think Agile means you just discuss your code. But for a real project, you need a workflow.

Backlog: Write each feature, like "User Login" or "SQL Database Connection," as a User Story.

Sprint: Plan a two-week period where your team focuses on completing a set of backlog items.

Visual Management: Use GitHub Projects to track your progress. Moving a task from "To-Do" to "Done" is like a professional Lead Developer setup.

Summary

When writing your project for your unit rubric, use logic as your basis. Agile is not just "quicker." Agile is a means of decreasing your risk. By using an iterative methodology, you test your MVC (Model-View-Controller) architecture early and often instead of waiting until the end of your project to have a huge failure.

INTERFACES VS. ABSTRACT CLASSES: A REAL-WORLD JAVA EXAMPLE

xh1m — Thu, 12 Mar 2026 12:42:50 +0000

If you’re familiar with OOP (Object Oriented Programming), you’ll probably recognise the following code: an Animal class, a Dog class, and a method called bark.

It’s good code if you want to learn Java syntax. It’s bad code if you want to understand software architecture. Nobody in the real world writes code to make digital dogs bark. If you only learn these abstract metaphors, you’ll never understand why we use polymorphism or why an interface might be a good idea.

Today, we’ll skip the zoo. We’ll write a real-world e-commerce checkout application using Java and show how using an interface helps your application scale without changing your core code.

The problem: the tightly coupled nightmare

Let’s say you’re building a checkout application. At first, your boss says: “Hey, we only accept Credit Cards.” So you write a service class called CheckoutService that calls a CreditCardAPI.

A month passes. Your boss says: “Hey, we need to accept PayPal.” Then: “Hey, we need to accept Crypto.”

If you’re not using polymorphism, your code will become a nightmare of if/else statements

public class BadCheckoutService {

    public void processPayment(String paymentType, double amount) {
        if (paymentType.equals("CREDIT_CARD")) {
            CreditCardAPI cc = new CreditCardAPI();
            cc.charge(amount);
        } else if (paymentType.equals("PAYPAL")) {
            PayPalAPI pp = new PayPalAPI();
            pp.sendFunds(amount);
        } else if (paymentType.equals("CRYPTO")) {
            CryptoWallet cw = new CryptoWallet();
            cw.transfer(amount);
        }
    }
}

So, why is this bad?

For every new payment type you add, you must go into this fundamental class and change the logic in your if statements. This is a problem because you're altering something that could potentially break your entire checkout process. This is a violation of the Open Closed principle. Our code should be open to extension and closed to modification.

THE SOLUTION: PRACTICAL POLYMORPHISM

We're going to avoid hardcoding every type of payment. What is an Interface? An Interface is a contract that tells the world how something will behave without worrying about how it's implemented.

Step 1: Define the Interface

We're going to make a simple contract that all our payment classes must follow.

public interface PaymentProcessor {
    boolean processTransaction(double amount);
}

Step 2: Implement the Interface

Now, we create distinct, isolated classes for each payment method. They all implement PaymentProcessor, meaning they are forced to provide their own specific logic for processTransaction.

public class CreditCardProcessor implements PaymentProcessor {
    @Override
    public boolean processTransaction(double amount) {
        System.out.println("Connecting to Stripe API... Charging £" + amount);
        return true; 
    }
}

public class PayPalProcessor implements PaymentProcessor {
    @Override
    public boolean processTransaction(double amount) {
        System.out.println("Redirecting to PayPal OAuth... Transferring £" + amount);
        return true; 
    }
}

Step 3: The Polymorphic Checkout Service

This is where the magic happens. We inject the interface into our checkout service rather than the concrete classes.

public class CheckoutService {

    // The service doesn't care IF it's PayPal or Crypto. 
    // It only knows it holds an object that can 'processTransaction'.
    public void executeCheckout(PaymentProcessor processor, double amount) {
        boolean success = processor.processTransaction(amount);

        if (success) {
            System.out.println("Order complete!");
        } else {
            System.out.println("Payment failed.");
        }
    }
}

If your boss wants you to implement Apple Pay tomorrow, you should not touch the existing code in CheckoutService. Instead, create a new class, ApplePayProcessor, that implements PaymentProcessor and pass it in. Your core code remains unchanged and stable.

HND WARNING: AVOID OVER-COMPLICATION

When implementing interfaces in your unit rubrics, ensure that your code remains uncomplicated and easy to maintain. Avoid complicating your code further by implementing advanced Abstract Factory patterns or Spring Boot Dependency Injection (DI) unless your assignment specifically requires you to. It is very easy to get into an error where you create an Interface for every class. For example, you might create an Interface like IUser, an Interface like IDatabase, and an Interface like IButton. This results in too many interfaces. Only create an Interface if you expect that there will be multiple, distinct implementations of that Interface.

Otherwise, use basic constructor passing, like above, if you want top marks.

BUILDING A CLEAN CRUD WRAPPER FOR ORACLE SQL IN JAVA

xh1m — Thu, 12 Mar 2026 12:27:38 +0000

If you are currently working on a Database Design and Development assignment, you know the pain of transforming a database from 1NF to 3NF. But after the normalization nightmare comes another challenge: connecting your Java application to your Oracle database.

When Java developers sit down at their IDEs like JetBrains or NetBeans to write their CRUD operations like Create, Read, Update, Delete, they soon find that their code is a mess. They are copying and pasting their database connection string into a lot of different methods, failing to close database connections that cause timeout exceptions, and concatenating strings to build SQL queries that leave themselves vulnerable to SQL injection attacks.

Today, we’re going to solve this problem once and for all by creating a clean and secure object-oriented programming interface to our Oracle database using standard Java JDBC.

THE PROBLEM: THE COPY-PASTE ANTI-PATTERN

Here is what a standard, messy database call looks like when you put everything in one place:

This code is a major security risk and breaks the principle of DRY (Don't Repeat Yourself). If a user were to input ' OR '1'='1 as their username, then the query would be compromised.

The Solution: A Dedicated Database Utility Class

To ensure that our application interacts with Oracle in a consistent manner, it is necessary to refactor the database connection logic into a single class.

Step 1: The Database Manager

We will create a class called DatabaseHelper. This class centralises the connection string so that any changes to the password or server are required only in this class.

Step 2: Secure CRUD Using Prepared Statements

Let’s now re-implement our INSERT method with our new helper and a prepared statement. Prepared statements will automatically escape our user input and prevent SQL injection entirely.

We’ll use a try-with-resources statement. This is a really nice feature of Java that ensures your database connections and statements are closed right after you finish with them, no matter how you left your method. No more timeout exceptions!

THE ARCHITECTURAL WIN

By structuring your code like this, you have demonstrated your understanding of a Data Access Object (DAO) pattern.

Security: Using a PreparedStatement prevents SQL injection attacks.

Stability: The use of try-with-resources prevents memory leaks and Oracle connection limits from being exceeded.

Maintainability: Your CRUD operations are completely decoupled from your UI layer and your connection string.

HND WARNING: KEEP IT SIMPLE

When researching database connectivity for Java projects, you will most likely come across various Enterprise Java frameworks like Hibernate, JPA, or Spring Data. However, remember that your solution doesn’t need to be more complicated than a standard unit question asks. While ORMs are great tools, creating your own ORM system without understanding the fundamentals of JDBC is a recipe for a complicated mess that is hard to grade. A clean and well-structured JDBC utility class using Prepared Statements is exactly what a Lecturer wants to see to ensure that you know your data access patterns.

Master the basic wrapper first, and you will ace the unit.

STOP PUTTING LOGIC IN YOUR BUTTONS: A BEGINNER'S GUIDE TO SEPARATING CONCERNS IN C#

xh1m — Thu, 12 Mar 2026 11:58:46 +0000

If you are new to building GUIs in C# using Windows Forms or WPF, you are probably about to fall into the most common trap in software development. You know, you double-click on a button in your designer, Visual Studio generates a _Click event handler for you, and you just copy-paste about 150 lines of database access, validation, and business logic straight into that function.

Well, guess what? It works. The data is saved. You are a genius.

However, in actual software development, this is a terrible structure. It is a terrible structure because you are violating some fundamental principles of Object-Oriented Programming (OOP), you are making unit testing virtually impossible, and you are going to lose points on a strict grading scheme.

Today, we are going to show you how to save your logic from your UI using a simple Model-View-Controller (MVC) structure.

THE MONOLITHIC NIGHTMARE (THE "BAD" WAY)

Let’s look at a classic beginner mistake. We have a simple form to register a new user.

Why is this a problem?

The UI (the View) now knows how your database is set up. If you move from an Oracle SQL database to an API, you have to change your UI code. If you want to test your registration logic, you have to click the button on the screen. It is too much work for the UI.

ENTER MVC AND SEPARATION OF CONCERNS

The concept of Separation of Concerns is that a program should be divided into sections, with each section being responsible for a single task. To illustrate this concept, we will introduce a simple MVC pattern:

THE MODEL: This section holds the data. It holds the properties but does not perform any work on the data.

THE VIEW: Simple UI. It displays the data and accepts input from the user. It does not make any decisions.

THE CONTROLLER: This section is the brain. It accepts input from the View, runs the business logic, interacts with the database, and notifies the View.

THE REFACTORED APPROACH (THE "GOOD" WAY)

Let us refactor that monolithic button click into three distinct, professional files.

The Model (UserModel.cs) First, we define what a user is. This is purely an # OOP data container.

The Controller (UserController.cs) Next, we extract all the database and business logic into a dedicated controller class.

The View (Form1.cs) Finally, look at how clean our button click becomes. The UI simply collects the data, hands it to the controller, and displays the result.

IMPORTANT WARNING: AVOIDING OVER-ENGINEER

A quick note for students: It's easy to get caught up in very advanced software architectures when reading about separating concerns.

For a normal course rubric, the simple controller setup above is perfectly fine. It clearly demonstrates modularity and proper separation of CRUD operations. Avoid over-complicating the solution with unnecessary use of advanced Dependency Injection frameworks or tools like Inversion of Control or Command Query Responsibility Segregation. A normal controller class with creation of your models demonstrates understanding of the basics of software architecture without over-complicating the code.

Just remember to avoid putting logic in the UI, and you'll have a professional-grade codebase.