Kavita Salve teaches computer science to thirty-two students of class eleven in a government school in Bhopal. The lab has fourteen desktops that switch on, all running Windows 10, all locked down by the district's IT contractor. The administrator password is with the contractor. He visits once a month and his next visit is in nineteen days.

She had two options and both cost something.

The first was to teach the whole term in a browser. A free notebook service starts in about thirty seconds, needs nothing installed, works on the four students' phones as well as on the desktops, and cannot be broken by anything a student does. The cost is that the lab shares a four megabit connection with the office, and every morning at about twenty past eleven the block's attendance upload saturates it for fifteen minutes. It is also, in her words, a place where code goes to be forgotten: the notebook hides where the file is, students never save anything they can find again, and a program becomes something that only exists while a tab is open.

The second was to get Python on the machines. The installer from python.org wants administrator rights. The store version does not, but the store requires a signed-in account and the machines have none. She could wait nineteen days for the contractor, or she could write to the district office and wait longer.

A colleague suggested a third way that she had not considered: a portable build of Python, copied from a USB stick into each machine's own user folder, which needs no administrator and no store. It runs. It also cannot tick the Add Python to PATH box, because there is no installer doing the ticking, so the command is not python. It is a path eleven characters longer, typed at the start of every line, or a batch file she writes for them.

The decision was not really about Python. It was about what the first three lessons of the term were going to be. Three lessons on installation is three lessons of a fifteen-week term spent on something no exam asks about, with a real chance that on lesson three four machines still do not work and those students have done nothing. Three lessons on code means the browser, and the browser means that in February, when a student sits at a cousin's laptop and wants to run what she wrote in September, none of it is there and none of the commands she knows apply.

The head teacher, who signs the internet bill, had a view of his own. He wanted the browser, because a lab of machines with software installed by a teacher is a lab he gets asked questions about when something stops working.

Kavita made her choice on the strength of one thing she had seen the previous year. In the board practical, students are given a printed program and asked what it prints. Her class had done badly on it — not because they could not code, but because they had only ever seen code in a cell that prints the value of the last line automatically. Asked what a saved file prints, half of them included values the file never printed. That is a gap the browser had created and she could see it in the marks.

The placement cell at a private engineering college in Coimbatore runs a matching exercise every December. Nine hundred and twelve final-year students, forty visiting companies, and for each company a list of conditions: a minimum aggregate, an allowed set of branches, sometimes a backlog rule, sometimes a bar on students already holding an offer above a certain package.

The script that does it was written three years ago by a student who has since graduated. It works. It is also seven nested loops over lists, and it takes twenty-six minutes for a full run on the cell's one laptop.

Twenty-six minutes was tolerable when the rules were fixed. This year they are not. The companies send revisions — a branch added, a cut-off dropped from seventy to sixty-five — and each revision means another run. On the Tuesday, the coordinator, Divya, ran it nine times and lost most of the working day to waiting. The shortlists are due Friday morning and eleven companies have still to confirm their final conditions.

A colleague in the CS department looked at the script for twenty minutes and found the shape of the problem. Buried in the innermost loop was a line that asked, for every student and every company, whether that student's roll number appeared in a list of students already placed. That list had grown to four hundred and ten entries, and Python was scanning it from the start, every time, four hundred thousand times over the run.

His proposal was small: build a set of placed roll numbers once, before the loops, and change one line. He estimated ten minutes of work and a run of under a minute afterwards.

Divya's objection was not about the code. It was Wednesday. The script produced shortlists that the college had been sending to companies for three years, and the results were trusted. A change to a working program four days before a deadline, made by someone who had not written it, was a risk with a specific shape: if the new version quietly dropped or duplicated students, nobody would notice until a company asked why a shortlisted student had never been told, and that is a conversation the college has once and then loses the company.

Against that was the cost of not changing it. Eleven confirmations still to come meant at least eleven more runs, five hours of waiting spread across two days, and the real danger that the last revision would arrive at eight on Thursday evening with the printing to do.

The head of the cell asked one question that decided it: can you prove the new one gives the same answer as the old one?

There was a second thing in the file that the CS colleague noticed and did not mention on the Tuesday, because it was not the bottleneck. Every company's allowed branches were stored as a list of strings, and every student's branch was compared against it with the same in. Forty companies, nine hundred students, a list of six branches each: small enough to be invisible next to the four hundred thousand scans, and the same shape of mistake.

What made the twenty-six minutes hard to argue about was that nobody in the room could point at the slow line by reading the code. The nesting was seven deep and every loop looked reasonable on its own. The colleague had not found it by reading either; he had run the script with cProfile while making tea, and the top of the output said that ninety-four per cent of the time was inside one membership test.

Divya's other worry was the input file. The cell receives student data as a spreadsheet export, and it had grown two columns since the script was written. A rewrite that touched how records were read might quietly change which column the aggregate came from, and an aggregate read from the wrong column produces shortlists that look completely normal.

Sahyog runs forty learning centres across three districts and reports monthly to the funder: attendance per centre, per class, per gender, with a comparison to the previous month. Until last year this was four days of somebody's time in a spreadsheet.

Then a volunteer, an engineering student named Ankit, wrote a script. It reads the attendance sheets that field staff send as CSVs, cleans the centre names, computes the tables and writes the report. It reduced four days to about forty minutes, most of which is Ankit's script asking questions.

Eleven questions, in fact. When you run report.py it asks for the month, the year, the input folder, the output folder, whether to include the new centres, whether to use the corrected September figures, and five more. The answers go into input() calls. Ankit knew all eleven by heart.

Ankit finished his degree in June and took a job in Hyderabad. The person now running the script is Rekha, who manages the programme and does not write code.

In August the funder asked for two changes: split the attendance by class as well as centre, and email the report on the first of each month rather than whenever somebody remembers. Rekha found a volunteer, a second-year student called Farhan, and asked him to do it.

Farhan opened the file. Seven hundred and forty lines, no functions, one long run from top to bottom, with the cleaning, the arithmetic, the formatting and the printing interleaved. Variables called df2, df3 and temp. The correction for the September figures was a block in the middle guarded by an if that read the answer to question seven.

He gave Rekha two estimates. Patching it: about a day, maybe two, for the class split. He could find the place where the totals are computed and add another grouping next to it. The email, he said, was the problem — a script that stops to ask eleven questions cannot be run by a scheduler at two in the morning, so either somebody sits and answers them on the first of every month, or the questions have to go.

Restructuring it: four days. Split the file into functions with arguments and return values, move the eleven questions to command-line options with defaults, put the reading in one module and the arithmetic in another, and write the two or three checks that would tell them whether the new version agreed with the old.

Four days of a volunteer's time, in the middle of the reporting cycle, produces nothing the funder can see. Rekha had been given the volunteer for six weeks. Spending most of the first week on a report that already worked was a hard thing to justify to her own director, who had asked for the class split and did not care how the file was arranged.

And there was a specific risk she could name. Ankit was gone. If Farhan restructured the script and then his exams started, Sahyog would be holding a half-rearranged program that neither of the two people who understood it was available to finish.

The clinic sends a reminder message the evening before an appointment. Around ninety a night. The script was written by the receptionist's nephew, Sameer, who is in his final year of a BCA and comes in on Sundays.

On a Tuesday in March the clinic's manager, Dr Phadke, noticed that the no-show rate for the week was thirty-one per cent. It had been running at eleven. She checked the log file. Every night for nine days it said the same thing: Reminder job finished. 0 errors.

Sameer found the cause in about an hour. Nine days earlier the message provider had changed the name of one field in its reply, from message_id to id. The script read the old name, which raised a KeyError. And the whole send loop was inside this:

try: ... except: pass

So every message failed, silently, and the loop went on to the next patient. The counter that printed 0 errors was incremented in the except branch of a different try, further down, that had never been reached.

The fix itself was five minutes: read the new field name. Sameer pushed it on the Tuesday evening and the reminders went out that night.

The decision came afterwards, and it was Dr Phadke's, not his. She wanted to know what would stop the next one. Sameer offered three things and estimated them honestly.

Removing the bare except and catching only what he had a plan for: half an hour. Cheap, and it would have turned the nine silent days into a crash on night one.

Logging properly, with levels, so that a failed send wrote an ERROR line with a traceback rather than nothing: two hours.

Tests: a day, and this was the one he was reluctant about. The part he most wanted to test was the sending, and sending is where the money and the patient data are. A test that really sends is a test that texts ninety people every time somebody runs it.

Against all three sat the clinic's actual constraint. Sameer is there on Sundays. A day of his time is a month of the clinic's access to him, and in that month Dr Phadke had also asked for the reminders to go out in Marathi for the patients who prefer it.

She asked him what a day of tests would have caught here. He said, if he were honest: nothing. A test of the message formatting would have passed the whole nine days, because the formatting was fine. What broke was a field name in somebody else's reply, and the only test that would have seen it is one that calls the real service.

There was one more thing in the log that Dr Phadke wanted explained. The nightly line said Reminder job finished, and it had said that on every one of the nine nights. It was a print statement at the end of the file, and it printed whether or not anything had been sent, because nothing between it and the loop could stop the program from reaching it. She had been reading it as confirmation for two months.

Sameer's own view of the bare except was worth recording, because it is the reason the pattern exists at all. He had put it there deliberately, in the first week, after a single bad phone number in the patient list stopped the whole run at patient nineteen and seventy people got no reminder. Catching everything and continuing had genuinely fixed that problem. It had also, in fixing it, thrown away the difference between one bad number and every message failing.

What he wanted, and did not know how to ask for at the time, was to continue past the failures he expected and stop on the ones he did not.

Every month the block education office collects a return from ninety-one schools: enrolment, meals served, days the kitchen ran, and the names of the cook-cum-helpers who are to be paid. The schools send spreadsheets. The office combines them into one file and uploads it to the state portal.

Biraj, a data entry operator who taught himself Python from videos, wrote the combining script in January and it saved the office three days a month. In May the portal started rejecting the file.

The error from the portal said only: invalid characters in row 214. Biraj opened the combined CSV in Excel and the names in Assamese script were question marks. Not all of them. The first forty-odd rows were fine. Some of the rest were question marks and some were sequences like রাজ.

He spent a day and a half on it, and what he eventually found was that the office was handling three different things at once, all called text.

One group of schools sends .xlsx files. Those are read by a library and arrive as proper Unicode; they were the rows that were fine.

A second group exports CSV from a much older machine, where the school clerk saves from a version of Excel that writes in the local Windows code page. Those files could not represent the Assamese characters at all, so Excel had substituted question marks before the file ever left the school. Those bytes were gone. Nothing in Biraj's script could recover them.

A third group sends CSVs that are genuinely UTF-8. Biraj's script opened every CSV with a plain open() and no encoding argument, and on the office's Windows machine that meant the code page again. Those names were being read wrongly on his side. The bytes were intact; only the label was wrong.

So he had two problems that looked identical on screen and were not the same at all: one where the data was destroyed at the source, and one where he was mislabelling data that was fine.

The decision was what to do about the first group, and it had a cost either way.

He could write the combined file as UTF-8 with a byte order mark, which is what makes Excel on Windows open it correctly by double-clicking. That would help the schools, who check the combined file and complain when names look wrong. But the state portal is a program, not Excel, and Biraj did not know whether it would treat those three extra bytes at the start as part of the first column name.

Or he could write plain UTF-8, which the portal would certainly accept, and accept that every school that opens the file to check it sees mangled names and telephones the office about it. The office has two phone lines and a fortnight of the month when nobody can use them anyway.

The deeper choice was whether to fix the twenty-two schools at the source, which meant a circular to clerks with the words save as CSV UTF-8 in it, and a follow-up call to each, and a month in which some of them get it wrong.

Padhaai Labs sells a writing-feedback tool to twelve schools. Every night it sends the day's essays to a model API, which returns a set of tags and a short comment for the teacher. About forty thousand essays a month, at roughly two paise each in model cost, which is a bill the company can carry.

The job used to fail about once a week. A connection would drop somewhere between Indore and the provider's servers, one call would raise, and the whole run would stop with two-thirds of the essays untagged. The next morning somebody would restart it and the teachers' comments arrived at lunchtime instead of before first period.

So Anuj, who wrote it, added retries. He used the Retry object that comes with urllib3, set five attempts with exponential backoff, and — because the calls that were failing were POSTs, and retrying only GETs would have fixed nothing — added POST to allowed_methods. The weekly failure stopped. Nobody thought about it again for four months.

The bill for March was 2.7 times February's. The volume of essays had gone up by about eight per cent.

It took Anuj most of a day to find it, because the tagged output looked correct. Every essay had exactly one set of tags in the database, because the database write was keyed on the essay id and the second write replaced the first. The evidence was only in the provider's usage export: on some nights, several thousand calls more than there were essays.

The mechanism turned out to be the read timeout. He had set timeout=20 for the whole call. Most replies came back in three or four seconds, but a long essay with a slow model could take twenty-five. When that happened, the request had been received, the model had generated the tags, the provider had billed for the tokens, and the reply was still on its way when Python gave up waiting. The retry then sent the same essay again. Sometimes twice. Once, on a bad night in the second week of March, five times for the same essay.

He now had a decision, and both sides of it cost money.

He could stop retrying POSTs. That is the correct default and it is why urllib3 excludes them. The cost is the thing he had fixed four months earlier: the job goes back to dying on a dropped connection, at two in the morning, and the teachers get their comments at lunchtime, which is the complaint that started all of this.

He could keep retrying and raise the read timeout to ninety seconds, so that a slow reply is waited for rather than abandoned. That removes most of the double billing but not the case where the connection genuinely drops after the server has done the work, and it makes a truly hung call cost ninety seconds of the run rather than twenty.

The third option was the one the provider's documentation had been suggesting all along and which he had not read: an idempotency key. You generate an identifier for each logical request, send it on every attempt, and the server returns the first result rather than doing the work again. The cost there is that not every endpoint he uses supports it, and he would have to check.

Khula Khata publishes a weekly digest of tenders issued by four municipal corporations. A scraper collects the PDFs, a model summarises each one in about eighty words, and a volunteer editor checks the summaries before they go out. Roughly six hundred documents a week.

In February their model provider changed its pricing, and the summarising step went from about nine hundred rupees a week to about three thousand two hundred. For a group funded by two small grants, that was the difference between publishing weekly and publishing when they could.

The obvious response was to move to a cheaper model. There were three candidates: a smaller model from the same provider, a model from a different provider with a different reply format, and an open model they could run themselves on a rented machine for a fixed monthly cost.

The problem was the code. The provider's client object appeared in eleven places across four files. Two of those places unpacked the reply structure by hand. One built a request with a parameter that only that provider accepts. The team's developer, Meghna, described it accurately: the program did not call a model, it called that company.

She put two options to the other two.

The first was an afternoon. Find and replace the client, fix whatever breaks, run the pipeline on last week's documents and read twenty summaries. If the new provider works out, they have saved two thousand rupees a week by Friday. If it does not, they do the afternoon again for the next candidate.

The second was two days. Define one small class with one method — take the messages and the system prompt, return a string — and write a subclass for each provider that absorbs the differences: the argument shapes, the reply structures, the error types. Then the rest of the program holds a provider object and never knows which one it is. Two days in which nothing is published and no money is saved, in exchange for being able to try the third candidate in twenty minutes rather than an afternoon.

The argument against the two days was not only time. The editor, Farid, had watched a previous volunteer spend a fortnight building an abstraction over three databases they turned out never to need. His question was fair: are we writing a class because we will change providers again, or because writing classes feels like progress?

Meghna's answer was that they were going to change providers at least twice this month, because they had three candidates and no way to compare them except by running the real pipeline on real documents.

There was one more thing pushing at the decision. Nobody in the group could say what the pipeline actually cost per document, because the summarising and the PDF text extraction and the scraping all ran in one script and the whole thing took about forty minutes. Meghna assumed the extraction was the slow part, because PDFs are famously slow.

There was also a smaller mess she had inherited and never mentioned. The reply from the provider was unpacked by hand in two of the eleven places, with different assumptions in each: one took the first element of the content list, the other joined every element. For most tenders those give the same string. For the four or five a week where the model returns a second block, they had been giving different summaries for months, and nobody had matched them up because the two paths ran on different days of the week.

Meghna's own instinct, before the stopwatch, had been to leave the structure alone and cache the summaries instead. A tender document does not change once issued, so a re-run should not pay twice. That instinct was right and stayed on the list; it simply was not the thing standing between them and a cheaper provider this week.

The cooperative collects milk twice a day from 4,217 members across thirty-one villages. Payment is monthly and works from two files: the collection records, one row per member per session, and a member master with the bank account, the rate category and any deductions for cattle feed taken on credit.

For eleven years this was done in a spreadsheet by a clerk named Sunil, who is retiring. His successor, Pooja, has a BSc in statistics and had spent three weeks moving it into a pandas script that reads both files, groups the collections by member and month, joins the member master, applies the rate and the deductions, and writes the file the bank uploads.

On the morning of the run she did the check she had been taught to do: the number of rows before a join and after it. The grouped collections had 4,217 rows, one per member. After merging the member master it had 4,261.

Forty-four extra rows. The total to be paid had gone up by about ninety-one thousand rupees.

The cause took her an hour. Forty-one members appeared twice in the member master and one appeared four times, because when a member changes bank account the cooperative's old software adds a row rather than replacing one. The merge matched each collection row against every matching master row, which is what a join on a repeated key does, and produced a payment line for each. Two of the duplicates had different rate categories, because a member had moved from one category to another in 2023 and both rows survived.

She could see three ways forward and the deadline was one o'clock, when the file has to reach the bank for same-day credit.

The first was to deduplicate the master by member id, keeping the most recent row, and run. Fifteen minutes. The risk is the account number: if the most recent row is the stale one — and she did not know how the old software ordered its rows — forty-one members are paid into closed accounts, which the bank returns three days later and which each require a phone call and a visit.

The second was to fall back to the spreadsheet for this month, which Sunil could still do, and fix the script properly in June. The cost is a day of a retired man's time, an admission on her third week that the new system is not ready, and the same forty-four rows waiting in June.

The third was to hold the whole run until the duplicates were checked against the branch, which would be tomorrow at the earliest. Four thousand two hundred families paid a day late in a month when the school fees fall due.

The check that caught it was not something Pooja invented on the day. Sunil had done the same thing in the spreadsheet for eleven years, in his own way: the total on the payment sheet had to match a figure he wrote in pencil at the bottom of the collection register before he started. He could not have said which pandas function corresponds to that, and it is the same invariant.

What had made her nervous all week was a different number. The collections file for the month had 253,014 rows, and pandas had read the member id column as an integer in one file and as a string with a leading zero in the other, so an earlier draft of the script had merged on nothing at all and produced a payment file with 4,217 rows and every amount zero. That failure was loud. It was the reason she had started printing row counts and sums between every step, which is why she was in the habit that morning.

The helpdesk sees about sixty people a week: pension arrears, land mutation, ration card exclusions, school admission under the reserved quota. Two paralegals answer most of it from experience. The experience is the problem — one of them, Shalini, is leaving in October, and what she knows sits in eleven years of handwritten case notes, typed up by a volunteer into about three thousand pages of documents, and in a folder of state circulars nobody has indexed.

A volunteer developer, Arif, offered to build a search. Not a chatbot for the public — the helpdesk's lawyer was firm about that — but a tool the paralegals use, which finds the three or four passages most likely to answer a question and shows them with the file and the page they came from.

He had the pieces. Chunk the documents, embed each chunk, save the matrix, embed the question, take the top few by cosine similarity, show them. Sixty lines, most of which he had written before.

The decision was which embedding model, and it was not a technical preference.

A hosted embedding model would cost about four hundred rupees to index everything once and almost nothing per query. It is measurably better on Hindi, and about a third of the notes are in Hindi and a good many are in both languages in the same paragraph. It also means every case note leaves the building: names, addresses, the details of a woman's dispute with her brother-in-law over a plot of land, sent to a company in another country under terms nobody at the helpdesk has read.

A free model running on the office laptop costs nothing and nothing leaves the room. It is slower to index — Arif estimated two hours for three thousand pages on that machine — and the small English-first models are noticeably weaker on Hindi. There are multilingual open models that do better, at three times the memory, on a laptop with eight gigabytes that also runs the office's accounting software.

The lawyer, Mr Verma, asked the question that framed it: if a client asked us where their case note is stored, what is the true answer?

Against that, Shalini's point was equally concrete. A search that misses the Hindi notes is a search that misses her Hindi notes, which are most of the ones about pension arrears, which is the largest single thing the helpdesk does. A tool that works well in English and poorly in Hindi will be used for a month and abandoned, and she leaves in October.

Arif had one more constraint that shaped the build more than either model did. The office laptop is shared: the accounting software runs on it every afternoon, the machine is switched off at night by whoever leaves last, and there is no server anywhere in the building. Anything that had to stay running was not going to survive contact with that room.

So the tool is a script the paralegals start from a shortcut, which loads the matrix and the notes into memory in about four seconds and opens a small local web page. Nothing runs when nobody is using it. The monthly re-index is a scheduled job that checks for a lock file first, because the first week Arif ran it, two copies started at once — the scheduler and a paralegal who had double-clicked the shortcut — and the two of them wrote a half-finished matrix over a good one.

He restored it from the previous month's copy, which existed only because he had been lazy and never deleted it, and then wrote the four lines that make the job refuse to run alongside itself.