← BBS SG Bank submission · All documents

06 — Per-Teammate Medium / LinkedIn Post Outlines

Submission rule: *an original public Medium or LinkedIn post from each team member. This file is a starting outline per person**, not a finished post. Every member must rewrite it in their own voice, add their own screenshots, and replace the placeholders with what they actually did. Do not publish identical text across members — that fails the rule.

Honesty rules for every post

wall-clock figures are 28.6x (1200×400) and 128.1x (5000×500) — quote them only with the disclosure: synthetic fixtures, a deliberately inefficient legacy whole-file rewrite, and not a general claim about COBOL. Link the transcript you cite (scripts/evidence/).

complete (ForgeScore 57/100, Developing; raw report not exported; docs/forge/assessment.md is a team transcription); Intent v1, PRD-Spec v1, Architecture v1 and User Stories v1 (6 epics / 33 proposed stories) are approved and downloaded, and Testing v1 (132 proposed cases) was generated/exported without an approval step (no Approve action was shown) — all into docs/forge/ (SHA-256 in docs/forge/README.md). Never claim Forge generated the modern Python, deployed anything, implemented the 33 stories, ran the 132 tests, or built its proposals** (safe temp-file replacement, append-only audit, FastAPI, Forge Shipping are not implemented) — the engine is our own local code and the local suites are 108 passing.

personal contribution is plagiarism-adjacent and reads as filler.

Post ownership map

MemberRoleOwned area (edit to match reality)Post anglePost URL
{MEMBER_1_NAME}{MEMBER_1_ROLE}Legacy assessment / COBOL analysis"How I read 172 lines of COBOL and found the bottleneck"{MEMBER_1_POST_URL}
{MEMBER_2_NAME}{MEMBER_2_ROLE}Target architecture + modern/bank.py"Rewriting a flat-file batch as an in-memory index without changing a byte"{MEMBER_2_POST_URL}
{MEMBER_3_NAME}{MEMBER_3_ROLE}Parity harness + tests + Forge Testing"Making a migration provably safe: byte-identical parity tests"{MEMBER_3_POST_URL}
{MEMBER_4_NAME}{MEMBER_4_ROLE}Forge pipeline lead + delivery + presentation"Driving a legacy modernization through the Opsera Forge pipeline"{MEMBER_4_POST_URL}
Add rows if there are more/fewer members. One row = one required post.

Member 1 — Legacy assessment / COBOL analysis

Contribution placeholder (fill first): {MEMBER_1_CONTRIBUTION — e.g. "I read bank.cob, documented the data contract, and flagged the L108/L133 double scan."}

Angle: the archaeology of understanding legacy code before touching it. Hook: "This 172-line COBOL program is a bank's overnight batch. Two lines explain why it gets slower every year — and neither is about how fast COBOL is."

LinkedIn outline (~180 words):

  1. Hook (above), with a screenshot of bank.cob L108 and L133.
  2. What the program does: reads operations, then — for each one — rescans all accounts and

rewrites the file.

  1. Why that's O(operations × accounts), in one plain sentence.
  2. The data contract I documented (fixed-column fields at (1:8), (10:12), …) and why it

matters for compatibility.

  1. What surprised me about reading legacy code {MEMBER_1_SURPRISE}.
  2. One takeaway: find the cost before you find the replacement.
  3. Links: https://github.com/vasanthsreeram/bbs-sg-bank-modernization, demo https://bbs-sg-bank-demo.pages.dev/media/bbs-sg-bank-demo.mp4, hosted https://bbs-sg-bank-demo.pages.dev.
  4. Hashtags: #LegacyModernization #COBOL #SoftwareEngineering #Hackathon.

Medium outline (~600–900 words): expand with the exact offsets table, a before/after diagram of the write pattern, and a paragraph on the difficulty of testing bank.cob in isolation (it re-opens files per op).

Member 2 — Architecture + modern implementation

Contribution placeholder: {MEMBER_2_CONTRIBUTION — e.g. "I designed the dict-indexed run() and wrote modern/bank.py, then wired the demo service to the unmodified engine."}

Angle: changing the cost model while freezing the behaviour. Hook: "How do you make a batch 100x-faster-sounding without lying? You don't quote a number — you change the algorithm from O(M×A) to O(M+A) and prove the output is identical."

LinkedIn outline (~200 words):

  1. Hook.
  2. The decision: the flat file was incidental state — replace the shuffle with a dict index.
  3. Show the 45-line modern run(); point at the single write_text at the end.
  4. The constraint we refused to break: the on-disk format and stdout contract stay the same.
  5. A code snippet: the validation block (bank.py L28-38) mirroring legacy rules.
  6. What I'd do differently {MEMBER_2_LESSON}.
  7. Links + hashtags.
  8. Honesty line: "We publish the algorithm and the parity test, not an unmeasured ratio."

Medium outline: include the ADR (don't port the shuffle / do index / keep semantics) and a walkthrough of one operation end-to-end.

Member 3 — Testing / parity harness / Forge Testing

Contribution placeholder: {MEMBER_3_CONTRIBUTION — e.g. "I wrote scripts/benchmark.py that generates identical fixtures and asserts byte-identical output."}

Angle: proof over promises — how to make a rewrite safe. Hook: "A migration is only as good as the test that can catch it being wrong. Here's the harness that runs the old COBOL and the new Python on the same data and refuses to let them disagree."

LinkedIn outline (~200 words):

  1. Hook.
  2. The risk: a faster batch that computes different balances is worse than a slow one.
  3. The approach: one fixture generator feeds both programs; assert identical stdout and

byte-identical accounts.dat (the parity_ok gate in scripts/benchmark.py). Show the parity: … byte-identical: YES line from scripts/evidence/benchmark-1200x400.txt.

  1. Why "identical bytes" is a stronger claim than "same totals."
  2. The edge cases we explicitly inject: insufficient funds, self-transfer, missing

destination.

  1. The gap I found: malformed amounts used to crash the modern batch — I wrote the failing

case, we added the guard (bank.py L23-25), and it's now a passing test. Documenting a defect you then fix beats hiding it.

  1. One deliberate divergence worth stating: modern rejects duplicate account IDs and

12-digit balance overflow, where the legacy COBOL rewrites duplicate rows and truncates the overflow — fail-closed instead of silently corrupting a balance, pinned in tests.

  1. The measured payoff, with the caveat: with an isolated GnuCOBOL 3.2.0 we timed both —

28.6x at 1200×400 and 128.1x at 5000×500. Say plainly that the fixtures are synthetic and the legacy design is deliberately inefficient, so the ratio is a property of that algorithm, not of COBOL.

  1. scripts/test_bank.py now holds 33 tests (parity, contract, characterization, an

end-to-end benchmark) alongside the 5 engine tests, and the terminal suite runs the real COBOL (legacy-ui/, 20 tests).

  1. Takeaway: write down what's broken; it builds more trust than a green checkmark.
  2. Links + hashtags.

Medium outline: walk through benchmark.py section by section; include the AT matrix and the AT-11 fix.

Member 4 — Forge pipeline lead / delivery / presentation

Contribution placeholder: {MEMBER_4_CONTRIBUTION — e.g. "I mapped our process to the Forge pipeline stages and built the demo site + docs + slides."}

Angle: using Opsera Forge as the spine of the modernization, not a side tool. Hook: "We didn't just modernize a bank's COBOL batch — we drove the planning through a pipeline: Assessment, Intent, PRD-Spec, Architecture, User Stories, Testing, Delivery. Forge authored the planning artifacts; we wrote the engine."

LinkedIn outline (~200 words):

  1. Hook.
  2. Why process matters: a rewrite without a spec is a gamble.
  3. The Forge stages, the live project we created from the legacy ZIP, the completed

Assessment — ForgeScore 57/100 (Developing), 10 findings incl. 3 high — and the Intent v1, PRD-Spec v1, Architecture v1 and User Stories v1 (33 proposed stories) documents approved and downloaded, plus Testing v1 (132 proposed cases) generated/exported (not approved), into docs/forge/ (hashes recorded) — the stories/tests are planning proposals, not shipped code or runs (link 04-forge-pipeline-mapping.md).

  1. Draw the line clearly: Forge assessed and framed the work; we wrote the modern engine

ourselves. State this explicitly — it's the honest version and it still shows real Forge use.

  1. Keying it honest: every stage maps to a file under docs/forge/; pending stays pending.
  2. Delivery: hosted app, ≤3-min demo, before/after, one post per teammate.
  3. A lesson about shipping under a deadline {MEMBER_4_LESSON}.
  4. Links + hashtags.

Medium outline: the full pipeline narrative with the stage table, what Forge changed vs. how we'd have done it by hand, and the submission checklist.

Cross-post checklist