This is a bit beyond architecture, but being competent to build a mathematically bug-free API is probably something that few programmers would even bother trying to compete-against…

https://leanpub.com/algebra-driven-design

---

I think there is a fundamental mis-framing, throughout the entire software/development understanding…

I think that the architecture needs to be simultaneously agilely-devloped, but into an executable-model, a kind of toy-implimentation, so it is easy to change the architecture, low-cost, BEFORE one converts it into load-bearing, & therefore unchangeable architecture ( architecture’s the hardest thing to change, as it’s most-fundamental )

So, I think that the proper way is to do it in 2 stages:

1. agilely develop the architecture, until ALL required-kinds-of-function are working, in the toy-model, & one has re-architected it so that the structure is right, & then
2. set about converting it from the high-level-language to whatever production-language it is that is efficiency-optimal, for production-scale.

This is part of an idea from years ago: I read in a Wiley GAAP book that I happened to be glancing into, that it’s a violation of GAAP to prototype any project in any language other than the final-implimentation-language, & expense that prototype.

Which is totally insane!

Prototype in the highest-level-language you can, to get the domain+architecture right, then reimpliment what you have to in the most production-efficient/effective language for that project.

GAAP ( of that year ) is categorically wrong: it penalizes optimal-prototyping.

It was years-later before I discovered that an English mathematician ( roundish ginger, worked in Glasgow, no idea what his name was, sorry ) had studied the difference between complex projects which worked vs ones which died, & it was the visual-spacial-representation-of-the-model, & the complete-coverage executable-model which made the successes win.

So, I just put those ideas together.

_ /\ _