Software Architecture Guide • Hacker News Board

Re: Software Architecture Guide

#111

Post by jhayward » Sat, Aug 24, 2019, 5:09 PM UTC

geofft wrote: post #20

streetcat1 wrote: post #18

Earlier quoted context omitted.

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…

The question was about "research" in the meaning of quantitative scientific evidence that these proposed techniques make software delivery better in real-world conditions, not "research" in the sense of new ideas from academics. As a professional, I don't want UML because I've seen no evidence it actually helps. Show me relevant studies that it does and I will absolutely change my mind. (And there are plenty of thing…

I would be interested in a list of the tools you use daily and your list of research publications that prove that those specific tools improve productivity, reliability, or whatever metric you have named in selecting them.

Re: Software Architecture Guide

#112

Post by noobiemcfoob » Sat, Aug 24, 2019, 5:09 PM UTC

CraigJPerry wrote: post #86

noobiemcfoob wrote: post #80

Earlier quoted context omitted.

> it does mean that it's quite hard to fire an underperforming dev, because how the hell do you prove they're underperforming? What metric do you use? I think your criticism of 'at-will' employment is unfounded in this scenario. Having lower guardrails on employment means it's not as pressing to figure out performance metrics. If the company narrative is that an employee is helpful to the mission, then there isn't mu…

> I think your criticism of 'at-will' employment There was no criticism of at-will employment in the parent post. That's a hair trigger you've got yourself there fella.

> In my country, which (thankfully) lacks America's "at-will" employment contract

I'm sorry, is that not obviously criticism? My parser must be busted again.

Re: Software Architecture Guide

#113

Post by sooheon » Sat, Aug 24, 2019, 5:10 PM UTC

jmartinpetersen wrote: post #24

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…

Robert Martin seems to cherry pick stats and trends and whatever that fits his world view. In Clean Architecture he cites a study with N=1 as proof TDD works. I have no hope for him.

I'm genuinely curious what the stats backed world views you hold are.

Re: Software Architecture Guide

#114

Post by crimsonalucard » Sat, Aug 24, 2019, 5:10 PM UTC

perlgeek wrote: post #100

crimsonalucard wrote: post #93

Earlier quoted context omitted.

Software development doesn't need to be an art and it doesn't need to be a science either. By science I mean using data and statistical evidence to drive development, by Art I mean using your gut and your intuition to drive development. A computer is a deterministic system. It is 100% predictable and follows an exact set of rules. Software development is amenable to proof, logic and theory. You don't need to make dec…

> A computer is a deterministic system. It is 100% predictable and follows an exact set of rules. Software development is amenable to proof, logic and theory. You don't need to make decisions driven by data or your gut if the problem space can be described by a logical and axiomatic theory. That's true, only if you can assume perfect knowledge about the problems/requirements, the data, the environment, and how (if at…

Yes this is where the "Art" that I described also comes into play. We have no theory that can predict the output of a human brain therefore we can't theoretically derive what requirements a customer will want or change over a span of time.

However...

There is something sort of new from the academic side that could potentially be a theory that can deal with problem you describe.

At a high level the theory looks almost like a formal language for "design" and "abstraction." It's called category theory. It's new-ish so it doesn't yet solve the problem you describe but I see the outlines of it within the framework of the theory.

Re: Software Architecture Guide

#115

Post by noobiemcfoob » Sat, Aug 24, 2019, 5:12 PM UTC

EdwardDiego wrote: post #88

noobiemcfoob wrote: post #80

Earlier quoted context omitted.

> it does mean that it's quite hard to fire an underperforming dev, because how the hell do you prove they're underperforming? What metric do you use? I think your criticism of 'at-will' employment is unfounded in this scenario. Having lower guardrails on employment means it's not as pressing to figure out performance metrics. If the company narrative is that an employee is helpful to the mission, then there isn't mu…

I didn't express any direct or detailed criticism of at-will in my comment, just my gladness that we don't have it. Why, despite the difficulties it causes me when dealing with poor performing devs, am I happy we don't have at-will? Because at-will dramatically distorts the employer - employee social contract in favour of the employer. And employers already have a disparately large amount of power over their employee…

Gladness you don't have it is criticism you're trying to hide behind semantics.

You and I seem to have different ideas of an employment social contract (or non-existence of one). Unless you're interested to dig into that difference, I don't think we have anywhere else to go with this thread.

Re: Software Architecture Guide

#116

Post by netsensei » Sat, Aug 24, 2019, 5:13 PM UTC

ori_b wrote: post #96

netsensei wrote: post #84

Earlier quoted context omitted.

I think the answer to your question would be: it depends on external constraints. How much time do you have? What is the scope of the project? Size of your team? Number of stakeholders? Budget? Etc. In my mind, the crux of the entire exercise is trying to translate a complex murky real world problem domain into a mental model that can be expressed via a shared language describing properties, aspects, processes, conce…

> I think the answer to your question would be Yes, that's the problem. The pixels spent here are based on hypothesis, not experiments. You think one thing, I think something else, and not a joule of effort is spent measuring.

Ah yes, that would be Karl Popper's concept of Falsifiability of a hypothesis.

https://en.m.wikipedia.org/wiki/Falsifiability

That's what we are debating here: is this claim that use of UML is always markedly better when modelling any problem domain is true as observed through a sufficient number of data points?

I'm poking holes in that hypothesis because there's always n + 1 conceivable use case where the opposite is true. And I'm basing myself on set theory and computational algebra.

The crux is 'sufficient' because all use cases that could be moddeled with UML being equal, prove to me that there is a finite amount of use cases. Hard answer: you can't.

Moreover, there is no way you can prove to me that each and any use case is solvable with UML in an efficient way without actually solving said use case.

Check Hilbert's Grand Hotel paradox. Perfectly applicable to this question. https://en.m.wikipedia.org/wiki/Hilbert%27s_paradox_of_the_G...

Re: Software Architecture Guide

#117

Post by Ozzie_osman » Sat, Aug 24, 2019, 5:14 PM UTC

jeswin wrote: post #98

I looked at this thread a while back and closed the window, hoping that those early comments don't influence the younger practitioners who are on HN. As someone nearing 40 (mainly doing consulting work around boring business apps for a long time), my view is that Martin Folwer's biggest contribution is indeed the documentation, and defining the vocabulary to enable discussion around frequently encountered (but perhap…

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.

Re: Software Architecture Guide

#118

Post by ris » Sat, Aug 24, 2019, 5:17 PM UTC

jeffdavis wrote: post #92

Architecture is your chance to decide which problems will be easy and which problems will be hard. In a microservice architecture, failure handling is easy. State management is hard. In a centralized database architecture, failure handling is hard. State management is easy.

> In a microservice architecture, failure handling is easy

I'm not sure I would agree with this - it's still incredibly hard to be able to make the rest of your architecture do something useful when a significant part of it goes away. Multiply the possibility of one of your important services going down by the number of important services you have...

Re: Software Architecture Guide

#119

Post by [deleted] » Sat, Aug 24, 2019, 5:18 PM UTC

scarface74 wrote: post #16

Spearchucker wrote: post #11

Oh man. Another diatribe from Martin Fowler™. Takes me back to the 90's when I was in awe of teh architectures and architects, understanding of which was always just beyond my grasp. 99% of software I've encountered has some kind of interface, a domain it operates in, and data it operates on. Call these three things layers. It also has some cross-cutting things that are universally available in the software - broadly…

I learned a lot from Domain Driven Design and some from Design Patterns by the GOF.

[deleted]

Re: Software Architecture Guide

#120

Post by sooheon » Sat, Aug 24, 2019, 5:22 PM UTC

crimsonalucard wrote: post #85

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…

I agree with you. There's another angle to look at it though other then "evidence based" or scientific. In the field of engineering a large portion of it has to do testing to verify systems that are unpredictable or not modelled by theory. For example: building a plane involves testing it a wind tunnel. The thing with computer systems is that computers are deterministic math machines. You don't need to test a compute…

> He treats this stuff like it's 100% art

Is this true? I'm just picturing in my mind juxtaposing Fowler's writings and I dunno, an art critic's.

Category theory is cool and important, but to insinuate that all design problems can be "derived" by it sounds like a mathematician declaring that the work of all civil engineers as just "applied math".