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

Software Architecture Guide

martinfowler.com

Post reply on HN
Print view View original

251–260 of 303 posts

Re: Software Architecture Guide

#251

Post by goto11 »

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…

I think there is some tribalism at play. Fowler and friends are writing about enterprise architecture. HN is probably more oriented towards startups which haven't yet reached that kind of challenges and constraints (and in most cases never will), and who feel superior to the dinosaurs. And then there is is the "computer scientists" who think software development should be based on proofs rather than experience and results.

Re: Software Architecture Guide

#252

Post by lidHanteyk »

crimsonalucard wrote: post #206
lidHanteyk wrote: post #201

Earlier quoted context omitted.

Category theory is nearly a century old; what are you talking about? People write code today to solve these problems, and it's category-theoretic code: https://www.categoricaldata.net/fql.html

Yes yes, you are right. I mean new-ish in it's application to things outside of math. And also very new to programming. In terms of just pure math though, category theory is very new when compared to most of the disciplines around today. Also you are completely wrong about it being a century old. It was invented in the 1940s. I'm assuming you just googled it to find counter points. That being said you missed somethin…

Haskell is not really category-theoretic. The category Hask doesn't quite line up with real-world Haskell. The disconnection is well-understood and well-documented [0][1].

Category theory can directly give us systems from theories. See the papers behind FQL/CQL for more details, especially [2] and [3].

[0] https://wiki.haskell.org/Hask

[1] http://www.cse.chalmers.se/~nad/publications/danielsson-et-a...

[2] https://arxiv.org/abs/1102.1889v2

[3] https://arxiv.org/abs/1706.00526

Re: Software Architecture Guide

#253

Post by hyperpallium »

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…

I agree with your argument, but can you predict performance of an algorithm from big O complexity? (I assume you mean)

Perhaps a few runs of data points could enable curve fitting as it converges.

I feel like the "physics" of software is immature, closer to math than to practice, than for engineering - or something like that.

So I'm also agreeing with the gist of the other replier, that software isn't yet mature enough for precise estimates. We still flounder on what's needed, and stumble around what kind of a thing to build.

Precise specification is the exception.

Re: Software Architecture Guide

#254

Post by naasking »

anon9001 wrote: post #241
WalterBright wrote: post #181

Earlier quoted context omitted.

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 impr…

> Can you name any software that's "engineered"?

Most compilers. GPS and mapping systems. Basically, software whose core operation founded on well understood data structures and algorithms.

No doubt there is heuristic fiddling around the user interface and that's not engineering, but the core of plenty of software ought to be well engineered.

Re: Software Architecture Guide

#255

Post by Ozzie_osman »

camgunz wrote: post #184
Ozzie_osman wrote: post #117

Earlier quoted context omitted.

Your point on vocab is so spot on. Simply identifying something as a pattern and naming it is tremendously valuable. Doing it in a way that's packageable and shareable with others is not easy at all.

Agree, but people tend to stop at Fowler and live it as gospel. There is a profound richness in the different ways to think and talk about computers, engineering, and information science, far more wonderous than any one person can catalog. Read SICP, Knuth, Code Complete, Codd. Hell, just YouTube around. If your vocabulary is prescribed by literally one guy in a fedora, you gotta get out there. Might I suggest Joe Ar…

Agreed. But that's a fault of content consumers not producers, no? I have read SCIP (in college), Code Complete (first book I got in my first job), Gang of Four (2nd book), Clean Code, etc.

Unfortunately we are in an age where blog posts and videos are a lot more accessible than dense books. That sucks, and means we all have to expend extra energy to find a mix of good and diverse ideas and thoughts.

Re: Software Architecture Guide

#256

Post by Spearchucker »

lonelappde wrote: post #221
Spearchucker wrote: post #198

Earlier quoted context omitted.

First, anemic models work well in service contexts. You can't send a business rule from a web page to a web service as part of a data entity. And so such models have a valid place in the world. Micro services are still services. As such we always validate data crossing a trust boundary - whether monolith or micro service. The rules to do that validation cannot travel with the data. So guilt because anemic strikes me…

You wouldn't send a business rule from a web page, you'd put it in the domain model on the server. The web page has a UI model, not a domain model.

That's the point. And yet Fowler objects because it violates encapsulation and information hiding, because it requires a service layer and makes a model less expressive.

Re: Software Architecture Guide

#257

Post by ChicagoDave »

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…

The articles on Fowler’s blog are written by well-established senior developers/architects with years if not decades of experience.

There’s no evidence that Fowler, et al, are saying there is One True Way and he even eludes to the fact that any such proposal makes him uncomfortable.

I also have decades of experience and would add my observations:

Leadership matters. If you’re a part of team without authority or with weak a vision, you suffer at the whims of your leadership. I find this to be the first point of failure. Without a strong vision, enterprise software will develop code debt instantly and it will grow exponentially. Enabling a development team should be a priority.

Vision and Strategy A significant effort should be made to reason through objectives and put guardrails on those objectives. Are you re-platforming? Are you only rebuilding one boundary? Are you migrating to the public cloud and leveraging IaaS and PaaS? How brittle are your existing systems? Can your existing systems support the expected growth of the business?

Someone needs to consider these things before engaging with system change, develop a plan, socialize the plan with everyone, then develop execution strategies to enable the plan to succeed. This has less to do with code, but drives coding standards.

If you have complex systems, understanding Domain-Driven Design is a critical aspect to improvement.

If you have a “big ball of mud”, pulling it apart and rebuilding those parts according to the business is critical and can’t be done by “winging it”.

Opinionated vs Unopinionated Deciding how high your development guard rails need to be and managing them is an art, but it still needs to be explicitly managed. In an enterprise, opinionated is probably better. In a startup, the opposite may be true. Someone or some team needs to think about this and talk about it.

Communication Everyone, from Product Owners to Testers to QA needs to be able to model, whiteboard, and discuss problems, scenarios, and agree on solutions. Throwing work over walls will destroy the expected results.

Re: Software Architecture Guide

#258

Post by sidlls »

goto11 wrote: post #251
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…

I think there is some tribalism at play. Fowler and friends are writing about enterprise architecture. HN is probably more oriented towards startups which haven't yet reached that kind of challenges and constraints (and in most cases never will), and who feel superior to the dinosaurs. And then there is is the "computer scientists" who think software development should be based on proofs rather than experience and re…

And then there are people like me. I've worked in big enterprise software departments (a huge homeowners insurance tech company, big banking, government contractors), "companies" of three people including myself, and some in between. Currently I'm at a 500-ish person company that is not quite enterprise but not really a start-up.

My experience is that "Enterprise Architecture" creates as many problems for the business as it solves for technology practitioners attempting to solve problems in a huge battle royale of competing departments. I think it often helps cement and provide feedback loops for the causes of the problems seen in large enterprise systems.

Re: Software Architecture Guide

#259

Post by crimsonalucard »

krapht wrote: post #245
crimsonalucard wrote: post #210

Earlier quoted context omitted.

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.

Relational algebra is more or less isomorphic to SQL if you're doing SQL you're doing relational algebra.

Hoar logic can prove your programs 100% correct. This is useful for anyone who wants to write a program that's bug free.

UML is more of a visualization tool then a theoretical tool.

>Proving diagrams commute with abstract nonsense is not going to help the average programmer.

What in the world is a proving diagram, and what is abstract nonsense? Please be more clear with your explanations. I am not talking about diagrams and trying to say they commute with anything.

Re: Software Architecture Guide

#260

Post by crimsonalucard »

lidHanteyk wrote: post #252
crimsonalucard wrote: post #206

Earlier quoted context omitted.

Yes yes, you are right. I mean new-ish in it's application to things outside of math. And also very new to programming. In terms of just pure math though, category theory is very new when compared to most of the disciplines around today. Also you are completely wrong about it being a century old. It was invented in the 1940s. I'm assuming you just googled it to find counter points. That being said you missed somethin…

Haskell is not really category-theoretic. The category Hask doesn't quite line up with real-world Haskell. The disconnection is well-understood and well-documented [0][1]. Category theory can directly give us systems from theories. See the papers behind FQL/CQL for more details, especially [2] and [3]. [0] https://wiki.haskell.org/Hask [1] http://www.cse.chalmers.se/~nad/publications/danielsson-et-a... [2] https://ar…

Well you're not technically wrong about the Haskell thing. I'll look into FQL and CQL. If such a thing exists, what in your opinion is stopping an architect from using it?

Is it just that it's not popular or are there flaws?

Post reply on HN