How we work at Lamp

You may have seen this. You describe what you need, and a few weeks later the demo isn't what you meant. Your request passed through an account manager and a project manager before it reached a developer, and some of the meaning fell off at each step. A longer specification doesn't fix it. It just takes longer to go out of date.

What we do. You talk directly to the developers building your software, and they ask you when something isn't clear rather than guessing. We try to understand the business problem behind the request, build in small steps you can see and try, and tell you plainly when a change or a shortcut costs more than it looks.

Read part 1: Requirements and communication →

You may have seen this. You ask for one small change and something unrelated stops working. After a while every change feels like a gamble, so you stop asking, and the software quietly stops keeping up with the business.

What we do. Every change runs through a suite of automated tests that checks the whole system still does what it's supposed to. On top of that, an extensive set of automated checks reads the code itself and catches whole categories of mistake before they exist. Once we've seen a bug, we can usually write a rule that makes it impossible to write again.

Read part 2: Automated testing and code checks →

You may have seen this. There's one developer who knows how everything works. Every question goes to them and every tricky change waits for them. When they leave, the knowledge leaves with them, and the next developer inherits code that works but that nobody can explain.

What we do. Every change is reviewed by another developer before it goes in, so at least two people understand every part of the system. Code is formatted to one standard by tools, so it all reads the same. And when we make a decision that matters, we write down why, next to the code, where the next developer will find it.

Read part 3: Code review and shared knowledge →

You may have seen this. Something breaks on Thursday evening. The first you hear of it is a customer complaint on Monday. By then it's affected a lot of people, and when you ask what happened the answer is "we think it was probably...".

What we do. An alerting system tells us the moment an error appears on the live system, usually before anyone has noticed. And proper logging means we can see exactly what the system was doing at the time, so the fix comes from reading what happened rather than guessing.

Read part 4: Alerting and logging →

You may have seen this. Releases are rare, so weeks of work goes out at once. The run-up is a stream of last-minute questions: can this fit in, is that bit finished, if we hold it back when's the next chance? Someone stays late. Then something breaks, and because thirty changes went out together nobody can tell which one caused it. The lesson everyone draws is to release less often, which makes each release bigger and riskier. That's the trap.

What we do. Releases are small, frequent and boring. Nothing ships without passing the full set of automated checks, so "is this ready?" is answered by a machine. New work can be seen on staging before it goes live. And a genuinely big feature goes live switched off, then gets turned on gradually: your team first, then a few customers, then everyone. If there's a problem, it's off in seconds. There's no release day because every day is release day.

Read part 5: Release process →

You may have seen this. The feature you asked for in March is still "nearly there" in June. Bringing in extra help doesn't speed things up either, because a new developer spends their first fortnight getting set up and pulling your one experienced person off their own work to help.

What we do. We use AI tools to write code, and with the checks above in place it's a significant speed-up without lowering the bar. Our development environments are fully scripted: set up your keys, run one command, and about five minutes later a new developer is ready to work.

Read part 6: AI-assisted coding and dev environments →

You may have seen this. In the first year, features arrive quickly. By the third, one that sounds just as simple takes three times as long, and someone suggests starting again from scratch. Each shortcut made sense at the time, but the parts are tangled together and the libraries underneath are years out of date.

What we do. We build the system in parts with clear jobs and clear boundaries, so the parts that need to change can and the rest stays put. We keep things as simple as the problem allows, adding complexity only when it earns its place. And we keep frameworks and libraries up to date a little at a time, so an upgrade never becomes a project.

Read part 7: Designing for change →

You may have seen this. You've been told there are backups. Nobody has ever restored one. And there's probably a server somewhere that was set up years ago by someone who's since left, and everyone is quietly hoping it never dies. You won't find out how long recovery takes until the day you need it.

What we do. Every server we run is built from a script, so the whole system can be rebuilt from scratch without anyone having to remember how it was configured. And at least once a quarter we run a fire drill: take a backup, bring the system up from it, and check everything works. If we ever have to do it for real, we've done it recently and we know how long it takes.

Read part 8: Disaster recovery →

You may have seen this. Developers need realistic data to test with, so copies of the live database end up on laptops and test servers. Nobody's quite sure how many copies there are or who has them. It only becomes a question when a breach story is in the news.

What we do. We test against a slimmed-down, anonymised copy of the live database. Real-world messiness, so we catch the problems made-up data misses, but no actual customer information leaves the live system. As a side effect, the backups get restored and used all the time, which is a continuous check that they work.

Read part 9: Anonymised test data →

You may have seen this. Your software went live a while ago, it still works, and nobody has touched it since. Underneath it, the operating system, the database, the framework and dozens of libraries have all had security holes found and announced. Attackers start scanning for anyone who hasn't applied the fix within hours of the announcement.

What we do. Every system we build comes with an ongoing support and maintenance contract. We keep the whole stack current, from the operating system up to the libraries in your code, and respond quickly when something serious is announced. The automated tests from part 2 are what make that routine: apply the update, run the tests, ship it.

Read part 10: Support and maintenance →