davidvartanian
Complexity Cost Calculator
Agent Skill Pack: Market and Marketing and Monetization (9 and 2 Skills)
Structural Friction: A metric for human coordination cost
I was leading a team and everything felt slow. Everyone was busy, but shipping features was still very slow. We tracked velocity and story points, but those metrics don't even care about how good a business is doing or the cost of development, so I realized they were useless to me.We had a clean architecture (in theory), but it was strangling us with coordination requirements. Every minor...
Shared databases are not modular, they are just a weakness
I used to believe that defining clean interfaces and contracts between services was enough to maintain modularity. I shared a database because it seemed like the path of least resistance. I was wrong. Sharing a database or any resource that crosses the boundary to a foreign component creates a "welded" joint that defies any interface definition. It creates a failure cascade waiting to...
I canceled my Antigravity subscription today. Here is why
I was a heavy user of Google Antigravity for my development workflow. I relied on its token throughput to automate boilerplate and architectural prototyping. The recent pricing update and draconian rate limits feel like an attempt to manufacture scarcity where there should be efficiency.The new tiers create an environment where developer velocity is directly tied to a volatile vendor quota....
Why sharing domain data across microservices is a silent killer
I spent a few years working at a company where all our microservices backed into MongoDB instances. We were constantly under top-down pressure to deliver fast, and because MongoDB is schemaless, it felt very easy to just add fields to our documents whenever we needed to expose data to another service. We eventually arrived at what we thought was a genius optimization. We wrote a background...
What the 2026 AI price hikes taught me about lean engineering
I spent the last two weeks struggling with AI costs going up like crazy. I realized I had been treating AI tokens as if they were free. Like many others, I fell into the trap of using premium, Ferrari-level models to perform supermarket-run tasks. I convinced myself it was necessary because the API costs were negligible.But the subsidy era is over.The 2026 price hikes, driven by rising HBM...
Treat Interfaces as Organizational Treaties
I used to think that interface design was purely a technical concern. I focused on data structures, schema validation, and minimizing latency. I ignored the human factor. I recently realized that our teams were constantly blocked by each other, even when the APIs were well-documented.The issue was not the code. It was the lack of clear expectations. I stopped looking at our APIs as simple code...
The cost of duplicating domain data for performance
I was building a system a few years ago under immense pressure to ship. We had a choice. We could implement a new API call between two domains, or we could duplicate the domain data into multiple service databases. I argued for duplication because I believed the extra network call would compromise our latency goals, and the business demand for speed felt urgent.I remember thinking at the time...
Re:Labor market impacts of AI: A new measure and early evidence
on Sunday March 08, 2026 @07:19PM (#47302695)
That's just because everyone is misusing AI. If you ask AI to do a job and you have no idea what it did, you lost ownership, which means you're asking to be replaced. You need to own the task. If you fully delegate your task to anyone else or to AI, you no longer know what's going on.
AI does not necessarily produce more tech debt, but AI might do things you don't expect because it lacks context and specificity to perform accurately.
Re:Technical Debt Plaguing Us All
on Wednesday March 04, 2026 @03:57PM (#47253699)
I've been thinking about this exact tension for the past few years while building tools for operational efficiency.
The real predictor of long‑term pain isn't complexity per se; it's interdependence. LLMs make writing code cheap, but they don't instinctively architect for modularity. They'll happily generate a tightly‑coupled monolith that "works" today but becomes a coordination nightmare tomorrow (same as with human-implemented poor architectures).
What I've observed (Prof. Christensen's modularity framework applies here) is that teams that treat LLMs as "fast writers" but enforce "good enough" modular interfaces (clear boundaries, well‑defined jobs‑to‑be‑done for each component) can scale without the usual debt explosion. Teams that let the LLM dictate the architecture end up with a "house of cards"; every change risks cascading failures.
So the measurable signal I'd look for isn't lines of code or even cyclomatic complexity; it's change‑propagation distance. How many other files/modules need updating when you modify one? That's a proxy for interdependence, and it's something static analysis can actually track.
On LLM‑based evaluation in CI: I'd trust it for spotting obvious anti‑patterns (e.g., "this function is 500 lines") but not for judging architectural coherence. That still requires human context about the business's actual jobs‑to‑be‑done.
Have others found useful heuristics for measuring interdependence in real codebases?
Re:Tell HN: Technical debt isn't messy code, it's architectural compou...
on Wednesday March 04, 2026 @04:52AM (#47245275)
The compound interest framing is the right one. The part people miss is that compound interest works in both directions.
Good early architectural decisions compound positively. A clean boundary between services means the team that owns service A doesn't need to coordinate with the team that owns service B when either one ships. That coordination cost you avoided on day 30 is the same cost you avoid on day 300, but by day 300 you've avoided it hundreds of times.
Bad decisions compound negatively, and the mechanism is subtle. A leaky abstraction doesn't break anything immediately. It just means every developer who touches that boundary spends an extra 15 minutes (BS, it can be an hour or two) understanding why the types don't quite match, or why that one field is sometimes null. Multiply 15 minutes by 8 developers by 250 working days and you've lost 500 engineer-hours to a decision someone made in week two.
The "Mullet Schema" idea (strict columns for business-critical data, JSONB for everything else) is a practical version of this. You're deliberately choosing where to accept compound costs (the JSONB side) and where to prevent them (the strict columns). The key is being explicit about which side a given piece of data belongs on, and reviewing that classification as the product evolves. What starts as "nice to have" metadata has a way of becoming load-bearing business logic over 18 months.
To answer your question about where to draw the line: I look at how many teams or people need to coordinate when something changes. If a schema change requires three Slack conversations or a "short" call, that's a signal the architecture is creating coordination costs that will definitely compound, what you correctly called "microservice tax" and I call "complexity tax". That's usually where the line should have been drawn earlier.
StoryPack helps young professionals learn from experts through stories
Re:StoryPack helps young professionals learn from experts through stories
on Tuesday September 22, 2020 @06:32PM (#24560774)
StoryPack is a micro-learning platform that helps young professionals learn and organizations train their modern workforce through external and internal expert knowledge in the form of short stories. We carefully select short stories from business books and experts so you can get great ideas and lessons quickly and efficiently.