Software Architecture Guide • Hacker News Board

Re: Software Architecture Guide

#241

Post by anon9001 » Sun, Aug 25, 2019, 8:45 AM UTC

WalterBright wrote: post #181

proc0 wrote: post #156

Earlier quoted context omitted.

"Engineer" Origin: Middle English (denoting a designer and constructor of fortifications and weapons; formerly also as ingineer ): in early use from Old French engigneor. Also shares same root as Engine I assume. Engineers are experts in system building or some kind, the earliest being weapons, then transportation, etc. Software Engineer is 100% an engineering role IF you are making what could be called a kind of eng…

Much programming is more art or craft than engineering. For example, what separates a mechanic from an engineer? They are often working on the same project, and appear to be doing the same thing. In my view, a mechanic follows rules of thumb, eyeballs a design, etc. An engineer applies math and derives design, or checks the design using math. A mechanic will say "this beam looks thick enough to hold the load", and en…

That's a pretty bad example because any good programmer will have at least a rough idea how to profile code in their environment.

Can you name any software that's "engineered"? I can't. All software is built by craftsman of varying degrees. Nobody sits down and engineers anything up front.

The original point "agile" was that code is an iterative craft, so everybody should get together and work toward incremental improvements and respond to change, rather than try to engineer the whole project upfront. In other words, the way software is "supposed" to be built in most places these days is explicitly the opposite of engineering.

* Individuals and interactions over processes and tools

* Working software over comprehensive documentation

* Customer collaboration over contract negotiation

* Responding to change over following a plan

Doesn't sound like "engineering" to me, and that's the process with the most adoption (even though it's bastardized now, that's still the idea that's being sold).

Re: Software Architecture Guide

#242

Post by TeMPOraL » Sun, Aug 25, 2019, 9:04 AM UTC

aklemm wrote: post #87

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?!?!"

Exactly. In fact, this thread looks like people cargo-culting what it means to be evidence-based (hint: life and work will always contain some reasoning and craft).

At this point it seems that there's more comments that start by saying "OMG HN is so negative about Fowler" than there are comments actually doing this.

I have this working hypothesis that HN is a nexus where multiple alternative realities intersect, which is why I sometimes find threads with 5 comments complaining about HN negativity to one or zero comments that are actually negative...

Re: Software Architecture Guide

#243

Post by mjburgess » Sun, Aug 25, 2019, 9:18 AM UTC

reilly3000 wrote: post #238

mjburgess wrote: post #125

Earlier quoted context omitted.

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…

You have to separate social-subjective elements from individually-subjective elements from objective elements.

The objective elements are, simply put, "what is true of the object". And the subjective elements are "what is true of the subject.

Where "object" is the target of understanding, and "subject" is the "understander" -- ie., not the human (as holding organs) but the human (as holding experiences).

When I say, "the code has 100 lines" that is true in virtue of the object. It is meaningful in virtue of various conventions about what a "line" is and what "code" is.

Let's not confuse what is being said for how it is said. The latter is subject-relative, the former is object-relative (ie., objective).

Mathematics is about order. The target of mathematical description is objective (it is instanced by objects, not by experiences). However mathematics as a language is conventional (ie., social-subjective).

What is being said (eg., that there are infinitely many primes) can be said many ways. Each of those ways is only meaningful given a social background.

Likewise, "Architecture" is a term grouping together some -- but not all -- facts about software. (eg., inheritance dependencies, but not comment symbol choice). What is being said requires conventions in which to say it.

OP article seems to confuse these issues mightily and I think would impair someone looking to understand "architecture" without prior experience. It is not merely "what's important". Many things are important.

Re: Software Architecture Guide

#244

Post by sriku » Sun, Aug 25, 2019, 10:01 AM UTC

blub wrote: post #163

cliffcrosland wrote: post #143

Reading an enumeration of architecture options can be helpful, but I've probably found more value in works like Ousterhout's "A Philosophy of Software Design" that cover fundamental design principles. Such principles seem to be applicable no matter the project. I appreciate that Ousterhout tries to support these principles with some data from his own experience (building Tcl, RamCloud where Raft consensus was discove…

Yes, "A Philosophy of Software Design" is brilliant, precisely because the author supports their statements through the many experiments they performed with students and The fact that they're the author of a well-known piece of software helps, although we should not use this as the main criteria to evaluate a text. Offering at least evidence based on experimentation is essential if we want to move past personality cu…

I'm wondering whether another factor that might be at play is that as consultants they may not be at liberty to discuss that kind of detail. Barring that, it would be interesting to have Fowler sit in Ousterhout's class, take on an advanced problem and see what they come up with.

Re: Software Architecture Guide

#245

Post by krapht » Sun, Aug 25, 2019, 10:15 AM UTC

crimsonalucard wrote: post #210

perlgeek wrote: post #194

Earlier quoted context omitted.

What's the relation between category theory and changing requirements? You lost me there...

An example: Since category theory looks almost like a formal theory of "design" and "abstraction" is looks like if one day someone could come up with an algorithm or function to formally derive a solution given a set of requirements. To anticipate changing requirements you simply need to adjust the initial set of requirements to be more broader and then this hypothetical function would output a system that can handle…

Proving diagrams commute with abstract nonsense is not going to help the average programmer. At most it's a formalism that will help people who design programmer's tools reason about their system, much like relational algebra for databases or Hoare logic for imperative programming, or UML.

Re: Software Architecture Guide

#246

Post by tempguy9999 » Sun, Aug 25, 2019, 10:37 AM UTC

blub wrote: post #233

jonbronson wrote: post #162

Earlier quoted context omitted.

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…

> unit testing [...] or neglecting other kinds of testing that are more effective

Could you elaborate? (happens I come from a background where there is no kind of systematic testing, which is a bit of a downer)

And 'PoC' = proof of concept?

> which justify their design and coding decisions based on what wrote in a book or blog.

Happened to me. We had an SQL-based product that ran like a dog. Much faster by the time I'd finished it (I was the local guru), but on the next iteration I found the lead programmer had ripped out the big complex SQL statements it generated, and replaced each with many simpler queries. I asked WTF he'd done that without telling anybody and he justified it by pointing to a blog article recommending that for speed.

The article ended up 'trust me, it will be faster'. Oh yes, it ran faster because the query optimiser (very cpu expensive) now had very little work to do - so in ran like a rocket when the lead programmer (ie. one single user) tested it in his laptop. But it would scale like a dog because the optimiser had been sidestepped!

In addition, lots of little queries picking data from here and there would allow inconsistent views of the data because he didn't know about transaction isolation levels.

Thanks, idiot blog author!

Re: Software Architecture Guide

#247

Post by [deleted] » Sun, Aug 25, 2019, 11:58 AM UTC

tempguy9999 wrote: post #246

blub wrote: post #233

Earlier quoted context omitted.

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…

> unit testing [...] or neglecting other kinds of testing that are more effective Could you elaborate? (happens I come from a background where there is no kind of systematic testing, which is a bit of a downer) And 'PoC' = proof of concept? > which justify their design and coding decisions based on what wrote in a book or blog. Happened to me. We had an SQL-based product that ran like a dog. Much faster by the time I…

[deleted]

Re: Software Architecture Guide

#248

Post by goto11 » Sun, Aug 25, 2019, 11:59 AM UTC

camgunz wrote: post #204

charlieflowers wrote: post #195

Earlier quoted context omitted.

> Agree, but people tend to stop at Fowler and live it as gospel. I know people do that, and it sucks. But I never got that from Fowler himself. There are other authors (not naming names) who are pretty dogmatic often. But Fowler seems to genuinely try to capture patterns and techniques in an open-minded way. It's the abuse of his material that is the problem.

Yeah he's no Zed Shaw. But actually I think Fowler is... well he skips a lot of steps and makes a lot of assertions. Here's an excerpt from the intro to Refactoring : > The performance of software usually depends on just a few parts of the code, and changes anywhere else don't make an appreciable difference. > But "mostly" isn't "alwaysly." Sometimes a refactoring will have a significant performance implication. Even…

Are you applying the principle of charity when reading Fowler? The quote about performance seem totally sensible and basically akin to Knuths "We should forget about small efficiencies, say about 97% of the time...". Focus on maintainability and only sacrifice clarity for performance when you know there is a performance problem. What part of this do you honestly disagree with?

You can pick any writing apart by being deliberately obtuse. It doesn't help the conversation. E.g rhetorically asking the meaning of "clear" and "well-factored" code, when basically all of his writing are about exactly that.

I'm sure some people are taking him too much as gospel and don't look further - since this happen to any sufficiently popular writer. Just look at all the people on HN which read PG's essays as gospel and think all problems of architecture and maintainability can be solved by using Lisp - you can't really blame PG for that either.

Yes you will have to apply you own experience and critical thinking and understanding of the problem domain. This is true for everything you read or hear.

Re: Software Architecture Guide

#249

Post by hyperpallium » Sun, Aug 25, 2019, 12:18 PM UTC

eitland wrote: post #153

hyperpallium wrote: post #91

Earlier quoted context omitted.

Yes. And Computer Science is not a science, and Software Engineering is not an engineering. Guides to it are more like guides to writing. Strunk and White , where is your empirical data? What's your control? Where are your PDE's? Some also have aspects of business productivity books, with well-known common-sense ideas, like In Search of Excellence (which made up case studies, and a co-author said what's the problem?)…

> Even Fred Brooks' Mythical Man-Month - informed by his leadership of the massive bet-the-company "360" project at IBM - lacks data. It's still great though (in, uh... my subjective opinion, I guess). I have just read that book. It is the computer book with most tables pr page of any I have seen. How you come to this conclusion is beyond me.

The "data" in this context is empirical data in support of the hypothesis that the man-month is mythical (aka adding people to a late project makes it later). You also need a control.

Similar for other hypotheses, such as a "programming product" and "programming systems" take three times longer than a "program" (written by e.g. a garage duo).

BTW Your "beyond me" was unnecessary. https://news.ycombinator.com/newsguidelines.html

Re: Software Architecture Guide

#250

Post by Ozzie_osman » Sun, Aug 25, 2019, 12:45 PM UTC

streetcat1 wrote: post #192

Ozzie_osman wrote: post #133

Earlier quoted context omitted.

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…

There is not such thing is "partial" engineering. Engineering is the creation and ongoing management of any real world object (building, cars, bridge, computer) which has affect on its environment. I.e. they are placed in the real world to achieve some sort of a function. The role of the engineer is: 1) Find out what function a machine should provide 2) Create this function by building the artifact on time, and in co…

I didn't say anything about partial engineering. Just that engineering disciplines are different. If you need to design a column to hold up some load, a set of equations will tell you the dimensions of that column, how much cement, sand, etc to put in the concrete mix, how many steel rebars of what diameter and specification. Designing that column is very different than anything I do as a software engineer.