Module 99: Technology Governance

Why each option is right or wrong

• “Money a company owes for servers and software licences” (Incorrect): That's financial debt, not technical debt.
• “The total number of open bugs in the bug tracker that haven't been fixed yet” (Incorrect): Bugs can be a symptom, but debt is about what makes change hard.
• “Old features that users no longer use or need, but which are still in the app” (Incorrect): Unused features can add debt, but debt is broader: shortcuts that slow change.
• “Shortcuts in code or design that make future changes slower and riskier” is correct.

  Like a loan, a shortcut gives you speed now but costs "interest" later: every change to messy, untested or tangled code takes longer and breaks more easily. Some debt is a deliberate choice; some builds up without anyone noticing.

  • Examples: missing tests, copy-pasted code, outdated libraries.
  • Pay it down: a little every sprint.

📖 Revise: Lesson 1: Technical debt

Why each option is right or wrong

• “Whenever the team wants to move faster, since it costs nothing” (Incorrect): Debt has a real cost later in slower, riskier changes.
• “Only for small projects that will be thrown away soon” (Incorrect): Throwaway code can carry debt, but planned debt is also reasonable in long-term projects.
• “It can't be, because all technical debt must be avoided” (Incorrect): Some deliberate, recorded debt is a reasonable trade-off.
• “To hit an important deadline, with a plan to pay it back” is correct.

  Sometimes speed matters more, such as a launch or a contract date. Taking a shortcut on purpose is fine if you record it and schedule time to clean it up. Debt becomes a problem when it's hidden or left unpaid.

  • Record it: in the backlog with the reason.
  • Agree: when it will be fixed.

📖 Revise: Lesson 1: Technical debt

Why each option is right or wrong

• “A log of every commit made to the main branch, with who made it and when” (Incorrect): That's Git history; an ADR explains a decision.
• “A diagram of all the servers in the system and how they're connected” (Incorrect): Diagrams can go in docs, but an ADR records a decision and its reasons.
• “A signed contract with a technology supplier, listing the service levels” (Incorrect): Contracts are legal documents; ADRs are team notes.
• “A short document recording a decision, its context, options and consequences” is correct.

  An ADR captures why a choice was made, such as "PostgreSQL over MongoDB", including the situation, the options considered and the expected trade-offs. Months later, the team can understand the reasoning instead of guessing.

  • Keep them: in the repository, numbered.
  • Superseded: write a new ADR, don't edit history.

📖 Revise: Lesson 2: Reviews and decision records

Why each option is right or wrong

• “They give managers a way to measure each developer's speed” (Incorrect): Using reviews to rate people discourages honest feedback.
• “They're mainly for training junior developers” (Incorrect): Everyone benefits, including seniors.
• “They make sure only senior developers' code is merged” (Incorrect): Anyone's code can be merged after review.
• “They spread knowledge and keep standards consistent” is correct.

  When someone reviews a change, they learn that part of the code, and the author learns from their feedback. Reviews keep style, testing and security practices consistent, so the codebase feels like one team wrote it.

  • Kind and specific: comment on the code, not the person.
  • Small PRs: are easier to review well.

📖 Revise: Lesson 2: Reviews and decision records

Why each option is right or wrong

• “When the feature is what makes your product unique” (Incorrect): Your unique features are usually worth building yourself.
• “When the team has no budget for any paid services” (Incorrect): With no budget, paid services may not fit; that's not when buying is wiser.
• “When the team wants full control over every line of code” (Incorrect): Wanting full control is a reason to build, not buy.
• “When it's not your core advantage, like payments, email or authentication” is correct.

  Payments, email delivery and sign-in are hard to get right and secure, and they don't make your product special. Using a trusted service saves time and risk, so your team can focus on what makes you different.

  • Check: cost at scale, data location, lock-in.
  • Build: what makes you unique.

📖 Revise: Lesson 3: Build vs buy

Why each option is right or wrong

• “None once it's launched, since the code is already written” (Incorrect): Code needs ongoing updates and fixes after launch.
• “Only the monthly server hosting cost for running it in production” (Incorrect): Hosting is one cost; maintenance and support are bigger.
• “Only the time spent writing its documentation and user guides at launch” (Incorrect): Documentation is part of it, but maintenance and security are bigger.
• “Ongoing maintenance, security fixes and support, not just the first build” is correct.

  The first version is only the start. You'll need to fix bugs, update libraries, patch security issues, answer questions and adapt it as needs change, often for years. That ongoing cost is usually bigger than the initial build.

  • Estimate: the yearly cost, not just the build cost.
  • Compare: with a service's yearly fee.

📖 Revise: Lesson 3: Build vs buy

Why each option is right or wrong

• “A security feature that locks accounts after failed logins” (Incorrect): That's account lockout, not vendor lock-in.
• “A contract term that fixes prices for several years” (Incorrect): Fixed prices are a contract term; lock-in is about switching costs.
• “A free hosting plan that has no paid upgrade path” (Incorrect): That's a pricing limit; lock-in is about how hard it is to leave.
• “Becoming so dependent on one provider that switching is very costly” is correct.

  If your app uses many features unique to one cloud provider or service, moving away means rewriting large parts. That gives the provider power over prices and terms. Some lock-in is fine; just choose it knowingly.

  • Reduce: standard formats, data export, a layer between your code and the vendor.
  • Record: lock-in risks in your ADRs.

📖 Revise: Lesson 4: Technology cost

Why each option is right or wrong

• “Switch to a cheaper cloud provider straight away to limit the damage” (Incorrect): Moving without knowing the cause is costly and may not help.
• “Delete any servers and storage that look unused, to cut costs quickly” (Incorrect): Deleting blindly can break the app or lose data.
• “Pay it this month, then check again next month to see if it repeats” (Incorrect): Waiting can double the cost again.
• “Break the bill down by service and find what grew” is correct.

  Cloud bills list costs by service and resource. Find which one jumped, such as a database, storage or data transfer, then why: a traffic spike, a forgotten test server, or a bug in a loop. Then fix the cause.

  • Set: budget alerts to catch it sooner.
  • Tag: resources by project.

📖 Revise: Lesson 4: Technology cost

Why each option is right or wrong

• “Because linting tools refuse to run without written standards” (Incorrect): Tools run with defaults; standards are for the team.
• “To make sure everyone writes code in exactly the same way” (Incorrect): Some variety is fine; the aim is readable, maintainable code.
• “So that clients see the team as more professional” (Incorrect): Appearance is a side effect; the real benefit is maintainability.
• “Consistency makes code easier to read, review and maintain” is correct.

  When everyone follows the same style, test approach and security checks, anyone can understand anyone's code, reviews focus on what matters, and fewer mistakes slip through. Automate what you can, like formatting and linting.

  • Write them down: short and practical.
  • Revisit: when they stop helping.

📖 Revise: Lesson 5: Standards and technology choices

Why each option is right or wrong

• “Rewrite the whole app in it as soon as possible” (Incorrect): A full rewrite is high risk with an untested tool.
• “Let the most experienced developer decide on their own” (Incorrect): Team decisions should be shared and recorded.
• “Avoid all new tools to keep the stack stable” (Incorrect): Avoiding change entirely can leave you stuck with outdated tools.
• “Try it on a small, low-risk piece first and record the decision” is correct.

  New tools promise a lot. Trying one on a small part shows its real strengths and problems with little risk. If it works, expand its use and write an ADR explaining why; if not, you've lost little.

  • Check: maturity, community and long-term support.
  • Plan: how the team will learn it.

📖 Revise: Lesson 5: Standards and technology choices