10 ms·

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 wh

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 literature, and I would be worse off if it all had to be evidence-based. If you think you can write better based on your experience, please go for it. I'd love to have more literature to read, analyze, and learn from. If you can't (pressed for time, etc), and only have time to post in HN comment threads, then at least discuss concretely which parts you disagree with so we can learn from that too (I'm serious, not being facetious). 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. Having a good understanding of how to architect code is hard. Being able to write about that in a way that's useful for others is even harder, and is a skill of its own. So personally, I thank Martin & Co for all their writing.

deleted 7y ago
[deleted]
vikingcaffiene 7y ago
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.
- sidlls 7y ago
  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?
  - vikingcaffiene 7y ago
    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.
    - atoav 7y ago
      Interestingly enough this social factor is also the hardest to deal with in other scenarios (expeditions, film crews, multi-party-projects, ...)
geofft 7y ago
> 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.
- Scarbutt 7y ago
  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.
  - bradleyjg 7y ago
    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"?
    - reallydude 7y ago
      Perception, Comprehension, Analysis, Publication repeat. Somewhere in there, it's doesn't matter if it's "advice" or whatever you want to call it, as long as it's shareable elucidation you can apply your own reasoning...but if you don't bother to follow the pattern, it doesn't matter what you think. Asking someone else to have done these steps for you, is a proxy for a lack of interest, imo. Everyone wants to be lazily told things they either already know or can agree with easily, but being critical in a constructive way is work.
Scarbutt 7y ago
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.html https://martinfowler.com/blik/PresentationDomainDataLayering...
mobjack 7y ago
Software development is as much of an art as a science. Personally I've seen people double down on bad design decisions early in a project that becomes major pain to deal with later on. It is easy to see that if they spent a little extra time on quality in the beginning it would pay off in a few weeks or even sooner. I also see others spend too much time trying to be perfect in the beginning and nothing ever gets delivered or the over engineered solution creates its own form of tech debt. Every situation is different so you need to use judgement whether to apply someone's advice.
- deleted 7y ago
  [deleted]
- crimsonalucard 7y ago
  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 decisions driven by data or your gut if the problem space can be described by a logical and axiomatic theory. The problem is that the current "theory" is incomplete and not all parts of systems are amenable to statistical measurement. Thus a proper system architect needs to unify Theory, Science and Art to form a cohesive framework of system architecture. Theory is priority because it says definitive things about the system, Science is secondary and operates as a data driven backup for places theory is currently incomplete, and Art is basically the catch all admission that there is no data or theory to back up the problem space and you're just going to have to rely on your intuition. The problem with Martin Fowler is that all his stuff is 100% Art. It's just made up stuff from intuition and buzz words. Art is largely ad-hoc and does involve a lot of guess work that is often wrong. People identify with Martin Fowlers stuff because they identify with it on the "gut" level. It "feels" right. Your feelings are not a good way to do engineering, you rely only on intuition when you have no choice. Fowler is also a big Object Oriented Architect. The thing with Object Orientation is that it has no basis in theory or science and is almost 100% art. The pattern is starting to fall out of favor because people are realizing that they tend to build over-complicated systems when following the pattern because they are largely just relying on their gut intuition to build these things using primitives that are validated by the same flawed intuition.
hyperpallium 7y ago
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).
- 2_listerine_pls 7y ago
  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.
  - criddell 7y ago
    That depends on what jurisdiction you are in. The title of engineer is protected in lots of places and the description of software engineer is very specific and effectively regulated. That is, a software engineer is licensed.
  - Ozzie_osman 7y ago
    I'd love to see what those scientifically derived principles are. If I'm building a bridge, there are equations based on physics I can use. Like I mentioned in a separate thread, software is far more removed from those physics.
    - eitland 7y ago
      While not exact physics we have plenty of real world constraints that we skillfully (or not) work our way around or use for our advantage, here are two : - Amdalhls law - Moores law
    - hyperpallium 7y ago
deleted 7y ago
[deleted]
perlgeek 7y ago
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.
2_listerine_pls 7y ago
ok, then. I will ask for no proof and believe in anything He writes.
- dang 7y ago
  Please don't post unsubstantive comments here.
blub 7y ago
If you want to see how a properly referenced text looks like, pick any of the following: * Code Complete - McConnell * The Economics of Software Quality - Capers Jones * Facts and Fallacies of Software Engineering - Robert Glass * Making Software - Oram & Wilson ... and there are many others. Not all references have survived the test of time, L. Bossavit describes in his book " Leprechauns of Software Engineering" how several software development "facts" are in fact myths. The approach you suggest suffers from a chicken & egg problem because you first have to be experienced enough to be able to evaluate such reference-free content, as the blog written by Martin Fowler. It's precisely the inexperienced that are likely to internalize such advice and perpetuate personality cults. Your objections are invalid; one does not need to be better at a task than an individual in order to criticize them. Asking for references and proof is perfectly legitimate, at least if we want to approach our discipline more as engineering and less as "Strunk & White" as someone comically suggested in another comment.,
- Barrin92 7y ago
  >Your objections are invalid; one does not need to be better at a task than an individual in order to criticize them. Asking for references and proof is perfectly legitimate, at least if we want to approach our discipline more as engineering and less as "Strunk & White" as someone comically suggested in another comment Software development, as often as comparisons are made to engineering or science is neither. It's a craft. The tools differ from person to person, each piece of software is different, a lot of practises are learned and tacit and transmitted from one pracitioner to the next. Writing code is more like being a blacksmith than being a scientist, as much as people yearn for formalistic answers and peer reviewed studies so that they can have the appearance of objectivity, a lot of software development is fundamentally subjective.
  - blub 7y ago
    Software development does have a certain Darwinian character - whatever survives and thrives can't be wrong. Embracing this seems misguided, because as software becomes more complex, it's no longer enough to have software blacksmiths banging away with their software hammers and unit testing the end result into a releasable shape. Teams working on high-availability, high-reliability software know this and take a rigorous approach. Too many take the BDD approach (blog-driven development) and when the thing inevitably falls apart, the customers pick up the broken pieces.
jonbronson 7y ago
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 organizations where they could encounter how these lessons play out, and so they're dubious about the whole thing. One reaction to being in that position is to downplay the author and complain about lack of 'evidence'. The other, is to put down our egos, and consider that maybe we're just not there yet to appreciate what the author is trying to tell us.
- blub 7y ago
  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 other kinds of testing that are more effective. I'm not going to claim that everything these authors say is false, but it's high time we say: PoC or GTFO - show us the systems where these rules are applied and let us judge if they're worth anything, don't tell us nice stories.
  - tempguy9999 7y ago
    > 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 <authority> 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!
acje 7y ago
I think the article is really on to something, but fails to make it clear. Her is my current belief system; A) Architecture is strategy. Ted Neward was my first inspiration for this. It makes sense particularly when considering systems with long live cycles. Less obvious for smaller designs that don’t se much change over time. B) Strategy is most clearly defined by Good Strategy Bad Strategy: The Difference and Why It Matters Book by Richard P. Rumelt Describes the kernel of strategy as 1) diagnose 2) guiding policy 3) coherent action C) diagnosing is difficult, but both wardley maps and cynefin can help direct us to methods of diagnosing. Unfortunately the immaturity of computer science puts a lot our subsystems in the complex adaptive domain. Partly because we haven’t discovered the best patterns and partly because our tools them selves are a mess of abstractions.
mcnichol 7y ago
There are many arguments that sound logical on their face but completely miss the mark. Laffer curve is one that comes to mind immediately. The saying goes: "It can be explained to congress in 6 minutes and used for 6 months." It can be argued (with data) that it failed. Martin Fowler is no doubt a smart and greatly respected person in this industry. Saying something qualitatively doesn't mean there isn't quantifiable data behind it...but with his vantage point I believe we should press for a higher source of truth. I assume he can understand how important that higher source of truth is in having these conversations regarding what moves the architectural needle. Else we stay in this echo chamber.
- deleted 7y ago
  [deleted]
goto11 7y ago
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.
- sidlls 7y ago
  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.
  - goto11 7y ago
    This is where I get confused. Are you criticizing a particular architecture, or architecture in general? Is it even possible to have a system without an architecture?
    - james_s_tayler 7y ago
      The Winchester Mystery House does exist in software somewhere.
      - JeffGrigg 7y ago
        Even the Winchester Mystery House has architecture. Pretty good architecture. It's still standing, in spite of earthquakes. She bought it in 1884. Now it has some fairly odd "features" based on her very eccentric "requirements." Doors that open into walls. Stairs that "go nowhere." Very expensive windows that look out at brick walls. But given her odd sense of "requirements," it's the house she wanted!
alanfranz 7y ago
> 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. I love opinions. But if you provide a plot like the one for software quality, you should provide backing data. OR you should clearly state that such plot is totally made up. Nothing else. I have a blog where I write about my opinions. But they're CLEARLY opinions, UNLESS I have some backing data.

deleted 7y ago

[deleted]

vikingcaffiene 7y ago

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.

sidlls 7y ago
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?
- vikingcaffiene 7y ago
  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.
  - atoav 7y ago
    Interestingly enough this social factor is also the hardest to deal with in other scenarios (expeditions, film crews, multi-party-projects, ...)

geofft 7y ago

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

Scarbutt 7y ago
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.
- bradleyjg 7y ago
  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"?
  - reallydude 7y ago
    Perception, Comprehension, Analysis, Publication repeat. Somewhere in there, it's doesn't matter if it's "advice" or whatever you want to call it, as long as it's shareable elucidation you can apply your own reasoning...but if you don't bother to follow the pattern, it doesn't matter what you think. Asking someone else to have done these steps for you, is a proxy for a lack of interest, imo. Everyone wants to be lazily told things they either already know or can agree with easily, but being critical in a constructive way is work.

Scarbutt 7y ago

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.html https://martinfowler.com/blik/PresentationDomainDataLayering...

mobjack 7y ago

Software development is as much of an art as a science. Personally I've seen people double down on bad design decisions early in a project that becomes major pain to deal with later on. It is easy to see that if they spent a little extra time on quality in the beginning it would pay off in a few weeks or even sooner. I also see others spend too much time trying to be perfect in the beginning and nothing ever gets delivered or the over engineered solution creates its own form of tech debt. Every situation is different so you need to use judgement whether to apply someone's advice.

deleted 7y ago
[deleted]
crimsonalucard 7y ago
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 decisions driven by data or your gut if the problem space can be described by a logical and axiomatic theory. The problem is that the current "theory" is incomplete and not all parts of systems are amenable to statistical measurement. Thus a proper system architect needs to unify Theory, Science and Art to form a cohesive framework of system architecture. Theory is priority because it says definitive things about the system, Science is secondary and operates as a data driven backup for places theory is currently incomplete, and Art is basically the catch all admission that there is no data or theory to back up the problem space and you're just going to have to rely on your intuition. The problem with Martin Fowler is that all his stuff is 100% Art. It's just made up stuff from intuition and buzz words. Art is largely ad-hoc and does involve a lot of guess work that is often wrong. People identify with Martin Fowlers stuff because they identify with it on the "gut" level. It "feels" right. Your feelings are not a good way to do engineering, you rely only on intuition when you have no choice. Fowler is also a big Object Oriented Architect. The thing with Object Orientation is that it has no basis in theory or science and is almost 100% art. The pattern is starting to fall out of favor because people are realizing that they tend to build over-complicated systems when following the pattern because they are largely just relying on their gut intuition to build these things using primitives that are validated by the same flawed intuition.

hyperpallium 7y ago

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

2_listerine_pls 7y ago
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.
- criddell 7y ago
  That depends on what jurisdiction you are in. The title of engineer is protected in lots of places and the description of software engineer is very specific and effectively regulated. That is, a software engineer is licensed.
- Ozzie_osman 7y ago
  I'd love to see what those scientifically derived principles are. If I'm building a bridge, there are equations based on physics I can use. Like I mentioned in a separate thread, software is far more removed from those physics.
  - eitland 7y ago
    While not exact physics we have plenty of real world constraints that we skillfully (or not) work our way around or use for our advantage, here are two : - Amdalhls law - Moores law
  - hyperpallium 7y ago

deleted 7y ago

[deleted]

perlgeek 7y ago

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.

2_listerine_pls 7y ago

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

dang 7y ago
Please don't post unsubstantive comments here.

blub 7y ago

If you want to see how a properly referenced text looks like, pick any of the following: * Code Complete - McConnell * The Economics of Software Quality - Capers Jones * Facts and Fallacies of Software Engineering - Robert Glass * Making Software - Oram & Wilson ... and there are many others. Not all references have survived the test of time, L. Bossavit describes in his book " Leprechauns of Software Engineering" how several software development "facts" are in fact myths. The approach you suggest suffers from a chicken & egg problem because you first have to be experienced enough to be able to evaluate such reference-free content, as the blog written by Martin Fowler. It's precisely the inexperienced that are likely to internalize such advice and perpetuate personality cults. Your objections are invalid; one does not need to be better at a task than an individual in order to criticize them. Asking for references and proof is perfectly legitimate, at least if we want to approach our discipline more as engineering and less as "Strunk & White" as someone comically suggested in another comment.,

Barrin92 7y ago
>Your objections are invalid; one does not need to be better at a task than an individual in order to criticize them. Asking for references and proof is perfectly legitimate, at least if we want to approach our discipline more as engineering and less as "Strunk & White" as someone comically suggested in another comment Software development, as often as comparisons are made to engineering or science is neither. It's a craft. The tools differ from person to person, each piece of software is different, a lot of practises are learned and tacit and transmitted from one pracitioner to the next. Writing code is more like being a blacksmith than being a scientist, as much as people yearn for formalistic answers and peer reviewed studies so that they can have the appearance of objectivity, a lot of software development is fundamentally subjective.
- blub 7y ago
  Software development does have a certain Darwinian character - whatever survives and thrives can't be wrong. Embracing this seems misguided, because as software becomes more complex, it's no longer enough to have software blacksmiths banging away with their software hammers and unit testing the end result into a releasable shape. Teams working on high-availability, high-reliability software know this and take a rigorous approach. Too many take the BDD approach (blog-driven development) and when the thing inevitably falls apart, the customers pick up the broken pieces.

jonbronson 7y ago

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 organizations where they could encounter how these lessons play out, and so they're dubious about the whole thing. One reaction to being in that position is to downplay the author and complain about lack of 'evidence'. The other, is to put down our egos, and consider that maybe we're just not there yet to appreciate what the author is trying to tell us.

blub 7y ago
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 other kinds of testing that are more effective. I'm not going to claim that everything these authors say is false, but it's high time we say: PoC or GTFO - show us the systems where these rules are applied and let us judge if they're worth anything, don't tell us nice stories.
- tempguy9999 7y ago
  > 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 <authority> 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!

acje 7y ago

I think the article is really on to something, but fails to make it clear. Her is my current belief system; A) Architecture is strategy. Ted Neward was my first inspiration for this. It makes sense particularly when considering systems with long live cycles. Less obvious for smaller designs that don’t se much change over time. B) Strategy is most clearly defined by Good Strategy Bad Strategy: The Difference and Why It Matters Book by Richard P. Rumelt Describes the kernel of strategy as 1) diagnose 2) guiding policy 3) coherent action C) diagnosing is difficult, but both wardley maps and cynefin can help direct us to methods of diagnosing. Unfortunately the immaturity of computer science puts a lot our subsystems in the complex adaptive domain. Partly because we haven’t discovered the best patterns and partly because our tools them selves are a mess of abstractions.

mcnichol 7y ago

There are many arguments that sound logical on their face but completely miss the mark. Laffer curve is one that comes to mind immediately. The saying goes: "It can be explained to congress in 6 minutes and used for 6 months." It can be argued (with data) that it failed. Martin Fowler is no doubt a smart and greatly respected person in this industry. Saying something qualitatively doesn't mean there isn't quantifiable data behind it...but with his vantage point I believe we should press for a higher source of truth. I assume he can understand how important that higher source of truth is in having these conversations regarding what moves the architectural needle. Else we stay in this echo chamber.

deleted 7y ago
[deleted]

goto11 7y ago

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.

sidlls 7y ago
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.
- goto11 7y ago
  This is where I get confused. Are you criticizing a particular architecture, or architecture in general? Is it even possible to have a system without an architecture?
  - james_s_tayler 7y ago
    The Winchester Mystery House does exist in software somewhere.
    - JeffGrigg 7y ago
      Even the Winchester Mystery House has architecture. Pretty good architecture. It's still standing, in spite of earthquakes. She bought it in 1884. Now it has some fairly odd "features" based on her very eccentric "requirements." Doors that open into walls. Stairs that "go nowhere." Very expensive windows that look out at brick walls. But given her odd sense of "requirements," it's the house she wanted!

alanfranz 7y ago

> 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. I love opinions. But if you provide a plot like the one for software quality, you should provide backing data. OR you should clearly state that such plot is totally made up. Nothing else. I have a blog where I write about my opinions. But they're CLEARLY opinions, UNLESS I have some backing data.