software-development

ity standards Technologies Used * Ruby (experience required) * Eventide / MessageDB * Rails * PostgreSQL * JavaScript You can read more about our practices and culture here: https://github.com/aaronjensen/software-development Email aaron at substantial dot com if you are interested. No recruiters, please.

al work (see Lean, Steven Spear's work, etc.). Good luck in your product and learning journey. Hopefully we can connect again down the road. Cheers. [1] https://github.com/aaronjensen/software-development/blob/mas...

nical issues in terms of latency and cascading failures. The existence of a control plane doesn't impact my concern about this, but it does add an additional concern. See smart pipes vs. dumb pipes. [3] > I do apologise for having a modern looking marketing page. That's not necessary, I wasn't saying that was bad. It looks nice, but if it's marketing something that can be harmful, that would be the problem. Its aesthetics are a differentiating factor. I wasn't trying to say anything more about it than that. > But the reason why this has been tried before in the software development history tells me that the proper abstraction is somewhere out there. Maybe, or maybe we don't pay enough attention to our past learnings and the body of knowledge that came before us. > Wise words, but I'd appreciate it if you could dive into the way things are [1] [3] a little bit, and let me know if you hold the same views. I read these, and there's nothing that I would consider new, although it is somewhat surprising to read what effectively amounts to the goal being to add network hops and complexity to monolithic code in order to get scaling and other technical benefits. > Monolithic codebases provide a great developer experience, but resulting monolithic services often do not. I disagree [5]. They only appear to provide that to teams that don't yet have the skills necessary to do proper partitioning. I believe that teams, and developers in general, will be better served by learning how to do this. They will unlock long term continuity [6] in productivity that they couldn't have imagined. > Instead of n services talking to n services... Here's a hint at the fundamental disconnect. Services shouldn't talk to other services. Period. Not if that can be avoided. See: autonomy. This is where pub/sub comes in. When services have autonomy, developers have productivity, and products are more resilient (at the very least). [1] https://github.com/aaronjensen/software-development/blob/mas... [2] https://github.com/aaronjensen/software-development/blob/mas... [3] https://twitter.com/sbellware/status/1760037861347258416 [4] https://eventide-project.org/ [5] https://github.com/aaronjensen/software-development/blob/mas... [6] https://github.com/aaronjensen/software-development/blob/mas...

route. We use the term "structural design" quite a bit, so I'm curious to see Yourdon's take on what they call "structured design". From everything I've read about it, it sounds very similar to a lot of how we think about things as it seems to be the basis for much of the coupling and cohesion thought in our industry. I'd also recommend studying Lean (not Lean Startup, which has much to do with Lean as non-fat yogurt does).

et peanut butter in our mayonaise. Each part is independently built and tested. When it's time to upgrade Rails, we can upgrade one application. This is 1/20th of our Rails code. That's a smaller batch. We know from basic flow principles that (see: Principles of Product Development Flow, Lean, etc.) that small batches are better for productivity. We rarely have merge conflicts. We don't do pull requests. We branch when we need to. We are often working on a brand new, never been deployed project. We don't have our tests running in CI. Our tests run in less than a second in most projects on our laptops. With those that have UI, our tests typically run in less than 30 seconds which include thorough Capybara (UI Interaction) testing. When we are working in any application, we only need to consider its direct efferents when making a change to any interfaces it exposes. We can trace those changes through easily when we need to make them. Because we practice software design, we don't often need to make large sweeping changes, but when we do, we can do them methodically without disruption. The "worst" part is that some things are tedious. But we can automate tedious things. We can invent around tedious things. We used to have to deploy 15 web applications any time we had a style change. Now we deploy one application that supplies the CSS for all our applications via SSI (server-side-include). If we need to deploy 70 back end components, we can script that (with manual verification at each step). We can even spread that out across a couple team members and do it as an ensemble. It takes about an hour to deploy everything. We maybe do this once a month or so (when something highly afferent changes -- and guess what, we structure our design so that afferent things change as infrequently as possible). Most things we work on we work until they are "complete". That is, they rarely change after that. We have components that have been in production for 3 years and haven't been substantially touched aside from Ruby upgrades and the like. They are still perfectly in control. The list goes on and on. Here are a few articles, feel free to poke around the others and ask any follow up questions. Partitions and Compositions: https://github.com/aaronjensen/software-development/blob/mas... The Mythical Monolith: https://github.com/aaronjensen/software-development/blob/mas...