clojure-nl

Companies working with Clojure in The Netherlands: https://docs.google.com/spreadsheets/d/1NzOqY1v-OReB1IquUgHuT3Kh8K8jhPdlwBM6ds7id6Y/edit?usp=sharing
thomas 2021-01-14T08:59:59.000300Z

mogge

borkdude 2021-01-14T09:01:05.000500Z

mogguh

gklijs 2021-01-14T09:14:34.001400Z

Morgen, maybe finally going to ‘production’ today. With a project they started on 3 years ago..

😱 4
thomas 2021-01-14T09:46:53.001800Z

exciting

gklijs 2021-01-14T10:03:57.002700Z

Might take some time longer.. very happy that I’m just along the last half year for this project and not from start.

kwrooijen 2021-01-14T10:14:44.006Z

I remember someone giving a talk a while back and told the story about his job having yearly release cycles. But once they released they had to do a lot of bug fixes. To prevent this issue, management thought of the idea to have a two year release cycle instead of one. The speaker suggested to them that maybe it would be better to release faster. At which point he almost lost his job

worrelsik 2021-01-15T08:45:34.012400Z

@thomas Can you explain that Thomas, since I don't understand what the advantage would have been of 'cloud first'? What if that scenario went wrong: upgrade the cloud: OK, but releasing onPrem: fail?

thomas 2021-01-15T08:47:15.012600Z

on cloud you can make lots of little updates. CI/CD. deploying several times a day.

thomas 2021-01-15T08:48:04.012800Z

with a onPrem solution that is not really possible as companies only want to upgrade once is a while. (not automated downloads of new packages as your Linux distro for instance)

thomas 2021-01-15T08:48:20.013Z

does that make sense @roger429?

worrelsik 2021-01-15T08:53:05.013500Z

Ah, OK. But there's not a (big) problem then of functionality being out-of-sync (one colleague using onPrem version 1.x, other colleague using cloud version 1.x+n)?

thomas 2021-01-15T09:14:13.013900Z

I guess customers used one ot the other.

thomas 2021-01-15T09:14:15.014100Z

(this was enterprise stuff)

worrelsik 2021-01-15T09:41:16.014300Z

Thx for elaborating!

gklijs 2021-01-14T10:16:26.007400Z

Releases go fine, and we are in full control of those. The problem is getting other teams to use or services. In fact we did all the coding on there product to use our service..

thomas 2021-01-14T10:41:14.007500Z

that is just so appalling... as he was right of course.

Mno 2021-01-14T11:06:52.007700Z

Huh.. Unless it's avionics software or something very very mission critical.. That doesn't make much sense.

thomas 2021-01-14T12:28:43.007900Z

not sure I agree... the problem here is that they wrote lots of code, never tested it properly and then tried to do a big bang update. For mission critical (Avionics) software you would do loads more testing and do things like proofs etc. very different process.

Mno 2021-01-14T15:47:50.008600Z

Oh I didn’t say mornin’ today

Mno 2021-01-14T15:48:44.008900Z

You make a good point, I assumed testing was done in between long release cycles

Mno 2021-01-14T15:49:17.009100Z

Mornin’

👋 1
thomas 2021-01-14T16:15:47.009200Z

considering they had lots of bugs the testing wasn't that good....

thomas 2021-01-14T16:17:02.009400Z

but it reminded me of story from one of my previous employers.... they released the onPrem version first and then tried to upgrade the cloud... and this failed... so they reverted to the old version... and then the execs demanded new functionality before attempting to upgrade again.

thomas 2021-01-14T16:17:10.009600Z

and that would fail as well of course...

thomas 2021-01-14T16:17:17.009800Z

rinse and repeat

thomas 2021-01-14T16:17:31.010Z

they should have done cloud first of course.

gklijs 2021-01-14T19:22:00.011500Z

Acceptance went fine, so prod tomorrow morning. Than finally end users will use our service 😀

👏 3
gklijs 2021-01-14T19:24:57.011600Z

Yes, I also like libraries that first put the code in production, before making a release. Lacinia does this.