HackerTrans
TopNewTrendsCommentsPastAskShowJobs

mickduprez

no profile record

Submissions

Thinking in Hoses and Wires, Not Bolted Gears (Protocol-Driven Development)

github.com
3 points·by mickduprez·11 mesi fa·1 comments

comments

mickduprez
·3 mesi fa·discuss
I think that Agile in principle is a good idea, keep iterations small and work on the issues together and deliver working products. The missing piece I think is that PDCA (Plan/Do/Check/Act) cycle isn't being done correctly. The idea is not just to improve the product but to improve the process of creating the product. This may mean you stray way of the path of the Agile system but that doesn't matter, the standard Agile process is just a starting point, it's your shop, create it how you like.

I like a saying from the LEAN manufacturing culture - "The Process is the Expert" but that comes with a caveat, each and every team member is a Process Engineer!
mickduprez
·8 mesi fa·discuss
I agree, very true when used for purposes as you noted. I guess my point was more about using them as a way solve the underlying problems a large OO system can develop. Microservices enforce you to package data sets for transport, it's very functional if you only take the data and transport into consideration, the mess can still happen within the microservice though.
mickduprez
·8 mesi fa·discuss
>> _Anecdotally, I've replaced OOP with plain data structures and functions._

I think this is why FP is becoming more popular these days but I'm not sure some people get why. The problem with OOP is you take a data set and spread it all over a 'system' of stateful (mutable) objects and wonder why it doesn't/can't all fit back into place when you need it to. OOP looks great on paper and I love the premise but...

With FP you take a data set and pass it through a pipeline of functions that give back the same dataset or you take a part of that data out, work on it and put it straight back. All your state lives in one place, mutable changes are performed at the edges, not internally somewhere in a mass of 'instances'.

I think micro services et al try to alleviate this by spreading the OO system's instances into silos but that just moves the problems elsewhere.
mickduprez
·9 mesi fa·discuss
"A radio built like this, with individual subsystems connected together, is much more understandable."

Yes! this has been my experience too, building something from first principles and given some tools and direction to experiment you get the chance, and experience, to really learn. I've been looking for resources like this for building amps but they're either small signal or the whole design. You understand how they work but not where and what to change if you wanted to tinker or build your own.
mickduprez
·11 mesi fa·discuss
I totally agree and recently wrote a piece about this and how I came to the same question: "what can we learn?" https://github.com/MickDuprez/Protocol-Driven-Development

Even if you do use micro-services you still need a protocol!
mickduprez
·11 mesi fa·discuss
A short, self-contained design article I wrote after rediscovering the original, 'actual' intent behind Smalltalk's message passing.
mickduprez
·2 anni fa·discuss
The power of words! Nothing new here really, it's the old systems/process vs goal story but actually I felt that one word make a cognitive shift, for me at least :)