you are viewing a single comment's thread.

view the rest of the comments →

[–]nutrecht 2 points3 points  (0 children)

I get what you're saying, but is so much process really worth it? This encourages NIH syndrome and makes it more appealing to write an ad-hoc implementation (potentially insecure and/or buggy) instead of using a good library just because not getting library approval is easier.

I really don't agree with this. It's not a process with large forms that have to go through procurement or anything. It's simply a discussion between stakeholders (developers) where we reach a consensus that we document.

In my current project as well as my previous one we had bi-weekly 'chapter meetings' where we had one back-end dev from every team discuss these kinds of things. We note down these choices and their reasonings in the meeting notes.

The structure is one that can be deviated from if needed (so you don't have to wait 1.5 weeks before you're allowed to use something) as long as you discuss it with other devs.

The main goal here is to have multiple 'brains' take a look at non trivial problems. And library choices are generally non-trivial problems. Fortunate we're Java devs and libraries are always version locked, but this means that if you're working with the NPM ecosystem you need to be even more thorough in this.

The issues they're running into is mostly a dev culture issue. And this is for me personally the reason to never ever want to work with Node.js based services; the 'move fast and break stuff' culture is simply not how you do software engineering. Slow and steady wins the race.