Are your projects creating technical debt?
Categories:
software
Categories: software
 I thought I had written about this before, but I couldn’t find anything, so I figured I would tackle the topic – technical debt. We talk about debt on projects often in terms of how the project is being funded, but technical debt is different. It’s when you introduce a technical problem that will need to be resolved at some point in the future – debt that some other project or team is going to have to deal with (or maybe Phase 2 of your project). It’s where you make a short-term choice because it helps you in the moment, but it’s not the right strategic or longer term choice. These are some ways that you could be creating technical debt. Introducing manual processingIf your system expects users to do manual processing of data, such as receiving in paper forms when previously the submissions were digital, that’s technical debt. Especially with the march of AI, we are going to want to eliminate manual work, whether that’s reporting or data entry. And giving users processes and systems that are worse than what they previously had is never a good idea.Duplicating recordsIf your project duplicates data that is already in another system, that’s technical debt. You could/should be identifying which system holds the main record and linking back to that with system interfaces.Double keying for data entry is a similar thing – if you are expecting users to type the same information into two or more systems, that’s increasing the likelihood of user error. Eventually the smart product owner is going to want to automate the process or build an interface to pull the data. Increasing support ticketsIf your project has some kind of feature that you know has the potential to increase support tickets, that’s likely a sign that something will have to be fixed at a point in the future. For example, introducing an error message that people will call up about because it isn’t clear or because they can’t resolve it themselves. Or not being able to reset their own password and needing someone from tech support to do it for them.Parallel processing – 2 systems doing the same or similar thingsThis is a bit like duplicating records, but it’s more about what the systems actually do. For example, if you have two systems that process invoices, at some point in the future it would be smart to standardise the company on to one invoice handling system. Because otherwise you are paying for maintenance and user licences for two systems, including resourcing that work and having system administrators for each. That’s just not efficient, so think about whether your project introduces something similar to what you already have in place.Inefficient interfaces or integrationsAre you building system interfaces or integrating apps? Make sure you’re doing it in the most efficient way, or you’ll be back in a few months trying to unpick bad coding and streamlining it.Or more often than not, you won’t be back to fix that and your colleagues will live with the project’s bad choices for years. Sorting out a messy interface is never going to be top of the list for a strategic CIO, unfortunately. Building on old versions that need (or will need) an upgradeIf your project relies on old tech, platforms that will be decommissioned or are slated for an upgrade, the chances are that someone will have to redo your work in the future to move it (or make it suitable for) the new version. Could you reorder projects so your initiative happens after that upgrade is done and you only have to do the work once?What else do you see in your organisation’s projects that you would classify as technical debt, and how do you get those items on the radar for management so they make the right choice? |
Software testing: What to plan (Part 1)
| So many of my projects involve technical development, and if that rings true for you as well, it’s helpful to know what different types of software testing you might encounter on a project. Then you can add them to the discussions about the plan.
Just to confirm – never pop them on your schedule without talking to the right teams about how long they are going to take and when they are going to happen. But at least if you know the different types of testing, why you would use them and when they typically happen in a project, you can ask the right questions. Here we go! 1. Unit testingWhat it is: Testing individual components (e.g. functions, methods, modules) in isolation. Who does it: Developers. When: Early in development. As each individual piece of the solution is delivered, it’s tested, or you might do all the software development and then test. Why it matters: Catches logic errors early and makes debugging easier. 2. Integration testingWhat it is: Testing how components work together (e.g. how modules exchange data). Who does it: Developers or test engineers. When: After unit testing, before full system testing. Why it matters: Ensures that interfaces and data flow between parts of the system work properly. If you have an integration engine, the team responsible for that would be involved, as this is all about how different tools link together. If you have interfaces or data moving from one system to another, you’ll definitely want to factor this in. 3. Smoke testingWhat it is: A quick, shallow test to confirm that the most critical features work. Who does it: Developers or QA, often automated. When: After a build or deployment. Why it matters: Gives fast feedback before deeper testing begins. Smoke testing can happen at different points in the project. As the project manager, the question you need to ask is, ‘are we planning any smoke testing?’ and then you can decide together when to add it to the schedule. 4. System testingWhat it is: Testing the complete, integrated application as a whole. Who does it: QA/test team. When: After integration testing, before UAT. Why it matters: Verifies that the system meets technical specifications and behaves correctly. This is the important testing, and you’ll want to leave enough time for it. 5. Acceptance testing (including UAT)What it is: Validates whether the system meets business requirements and is ready for release. Who does it: End users, product owners, or business analysts. When: After system testing. Why it matters: Confirms the solution works in the real world for the people who’ll use it. While system-y people might be involved with the acceptance testing, the main focus for me is on the user testing. You’ll need to identify the right users, make sure they have access to the test system and most importantly, that they know what to do. They’ll record any bugs they find and the developers will put them right. You’ll probably want at least 2 rounds of UAT, to allow people to find bugs, fixes to be deployed and then for testing to evidence that the fixes work. Schedule in enough time for UAT testers to be trained on the system, test their access, attend a session on how to record bugs and for them to re-test the fixes. This always takes longer than you expect! Next time I’ll share four other types of testing that you might need to include in your plans. |
