8 ms·

I see we're rebranding SOA/microservices again. I did enjoy reading the preview book for EventStorming, seems like a decent format for getting stakeholders inv

I see we're rebranding SOA/microservices again. I did enjoy reading the preview book for EventStorming, seems like a decent format for getting stakeholders involved in the design process and capturing business details. I'm pretty sure you can also do this with an org-mode doc and emailing the right questions to the right people, but discovery is hard and having a big post-it note brain storm with 30 people does sound like more fun! I don't know, I feel like tech people are regularly amazed that other people can describe the events, processes, and data needs of their jobs if you just ask them. Likewise I grant that many people are poorly onboarded and end up "faking it to make it" in their careers. I've seen similar "people lighting up as they finally understand what the company does" moments through the use of literally any form of high-level modeling of the business. People are starved for context at most jobs.

bradhe 4y ago
“Getting stakeholders involved in the design process” is giving me BDD flashbacks. It’s Gherkin all over again.
- rswskg 4y ago
  haha, weren't they meant to be writing the tests by now?
  - mrkeen 4y ago
    I was happy that we got rid of Cucumber at my workplace in 2018. Two weeks ago at my new workplace I sat through a colleague's tech talk about how to test with Cucumber.
    - yosamino 4y ago
      A bit naviely using cucumber seems like a good idea. Could you share some advice or resources on why it might not be ?
      - mrkeen 4y ago
        You're setting up an extra layer of difficulty around the system. Sure, the English is 'easy' to read, as long you do the hard work of converting the test cases to English. Then when something goes wrong or you want to know what's really going on, you have to translate from English back into the system's language to think about it.
        dragonwriter 4y ago
        The utility of Cucumber, it seems to me, is that it makes it more likely that the business level description of the test cases is maintained in sync with the technical implementation, which (if the test cases aren’t squirreled away in the tech team away from the eyes of people responsible directly to customers) makes it less likely that you experience drift between what you are testing and what users rely on the system to do. Its not that it makes testing easier, its that, in the right social context, it makes testing more likely to be aligned with business intent.
        afandian 4y ago
        Not only that, but it enables product owners to actually express the features they want, in such a way as they can be implemented. Without that devs and product owners tend to second-guess each other. I've recently introduced Cucumber and it's been an incredibly useful framework for collaborating between developers and product owners. I'd recommend "Writing Great Specifications" by Kamil Nicieja.
        suzzer99 4y ago
        I own several apps that I wouldn't be able to maintain by myself without good end to end tests. The nice thing about cucumber is I can come back to a test a year later and instantly understand what it's testing for at a requirements level vs. having to reason through the gnarly details of what it actually does, then work backwards to the original requirement. It shines the most in gnarly login/sign up flows that always evolve into all kinds of weird edge cases over time.
  - conradfr 4y ago
    Maybe they'll get ChatGPT to write them for them.
    - rswskg 4y ago
      Maybe we will?
- marcosdumay 4y ago
  The good parts of SOA, the event and CQRS stuff, data administration (and curation recently), and BDD all reduce to the same set of ideas. But then there are always people that look at those and keep exactly the bad parts. Like the links from the article, that all but define event-driven architectures as software that use Kafka.
bennyp101 4y ago
I tried the EventStorming a few years ago with a dept for working out a new system , it was really eye opening how everyone referred to things - seeing it all laid out made them realise they all did things slightly differently, and referred to things differently. It was fun and very useful to not just me, but them as well
mcphage 4y ago
> I see we're rebranding SOA/microservices again. The rebrandings will continue until morale improves.
colonelpopcorn 4y ago
I don't think I can upvote this hard enough. Getting people to think and talk about what they do in context provides a lot of great insight in how to use tech (or not use it) to solve their problems.
- namaria 4y ago
  I agree, but I've experienced quite often people refusing to care about context. Often some variant of "I don't know about that, I only do X".
  - wil421 4y ago
    Or “I have to X, Y, and Z. To get the result I want.” Only to find out X and Y haven’t mattered in years and they only do it because it’s on the form.
    - namaria 4y ago
      Well that's rote learning for you, but I don't think it's the same issue as people avoiding knowing about context. I've met very smart people who know their silos quite well and refuse to acknowledge any picture bigger then they need to, strictly speaking.
erikerikson 4y ago
I disagree. EDA is about how microservices are integrated and, if you establish it, how consistency between them is maintained. Note the talk of ordering guarantees and the like. See also event sourcing and the shifting of responsibility for maintaining data stores: historically data stores were maintained by an authoritative microservice while in many EDA systems multiple copies of the same data stores exist across the system.

bradhe 4y ago

“Getting stakeholders involved in the design process” is giving me BDD flashbacks. It’s Gherkin all over again.

rswskg 4y ago
haha, weren't they meant to be writing the tests by now?
- mrkeen 4y ago
  I was happy that we got rid of Cucumber at my workplace in 2018. Two weeks ago at my new workplace I sat through a colleague's tech talk about how to test with Cucumber.
  - yosamino 4y ago
    A bit naviely using cucumber seems like a good idea. Could you share some advice or resources on why it might not be ?
    - mrkeen 4y ago
      You're setting up an extra layer of difficulty around the system. Sure, the English is 'easy' to read, as long you do the hard work of converting the test cases to English. Then when something goes wrong or you want to know what's really going on, you have to translate from English back into the system's language to think about it.
      - dragonwriter 4y ago
        The utility of Cucumber, it seems to me, is that it makes it more likely that the business level description of the test cases is maintained in sync with the technical implementation, which (if the test cases aren’t squirreled away in the tech team away from the eyes of people responsible directly to customers) makes it less likely that you experience drift between what you are testing and what users rely on the system to do. Its not that it makes testing easier, its that, in the right social context, it makes testing more likely to be aligned with business intent.
        afandian 4y ago
        Not only that, but it enables product owners to actually express the features they want, in such a way as they can be implemented. Without that devs and product owners tend to second-guess each other. I've recently introduced Cucumber and it's been an incredibly useful framework for collaborating between developers and product owners. I'd recommend "Writing Great Specifications" by Kamil Nicieja.
        suzzer99 4y ago
        I own several apps that I wouldn't be able to maintain by myself without good end to end tests. The nice thing about cucumber is I can come back to a test a year later and instantly understand what it's testing for at a requirements level vs. having to reason through the gnarly details of what it actually does, then work backwards to the original requirement. It shines the most in gnarly login/sign up flows that always evolve into all kinds of weird edge cases over time.
- conradfr 4y ago
  Maybe they'll get ChatGPT to write them for them.
  - rswskg 4y ago
    Maybe we will?
marcosdumay 4y ago
The good parts of SOA, the event and CQRS stuff, data administration (and curation recently), and BDD all reduce to the same set of ideas. But then there are always people that look at those and keep exactly the bad parts. Like the links from the article, that all but define event-driven architectures as software that use Kafka.

bennyp101 4y ago

I tried the EventStorming a few years ago with a dept for working out a new system , it was really eye opening how everyone referred to things - seeing it all laid out made them realise they all did things slightly differently, and referred to things differently. It was fun and very useful to not just me, but them as well

mcphage 4y ago

> I see we're rebranding SOA/microservices again. The rebrandings will continue until morale improves.

colonelpopcorn 4y ago

I don't think I can upvote this hard enough. Getting people to think and talk about what they do in context provides a lot of great insight in how to use tech (or not use it) to solve their problems.

namaria 4y ago
I agree, but I've experienced quite often people refusing to care about context. Often some variant of "I don't know about that, I only do X".
- wil421 4y ago
  Or “I have to X, Y, and Z. To get the result I want.” Only to find out X and Y haven’t mattered in years and they only do it because it’s on the form.
  - namaria 4y ago
    Well that's rote learning for you, but I don't think it's the same issue as people avoiding knowing about context. I've met very smart people who know their silos quite well and refuse to acknowledge any picture bigger then they need to, strictly speaking.

erikerikson 4y ago

I disagree. EDA is about how microservices are integrated and, if you establish it, how consistency between them is maintained. Note the talk of ordering guarantees and the like. See also event sourcing and the shifting of responsibility for maintaining data stores: historically data stores were maintained by an authoritative microservice while in many EDA systems multiple copies of the same data stores exist across the system.