Hacker News Reader

Comment by leetrout | Hacker News Reader

Off topic but...

> I work at a startup where business evolves really fast, and requirements change frequently, so it's easy to end up with big piles of code stacked together without a clear structure, specially with tight deadlines

That smells.

It sounds like the team could benefit from better stack technologies and a bit more discipline in how it is applied to solutioning.

> Enforcing some dependency rules that allow/forbid dependencies between different parts of the application.

What is the alternative to this tool that lowers the cognitive barrier / builds the right muscles for the team to understand what they should / shouldnt depend on?

View on HN

> It sounds like the team could benefit from better stack technologies and a bit more discipline in how it is applied to solutioning.

For our specific case it's actually pretty good, we've built a lot of discipline around maintainability, but in general this is a recurring problem in tech teams who might not be able to afford the time it takes to gain discipline.

> What is the alternative to this tool that lowers the cognitive barrier / builds the right muscles for the team to understand what they should / shouldnt depend on?

Some programming languages allow you to split the codebase into modular units (npm workspaces, cargo workspaces, etc..) which forces developers to modularize things, and dependencies between modules need to be explicitly declared.

This is good, but usually not enough, as nothing prevents you to mess things up within a module/workspace.

There's some other tooling with similar functionality to dep-tree, but language-specific and with visualizations not suitable for large codebases (.dot files, 2d svgs...)

Indeed, and tools like dep-tree provide a combination of 1) making module structure visible 2) making rules about this structure concrete and 3) automatically checking for rule violations.

These all help to lower the cognitive barrier to learning and maintaining the code base effectively. For developers new to the code base they help with learning and for those more experienced they help with ongoing design and maintenance.

Most long-lived code bases I've seen have adopted or built such tooling at some point, often with tools customized to the code base. For example in one large code base (c. 250 devs) we built tooling that simulated and helped optimize the changes to implement a major refactor of the overall module structure.

Stack technologies tend to bound contexts based on technologies and not on domain boundaries.

This is why we see all these products targeted at companies with 24 microservices with 26 developers who have to run end to end testing on everything.

Architectural erosion is primarily a cultural issue and any tool that helps people discover and call out architectural violations is potentially useful.

Many companies can't just do the inverse Conway law, and if you look at the state of devops report, note how they call out CAB forums and controls being problematic for even high performing companies to become elite.

This product as an example, which just really means you want to keep k8s but have given up on loose coupling and high cohesion.

https://www.signadot.com/blog/how-uber-and-doordash-enable-d...

Throwing products at structure problems typically doesn't work.

It's extremely common to get things twisted up. Even if there is a good tech lead, that person may not be good at writing documentation, may be too busy writing code, and may not yet have a plan for how to keep things organized.

Maintaining a code base requires communication, PR reviews and discipline. That doesn't always happen.

Having lint check rules is brilliant. Never mind discipline, you just need a friendly error to say don't import services into an ORM model file. I'm going to adopt this right away.

And even with discipline, sometimes introducing tech debt in order to ship something fast is actually something desirable at the short term, specially in the startup world, so I don't think that anybody with deadlines is completely free from twisting things up.

There’s such a weird vane of do nothingness that runs through this comments attitude. Yeah of course it’s easy to pick dependancies when you don’t worry about deadlines. A programmer without a deadline is like a fisherman going to grocery store to buy fish and claiming it’s “best practices” better results, but what was the point?

Reply on news.ycombinator.com