Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The C4 model for visualising software architecture (2017)

c4model.com

Post reply on HN
Print view View original

101–107 of 107 posts

Re: The C4 model for visualising software architecture (2017)

#101

Post by manicennui »

eitland wrote: post #98
manicennui wrote: post #60

Earlier quoted context omitted.

Code quality does not seem to have any correlation with business success. Why should business care?

If you think about code quality in terms like line length, spelling errors, etc it might not matter. If you think of it in terms of: - how long does it take to get at new developer up to speed? (everything from readability to build systems) - can this be hacked any day of the week if someone puts their mind to it? (both own code and libraries) - can we be resonably sure that new changes don't introduce (large) defect…

Everyone makes these claims, but I've worked at multiple successful companies with atrocious onboarding and code quality. A few people always make the claim that the software will become impossible to update or the system will collapse, and it never happens, even after a decade or more.

Re: The C4 model for visualising software architecture (2017)

#102

Post by manicennui »

jackblemming wrote: post #70
manicennui wrote: post #60

Earlier quoted context omitted.

Code quality does not seem to have any correlation with business success. Why should business care?

Well this is just wrong, so I don't really know how to respond. You're probably thinking about monopolies such as Facebook, Google, or the like, where not only does code quality not matter, but not much matters at all. Most businesses do not have this luxury.

Nope. I'm thinking about every single company I've ever worked at. My previous job was in healthcare and most of the software in the entire industry is atrocious.

Re: The C4 model for visualising software architecture (2017)

#104

Post by jackblemming »

manicennui wrote: post #102
jackblemming wrote: post #70

Earlier quoted context omitted.

Well this is just wrong, so I don't really know how to respond. You're probably thinking about monopolies such as Facebook, Google, or the like, where not only does code quality not matter, but not much matters at all. Most businesses do not have this luxury.

Nope. I'm thinking about every single company I've ever worked at. My previous job was in healthcare and most of the software in the entire industry is atrocious.

I guess if my rep sheet was McDonalds, Subway, and Tacobell I wouldnt think food quality mattered either.

Re: The C4 model for visualising software architecture (2017)

#105

Post by skinkestek »

manicennui wrote: post #101
eitland wrote: post #98

Earlier quoted context omitted.

If you think about code quality in terms like line length, spelling errors, etc it might not matter. If you think of it in terms of: - how long does it take to get at new developer up to speed? (everything from readability to build systems) - can this be hacked any day of the week if someone puts their mind to it? (both own code and libraries) - can we be resonably sure that new changes don't introduce (large) defect…

Everyone makes these claims, but I've worked at multiple successful companies with atrocious onboarding and code quality. A few people always make the claim that the software will become impossible to update or the system will collapse, and it never happens, even after a decade or more.

At one place I worked we were we were in a monopoly position and multiple companies were forced to buy from us.

Still we were barely were scraping by.

We were forced to spend a lot of time to do tricks to make Windows 7 behave like Windows.

We couldn't take opportunities that showed up as the only ones who knew the software were SW engineers in another country, and they were unreliable.

We could have lived comfortably since our software was almost mandatory and we were the only supplier.

But we struggled badly and pay were late on multiple occasions and I was happy to leave after some years.

Re: The C4 model for visualising software architecture (2017)

#106

Post by williamdclt »

simon_brown wrote: post #97
williamdclt wrote: post #46

Earlier quoted context omitted.

I’ve only tried structirizr briefly, but I found it too inflexible. No way to draw concepts that aren’t strictly part of C4. For example I wanted to encapsulate 2 components in a box to represent that they’re currently deployed as one service (not necessarily a good thing to do in absolute but would have helped my team to grok it better): impossible. I do like the idea of describing architecture formally, but the lac…

I don't have the full context of what you're trying to model, but "two components deployed as one service" might be better represented as a container. If that's not the case, you can use the "group" concept to group components together -> https://docs.structurizr.com/dsl/cookbook/groups/ Alternatively, https://likec4.dev provides a way to create an arbitrary number of abstraction levels (although I wouldn't recommend…

Can’t remember the details, but yeah it might be that I was trying to make a container appear in a component diagram or something like that

Re: The C4 model for visualising software architecture (2017)

#107

Post by captaincaveman »

IshKebab wrote: post #2

Interesting but I don't think this especially adds anything. The high level diagrams are great but then you can already make those without having to read any fancy visual model websites. The site even kind of admits this: > As an industry, we do have the Unified Modeling Language (UML), ArchiMate and SysML, but asking whether these provide an effective way to communicate software architecture is often irrelevant beca…

In practice this doesn't work very well in an enterprise, the boxes end up a mix bag of different levels of things, some abstract some concrete, some just random.

So if you need to piece together larger chunks of architecture, a supply chain for example, you basically have to redo it all. There is a lot of waste in this, and no one has a sufficiently clear view of the overall architecture, which leads to other waste and quality issues.

For some reasons most engineers get very defensive about a more formal approach, I suspect mostly because it doesn't immediately benefit them or they haven't had too deal with large scale architecture and don't see the problem.

Post reply on HN