Me too, although I admit I am sometimes part of that problem. The experience zombie in me gets ahead of itself too many times. That’s largely because governance and compliance has bitten me too many times. 😧

A common challenge of the need to slow down first to really unpack the problem/challenge before diving into a "fix".

I’ve found beyond identifying the problem it’s important to find common ground on an acceptable outcome. This has been especially true especially when dealing with compliance/security issues and can help reduce cycle time or break a deadlock between groups.

That’s very true. It is often too easy to walk down a path where one side appears to be the new superheroes only to be knocked down 6 months later once the scans get analyzed, CVEs get reported, or Vulnerability management kicks in. And then, it becomes a “We told you so proposition”. Trying to get consensus up front has not been working so well from personal experience because compliance will not budge from the paperwork drill. I hope I am not sounding like a lazy developer but I often think that’s how devs are perceived sometimes.

@US9F8GHS8, I am also not free of it. Good to see that I am not alone with that. 😀

We actually already talked about this in that other channel, but I wanted to share this article with any folks who might've missed it. https://mcfunley.com/choose-boring-technology

Thank you. I did miss that discussion.

Also have seen that often organization "buy" the new shine product, without proper analysis if it is indeed solving the problem, and if it suits the technology stack

@US9F8GHS8 I think Jerreck is referring to this discussion: https://itrevbookclub.slack.com/archives/CSHTHK72R/p1578856271003600 (GraphQL question ...) and then look at the discussion thread.

So here’s a question: let’s say you’ve analyzed the problem thoroughly and come up with valid solutions. How do you then make a decision, who decides, and how do you avoid making a TEP-LARB? Currently trying to find the part of TUP where that question is answered, but I’m wondering what yal’s thoughts are as well.

I think I found it, it wasn’t just one moment. There was the moment where Dewayne and the rebellion started their own team to support TUP in chapter 10 I think and then there’s an example of them making a decision in chapter 14 about the data hub - they just discussed and then made a decision… easy as that. I remember later on there being a bit about Maxine saying “that’s why you need architects because teams will optimize around themselves sometimes to the detriment of the entire system” though, which is something I’m also curious about. How do you empower a team to make a decision but also still consider the entire system in those decisions?

I have been lucky to work with great architects who don't drop solutions on the table without having learned about the business objectives and team interests first. If a project requires the usage of a database, the governance decides what brands of databases are being supported by the business and the architect tries to figure out if the feature team has an interest in learning a new type of database (e.g. NoSQL over RDBMS), if the project is fit for such a solution and if training and mentoring can be provided for the preferred solution.

Every damn day. I work for a large consultancy that primarily supports government clients. Government acquisition processes are entirely predicated on empowering these jokers to come up with full enterprise solutions with minimal information and no time to dive into the issues. Solutioneering is the way of the game. There is a reason everything is so problematic