Software Architecture Guide • Hacker News Board

Re: Software Architecture Guide

#231

Post by holy_city » Sun, Aug 25, 2019, 5:45 AM UTC

Ozzie_osman wrote: post #133

streetcat1 wrote: post #104

Earlier quoted context omitted.

Software engineering is engineering in the same sense the mechanical engineering is engineering. The only difference is that with software your materials are descriptions. I.e. you describe something, give to the computer and the computer turn itself into this something . In the end, there is a physical entity in the world (the hardware), which turned itself into a unique machine based on your description (for exampl…

I disagree. Engineering disciplines vary in how far removed they are from the underlying physics and how malleable they are. Building a bridge (or civil engineering) is very connected to the underlying physics. A set of equations give you the answers. It's also not malleable. You design it once, then build it, putting in some margins of safety to account for any variances in underlying material or potential usage, th…

I strongly disagree.

Engineering is the study and practice of problem analysis and design synthesis. Whether that means using abstractions of the physical world or how data is structured and processed is unimportant.

Any approach to the understanding of problems and how to solve them is engineering. Sometimes it's very structured, sometimes it deals with the physical world - and other times it's incredibly abstract and divorced from the real world. It's all engineering.

Re: Software Architecture Guide

#232

Post by ende » Sun, Aug 25, 2019, 7:03 AM UTC

hyperpallium wrote: post #132

streetcat1 wrote: post #104

Earlier quoted context omitted.

Software engineering is engineering in the same sense the mechanical engineering is engineering. The only difference is that with software your materials are descriptions. I.e. you describe something, give to the computer and the computer turn itself into this something . In the end, there is a physical entity in the world (the hardware), which turned itself into a unique machine based on your description (for exampl…

That is a valid argument if your concept of a mechanical engineer includes anyone who designs a machine; for example improvising levers, pulleys, gears to achieve some end. I guess it is all "engineering" in a casual, tinkering sense. But a professional engineer, with a Mech Eng degree who uses mathematical models of stress and strain etc, who did lots of tinkering as a kid, might not agree.

Again with the over emphasis on “state sanctioned recognition”.

Re: Software Architecture Guide

#233

Post by blub » Sun, Aug 25, 2019, 7:07 AM UTC

jonbronson wrote: post #162

Ozzie_osman wrote: post #66

Lots of hate in this thread.. People asking for proof: what sort of evidence would convince you? I take these blog posts, apply it to my experience, and take what I think makes sense. Sometimes, an idea will solve an obvious pain I've had. Sometimes, an idea will show me a pain I didn't know I have. Sometimes I disagree with the idea because it won't work for me. That's fine. I'm still much better off thanks to this…

Thank you for writing this. As an engineer reading these style of articles, I've witnessed two common reactions: Either the content resonates, and our eyes widen at the site of a simplified and intuitive explanation for phenomenon that we've somehow already observed, or... it doesn't. And maybe that's the source of much of the negativity we're seeing. These engineers haven't worked in domains, projects, or organizati…

That's not at all the source of my negativity. Instead, I am confronted in my work with developers of different experience levels which justify their design and coding decisions based on what e.g. Robert Martin or Martin Fowler wrote in a book or blog.

Some of these ideas, like "code should read like prose" or the obsession with unit testing are causing problems, such as making the code harder to follow or neglecting other kinds of testing that are more effective.

I'm not going to claim that everything these authors say is false, but it's high time we say: PoC or GTFO - show us the systems where these rules are applied and let us judge if they're worth anything, don't tell us nice stories.

Re: Software Architecture Guide

#234

Post by blub » Sun, Aug 25, 2019, 7:11 AM UTC

inopinatus wrote: post #219

blub wrote: post #179

Earlier quoted context omitted.

Software development does have a certain Darwinian character - whatever survives and thrives can't be wrong. Embracing this seems misguided, because as software becomes more complex, it's no longer enough to have software blacksmiths banging away with their software hammers and unit testing the end result into a releasable shape. Teams working on high-availability, high-reliability software know this and take a rigor…

> Teams working on high-availability, high-reliability software know this and take a rigorous approach Approaches that are, nevertheless, still more akin to philosophy than engineering.

Please detail your understanding of what philosophy is and how it resembles what such teams are doing. My gut feeling is that they're quite different, but I could be missing something...

Re: Software Architecture Guide

#235

Post by blub » Sun, Aug 25, 2019, 7:28 AM UTC

streetcat1 wrote: post #18

blub wrote: post #7

Whenever I see yet another article by Martin Fowler, Kent Beck, Robert Martin & co I ask myself - where is the evidence for what they are preaching? What are the graphs based on? What is the evidence behind the proposed rules? These authors are clearly accomplished blog and book writers, but anyone whose software-related accomplishments are not open source or at least well known should have their statements scrutiniz…

So first, you should read their books for concrete code. Martin books, for example "refactoring" or "Enterprise architecture" actually have good code examples. The same apply for kent beck early work on smalltalk (you can look at Junit) or his early work on the HotDraw editor (which was the source of many of the pattern in the Design Pattern book). Kent was one of the first adopter of smalltalk at the early 80 is tec…

I read parts of the refactoring book (1st edition) when it came out to see what kind of refactorings the author mentions. Since I didn't remember much from it, I decided this year to take a look at the 2nd edition, which to my amusement is written in JavaScript. After reading the example refactoring at the beginning I abandoned the book, because it champions the "code as prose" idea, which is rightfully contradicted by Ousterhout in his "A Philosophy of Software Design".

"Enterprise architecture" was not relevant for me, I wasn't doing any EA when I started reading it and quickly lost interest. The only potentially engaging topic was concurrency, but there are much better books available about that topic.

"Pattern-Oriented Software Architecture" (I am only familiar with vol 1 & 2) has wider applicability and is more compelling in my opinion. And they have references and examples. For instance the Pipes & Filters architecture patterns gives UNIX [Bac86], CMS Pipelines [HRV95] and LASSPTools [Set95] as examples and references "The Pipeline Design Pattern" [VBT95].

I do see case studies and references, but not from these authors I mentioned.

Re: Software Architecture Guide

#236

Post by JBSay » Sun, Aug 25, 2019, 7:53 AM UTC

I started reading his sample chapter on refactoring and I'm constantly put off by some really rookie mistakes and bad code practices like naming a function after nouns instead of action verbs (e.g. "amountFor" instead of "computeAmount").

Re: Software Architecture Guide

#237

Post by TeMPOraL » Sun, Aug 25, 2019, 8:03 AM UTC

ende wrote: post #232

hyperpallium wrote: post #132

Earlier quoted context omitted.

That is a valid argument if your concept of a mechanical engineer includes anyone who designs a machine; for example improvising levers, pulleys, gears to achieve some end. I guess it is all "engineering" in a casual, tinkering sense. But a professional engineer, with a Mech Eng degree who uses mathematical models of stress and strain etc, who did lots of tinkering as a kid, might not agree.

Again with the over emphasis on “state sanctioned recognition”.

So will you call anyone that tells people what chemicals to ingest when "a doctor"? Will you call anyone on the Internet commenting on legal issues "a lawyer"? Or would you prefer people emphasize the meaning of "state sanctioned recognition" in these cases?

Engineering is like law and medicine, in that it requires high skill and can hurt a lot of people if done badly. Not every country has engineering licensing, but I find myself increasingly agreeing with those that do. I feel calling software development engineering is mostly false advertising right now, only trying to capitalize on (and devalue) the status that engineering has in society.

Re: Software Architecture Guide

#238

Post by reilly3000 » Sun, Aug 25, 2019, 8:07 AM UTC

mjburgess wrote: post #125

mrkeen wrote: post #65

Martin Fowler: "Architecture is hard to define, but I'll try. Good architecture allows the system to evolve. Bad architecture attracts cruft and makes change hard." HN: "Fuck this ivory tower bullshit! Where's the evidence?!?!"

My objection is the "ivory-tower bullshit" is wrong. He goes to pains to fail to define architecture and rejects a reasonable definition for a confused genetic fallacy about social construction. "Architecture" isn't understanding . Understanding is of Architecture. If architecture were merely "the common understanding of what's important" there could be no disagreement or understanding of the software. Disagreement w…

Mathematics is totally a social construct. The UR patterns of our reality are immutable and await discovery. The ways in which humans explain their mathematical observations to each other is via a set of symbols that are socially agreed upon.

My problem with mathematical syntax is that it is so esoteric and arbitrary that many people struggle to use math to communicate with each other. Delving deeper into mathematics is an exercise in learning new symbols and their contexts. The understanding, acceptance, and advancement of mathematical concepts happens through social consensus.

For example, what does K mean? In an equation, strictly speaking it is a variable. But sometimes its a reserved constant. Others, its a unit. Is math 'universal' if the language of math is largely Eurocentric? In fact, several fundamental math ideas emerged from China far before they were expressed in Western culture. Their syntax differed from Western syntax to express largely, but not entirely, the same concepts.

Brett Victor[1] describes how the development of mathematical notation unleashed a clearer level of thinking, and a flowering of mathematical ideas, proofs, and science to follow. This requires agreement... consensus.

Take a look at Wikipedia's History of Mathematical notation and see what smells of culture you can find. [2]

Mathematics is the practice of translating observations about real-world things or abstract ideas from one person to another or many. A smart animal or intrepid alien sentience would not be guaranteed to understand what 3, 3%, or 3º means to us, but they could certainly understand 3 bananas vs 2, or a portion of a whole, or rotation.

Code is a social construct that is well-documented. Developers give trust to language authors and their compilers to generate correct bytecode. They in turn trust systems engineers to interpret their instructions correctly, and so on. Of course there are arguments and different perspectives on what the best way there is to express everything. These things get hashed out on this very social platform, and many others.

Architecture is about imposing one's will on the act of creating long-lived artifacts. It isn't system engineering. Its about arguing that things ought to be built out of arches, because they are durable, and look interesting, and especially because they have a rich symbolism associated with passage into new time and space. The will of an architect is usually something like enduring harmony with its inhabitants and surroundings. Software architecture I feel attempts to create durable systems for people to inhabit with their knowledge, and that is as social as it gets.

Sure, you may think of a software architecture as a formalized design on how to stitch together bits of data across network boundaries, maybe using packaged services from Cloud vendors. It is, but good architecture accounts for who is building it and who will own it, use it, and maintain it. It makes sure information isn't lost and people's simultaneous actions don't result in collisions. It attempts to resist loss, against a wide variety of classes of threats.

Look, I've been intrigued by event-sourcing, and also have heard of lots of gnarly consequences of trying to adopt it. Like any other pattern, its mileage may vary depending on the problem domain. An "ivory-tower bullshit" pattern may be widely a considered a "wrong" practice for the domains of today, but that doesn't mean you can prove that its fundamentally invalid in all cases.

If software architects made blueprints, I would think of the work of making said blueprint is "architecture". the work of software architecture is social, considering the needs of users, developers, and its financiers. What I read in your comment is referring to the blueprint as "architecture", or an architecture. Whatever the artifact of software architecture work is, the work itself is equal parts social and technical, and always in the context of the raw materials available at the time.

[1] Brett Victor, The Humane Representation of Thought https://vimeo.com/115154289 [2] https://en.wikipedia.org/wiki/History_of_mathematical_notati...

Re: Software Architecture Guide

#239

Post by PeterisP » Sun, Aug 25, 2019, 8:08 AM UTC

peheje wrote: post #97

moksly wrote: post #6

Earlier quoted context omitted.

In the public sector of Denmark we’ve been on a decade long journey toward better Enterprise Architecture. We have national guidelines for how we want public system/services to be build and how they should be able to transfer data through APIs. We don’t get completely technical, telling you what tools you need to use to build your software, only how your software needs to fit into the environment that is public secto…

It sounds more like someone actually sat down and thought about what to do before doing it. I read danish. I have experience with it. I did not understand what the page was trying to say. Providing your data through APIs are often a better way than rolling your own manual delta sync through reports every Sunday uploaded to your company FTP server with 5% downtime. Not duplicating your data throughout various systems…

Look from this from a perspective of a vendor. If a municipality orders development of a new system that does X, then from the perspective of a vendor, it's much cheaper to plan a 'fresh' system that has all the data to do X (and nothing else), structured in a way that makes it simple to do X.

If you want to actually understand all the other municipality systems that hold that data and integrate with them (instead of duplicating the data), then your proposal is not going to be the winning lowest-cost bid.

Re: Software Architecture Guide

#240

Post by TeMPOraL » Sun, Aug 25, 2019, 8:14 AM UTC

reallydude wrote: post #130

bradleyjg wrote: post #109

Earlier quoted context omitted.

Suppose we weren't software engineers, but instead bridge engineers or physicians. Would you then accept "someone took the time to sit down to think through, write and publish some ideas" that we could either take or leave depending on how persuasive a writer the author happens to be? I think it is entirely reasonable to ask "what reason to we have to think this is good advice"?

Perception, Comprehension, Analysis, Publication repeat. Somewhere in there, it's doesn't matter if it's "advice" or whatever you want to call it, as long as it's shareable elucidation you can apply your own reasoning...but if you don't bother to follow the pattern, it doesn't matter what you think. Asking someone else to have done these steps for you, is a proxy for a lack of interest, imo. Everyone wants to be lazi…

I think the point of both 'geofft and 'bradleyjg is that these writings are mostly opinion pieces, and it's justifiable to not trust them based solely on popularity and author's status - none of which involve anyone actually verifying the soundness of all this advice. It's also justifiable to ask for more concrete evidence, since an ethical responsibility of an author is to not waste people's time.

If you were building a bridge, you wouldn't accept that you have to use particular type of beams just because a certain well-known bridge architect Fartin Mowler recommends it, and tells stories of how good bridges are when they're using these beams. You probably wouldn't discard the advice either, but you'd ask for more detailed, first-principles explanation, you'd ask to see the plans and the studies of the bridges with these beams, etc.