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

71–80 of 303 posts

Re: Software Architecture Guide

#71

Post by vikingcaffiene »

I gotta say I am surprised and a little disheartened by all the negativity around this post and Fowler in general. Fowler's writing has been a huge inspiration to me in my career. I'm about to gift a copy of his book "Refactoring" to one of the junior engineers I work with for instance.

I think the idea of an architecture as a social construct is very fitting. Software is hard when multiple people are working on it with differing backgrounds and experience. Having a rough outline (emphasis on rough here) of "what lives where" and "what is allowed to talk to what" is absolutely critical IMO. It's how your team can effectively reason about a system and add new features to it. It should also be a living thing in that it's something that is continually refined, discussed, and changed as the needs of the business change. Done right, its an organic process that really helps deliver more robust software that everyone involved has a high level understanding of.

Contrast that with an Architecture (capital A) done in Enterprise which delivers a static artifact that does not allow for any creativity and micromanages every aspect of it. It's split off into chunks and no one without an expert level of knowledge can easily understand it. That kind of design will almost certainly fall over the first time there needs to be a change to it. It's important to point out the difference because that is NOT what Fowler is recommending in his writings.

Re: Software Architecture Guide

#72

Post by geofft »

streetcat1 wrote: post #57
traderjane wrote: post #43

Earlier quoted context omitted.

geoftt isn’t asking whether metaphorical TLA+ is academically fruitful. He’s asking if Amazons et al. have _continued_ to use it, and whether there’s some volume of evidence attesting to this.

Sure. So if amazon did not continue to use it. Does TLA+ suddenly become not useful? My point here is that those tools are theoretical CS tools based on the underlying nature of computers - which are a discrete digital state machine. Why do you even use high level languages, why not just program in assembler?

> Sure. So if amazon did not continue to use it. Does TLA+ suddenly become not useful?

Yes. (Or more precisely, it never was useful.)

Zero part of my business requirements involve anything about discrete digital state machines. If I could deliver business value more efficiently with pen and paper, I would. If I could deliver business value more efficiently with Excel or a shell one-liner, I would (and do). If I could deliver business value more efficiently by singing my harmony into the Music of the Ainur, I would. I write software because it's the tool we've found that is most efficient at delivering business value, not because the software itself has value.

So I use high-level languages because they are demonstrably more efficient. (And I frequently write sloppy code in Python or awk because it helps me answer business-relevant questions like "why is the site slow" quickly, without demanding I be rigorous about my software engineering in the process of answering the question.) don't use UML because I have yet to see evidence that it will help me deliver business value more effectively.

(I do also enjoy writing software as a practice, and I do that on weekends. That's the time to make code for code's sake.)

Re: Software Architecture Guide

#73

Post by vikingcaffiene »

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…

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.

Re: Software Architecture Guide

#74

Post by geofft »

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…

> 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 select for actual good ideas. It's quite possible none of the advice works.

That said, your broader point is taken, and I'll think about how to write things up about actual design lessons I've learned in practice, so still thank you for calling this out.

Re: Software Architecture Guide

#75

Post by Scarbutt »

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 remember struggling with my first non-trivial CRUD web app using no web framework, just libs, it had to have a CLI frontend too, his PresentationDomainDataLayering[1] really helped me in refactoring the spaghetti code I had. Probably obvious to many experienced devs but it was enlightening to me.

[1] https://martinfowler.com/blik/PresentationDomainDataLayering...

Re: Software Architecture Guide

#76

Post by legulere »

scarface74 wrote: post #56
legulere wrote: post #52

Earlier quoted context omitted.

System Software isn’t all that different from enterprise software. The business part is simply of technical nature. The biggest difference usually is that the software developers don’t have a deep understanding of the business rules.

I’ve had to maintain a bespoke compiler/IDE/VM for Windows Mobile/CE before and have spent two decades writing business software and architecting around the entire stack from networks, to databases, to web servers, load balancers, monitoring tools etc. I’ve also written SOWs, Done project plans, led teams (hated every minute of it). I’ve seen both sides. The types of optimizations and thought processes around enterpr…

Of course you’re not looking at generated assembly anymore because that is the business value of a compiler. The biggest difference now is that you’re probably not as big an expert in the enterprise topic as you were about generating assembly.

Re: Software Architecture Guide

#77

Post by afpx »

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…

The evidence is out there. If you look at successful libraries and applications, they almost always gave well-defined design and architecture guidelines. In fact, I can’t think of a good software library out there that doesn’t have a solid design and architecture. On the other hand, I often see big piles of mud that have to be re-written over (and over), because people believe architecture takes too long or they believe it’s unnecessarily complex.

Re: Software Architecture Guide

#78

Post by scarface74 »

legulere wrote: post #76
scarface74 wrote: post #56

Earlier quoted context omitted.

I’ve had to maintain a bespoke compiler/IDE/VM for Windows Mobile/CE before and have spent two decades writing business software and architecting around the entire stack from networks, to databases, to web servers, load balancers, monitoring tools etc. I’ve also written SOWs, Done project plans, led teams (hated every minute of it). I’ve seen both sides. The types of optimizations and thought processes around enterpr…

Of course you’re not looking at generated assembly anymore because that is the business value of a compiler. The biggest difference now is that you’re probably not as big an expert in the enterprise topic as you were about generating assembly.

These days - no. I’m nowhere near the business expert in the healthcare industry where I now work as I was in the ins and outs of assembly. That’s not my role. I’m a software developer by title, but I would consider myself an “expert” in both the software architecture and the AWS infrastructure of our (smallish) company.

When I was working for the company where I did have to maintain the compiler/IDE/VM after they forced their founder out. I also had to know the complete business needs of the client that kept us afloat because as they laid off people, I had to interact with the customer and write the SOWs. I saw both sides. The skillset I needed to implement the business side was completely different than the skillset I had to have to maintain the compiler stack.

Luckily I was mature enough (and an MBA dropout) to understand the business end and enough of a geek to understand low level computer concepts and could read assembly.

Re: Software Architecture Guide

#79

Post by Scarbutt »

geofft wrote: post #74
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…

> 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 not to the software we are currently creating is up to us to analyze and decided.

Re: Software Architecture Guide

#80

Post by noobiemcfoob »

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

> 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 much cause to fret for a more perfect metric. And at-will means you can test more employees before committing to a few for longer than a couple years.

Post reply on HN