Comment by prepend | Hacker News Reader

Comment by prepend | Hacker News Reader

This one of those things that sounds simple to do, but is rarely done. And there’s lots of cultural forces that work against it.

I think it addresses a big problem with important tech decisions- how to weigh engineering value and focus energy on the technical merits, not on political buy-in.

I work within a decent size government org where leadership is almost exclusively non-tech (makes sense because we’re not an org with a tech mission), and almost all tech management is program mgmt, business analysis, strategy. And the building is almost exclusively contractors.

This means to make a technical decision, it’s hard to evaluate because the tech manager doesn’t known whether MySQL or Postgres is better, and contractors have incentives to not invite review by other contractors and making it “good enough” for contract acceptance.

This means if a developer picks mysql, and the project manager is happy because it’s projected to be delivered in time, then there’s two big forces that don’t want comment on design.

We just started to try a request for comment process, but the extra effort to review is challenging. I think that on the surface it’s because letting large groups see your design before start introduces organizational risk.

And then a bit deeper is that it requires a greater level of technical depth in decision makers.

Many people call this "Enterprise architecture" and although painful tends to be worth doing.

You can think of it (simplified) as 4 steps: 1) figuring out and deciding which technologies to use for which domains and problems (these tend to be called capabilities) 2) getting rid of the ones you don't want to use 3a) enforcing use of existing, approved capabilities for new projects 3b) building out new capabilities

1) Tends to have the problem you pointed out: "it requires a greater level of technical depth in decision makers". Something that may work is to have some senior engineers in-house and embed them in the outsourced projects doing part of the real work. 2) This can be a multi-year program that needs to be separately funded. Think of it as enterprise-level technical debt. 3a) This can be the easiest part: your architecture should be part of the RFP process, with a well-defined escape hatch to 3b) 3b) Building out new capabilities needs to be i) funded separately but best ii) done as part of a real project. Otherwise you'll i) have crossed incentives with the projects as you pointed out, or ii) architecture astronauts.

HTH. There's plenty of literature on enterprise architecture, but there's no silver bullet, it's just hard work.

Yes, I agree, and that's why I'm trying to take this approach.

Interestingly I work in a world where enterprise architecture means something completely different. PM me for more details.

>because letting large groups see your design before start introduces organizational risk.

What is the risk to be specific? Just curious.

There's a few, the most tangible is that someone not technically qualified deems the design inferior and communicates to decision makers. So there's this kafka-esque experience where someone two degrees from engineering asks you to defend against a misunderstanding of proper design.

Maybe the easiest to deflect is "You're developing in Ada, and we prefer Lisp, etc. etc."

Reply on news.ycombinator.com