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

101–110 of 303 posts

Re: Software Architecture Guide

#101

Post by crimsonalucard »

billfruit wrote: post #46
gunnihinn wrote: post #38

Earlier quoted context omitted.

That restricts you to mathematics, logic or philosophy. Engineering, or the rest of the world, operates _at best_ on statistics.

Programming in general and Software correctness does not depend upon statistical arguments, so perhaps such a view could be taken for software engineering too. Also even considering aesthetics and elegance, I find use of statistics to power a reasoning, ungainly, compared with other means of arguing the same thing.

You're right. Why are you voted down. Programming doesn't need to be based on statistics it's largely a deterministic system amenable to proof and logic.

This application of "engineering" onto programming is largely the result of people not truly understanding the system they are dealing with. The system isn't some sub-sonic jet that will be subject to unknown turbulence, it's just axioms and rules.

Re: Software Architecture Guide

#102

Post by perlgeek »

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 concur.

I'd like draw a parallel to philosophy: There is not one Grand Unified Philosophy Of Everything, but there are many different philosophers you can read, and take some of their views as their own, and still be aware of the rest.

I'm sure Fowler has been in contact with way more projects in enterprise software than me, so I appreciate his perspective. That won't stop me from reading folks from the more functionally inspired crowd, from the DDD corner of software design, etc.

Re: Software Architecture Guide

#103

Post by 2_listerine_pls »

hyperpallium wrote: post #91
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…

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?)…

Engineering is the application of science. A civil engineer uses laws regarding compression, stress, etc... to build its buildings. If you apply scientifically derived principles when building software then You are a software engineer.

Re: Software Architecture Guide

#104

Post by streetcat1 »

hyperpallium wrote: post #91
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…

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?)…

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 example an ATM).

While in mechanical engineering, you materials are physical, which might make it easier to explain.

Re: Software Architecture Guide

#105

Post by 2_listerine_pls »

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…

ok, then. I will ask for no proof and believe in anything He writes.

Re: Software Architecture Guide

#106

Post by perlgeek »

omk wrote: post #5
chewyshine wrote: post #4

Unusually useless post. An aggregator that says little. Too bad.

I would really like to read through a solid post that details Enterprise Software Architecture. As the author mentions, it certainly is hazy and I wonder if you can bring in 2 architects form different firms to talk the same language. Wonder if HN has a recommendation.

Not an article, but a book:

"Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solution" by Hohpe and Woolf

(You don't need to read all the patterns in detail; reading the overview will be enough to get you a pretty good idea. You only need to read the details when you seriously consider implementing a pattern).

Re: Software Architecture Guide

#107

Post by crimsonalucard »

notus wrote: post #41
randomcarbloke wrote: post #10

Earlier quoted context omitted.

Thank you. If I want to design excellent architecture I will crack open SICP and transpose it to the fabric of modern computing. I also take issue with much of what Fowler et al say, but that's another conversation.

SICP isn't going to teach you excellent architecture for large systems, it's going to teach you excellent architecture for small programs.

The design of small programs is isomorphic to the design of large programs at all levels.

You're just referring to real world caveats and details, but the overall concepts taught in SICP apply to all layers of programming from assembly to the architectural level.

Small programs:

   Q =  A -> B
   W =  B -> C
   R =  C -> D
   T =  D -> E
Large Programs

   L = W . Q
   K = T . R
Architecture

   M = L . K
The above description works at every layer.

SICP deals with abstraction and architecture at all layers of programming. It does not talk about real world idiosyncrasies of the system. For example it won't talk about whether the assembly instructions of the small program being executed is efficient and it won't talk about network latency.

Re: Software Architecture Guide

#108

Post by charles_f »

EdwardDiego wrote: post #59

> All I see is yet another reasonably sounding yet unsupported piece of folklore. Another artefact of the fact that software developers are still craftspeople - as in "someone skilled at making things by hand". Software development output is something that no-one has yet successfully quantified. There's no easy metric to assess a non-productive software developer from a productive one. We can all tell the difference,…

I don't think my concern with the issue at end is much more related to automation and wages than it is related to the "engineering" side of things.

Most of what the "literature" recommends is based on individual lessons learned and ideas, that are indeed backed less by data than they are by anecdote.

Having that is better than nothing. But if you compare software "engineering" when talking about software architecture, to construction, electrical or such, it's puzzling indeed to see how much more craft and less actual science is involved.

There are metrics that seem to apply though. Lines of codes and bugs aren't good indeed. Cyclomatic complexity is more related to algorithmic than architecture (which if going that direction is very much a science).

Measuring architecture effectiveness is measuring how much the architecture achieves its goals. These are contextual, most commonly in business they will be related to things like quality (as in, the software does what it is supposed to), total cost, time of execution. Some goals you can derive from that are adaptability to change, ability to modify and extend, which you might derive in turn into qualities such as decouple-ness, non redundancy of code, readability, etc. Some metrics for these exist, such as the instability (fan-in / fan-out ratio) or the abstractness measure of packages.

I don't know of architecture books that present patterns or practices with this sort of justification though. There's a chapter on that in Clean Architecture, but most of the rest is only strongly worded opinion.

Re: Software Architecture Guide

#109

Post by bradleyjg »

Scarbutt wrote: post #79
geofft wrote: post #74

Earlier quoted context omitted.

> If you can't even do THAT, then sorry, all your valuable experience is way less useful than someone like Martin Fowler, because I'm not learning anything from you. There is a small gap in this reasoning: that something is written down and sounds like a good idea doesn't make it a good idea. If you select on "people who have successfully written books about software architecture," you're in no way guaranteed to sele…

There is a small gap in this reasoning: that something is written down and sounds like a good idea doesn't make it a good idea. That's his point, doesn't matter if is a good or bad idea, but that someone took the time to sit down to think through, write and publish some ideas that will give developers a new perspective on how to do things that they would never thought about, whether those ideas are good/bad, apply or…

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

Re: Software Architecture Guide

#110

Post by vikingcaffiene »

sidlls wrote: post #89
vikingcaffiene wrote: post #73

Earlier quoted context omitted.

Thanks for this. The initial wave of hate on this post had me worrying that we are collectively forgetting the lessons of the past. This industry continually re-invents the same concepts over and over again and just re-brands them. Once you recognize that, the writings of Fowler & Co become highly applicable to many scenarios.

Is this because what they've written truly works or is it because they've simply managed the same thing as the loudest engineer in the office, at larger scale?

Well HN knows a thing or two about the latter ;)

It’s because I write better software in a team setting when I apply the techniques and philosophies of Fowler & Co. The biggest complexity in software is people. Coordinating them, navigating egos, and leveraging their experience levels. It’s a hard problem and the place where I see the most consistent system problems.

IMO Fowler is just providing accessible common sense strategies for dealing with that complexity.

Post reply on HN