And you are here why?

/via http://mibt.edu.au/certificate-iii-in-concreting-cpc30313/ You’ve heard of “ concreting ”, right? No, I’m not referring to the verbing of the noun “concrete”, I’m actually referring to  the construction process around laying concrete . It’s a term of art, referring to getting the concrete  as close as possible to its final position , as quickly and  as efficiently as feasible , to ensure that  it can be fully compacted , and that  there is no segregation  . The thing about concreting is,   it’s Engineering . You don’t just wake up one day, and say to yourself “yeah, I think I’m gonna pour foundations”, and start doing it. More importantly, even if you   were   to start doing it, nobody in their right mind would (or should!) actually hire you to actually do it. Most importantly of all, if you’ve come up with (what you believe is!) a new and improved way to pour concrete,   the burden of proof is on you to show that it works ....

Do you know what your component’s dependencies are? OK, fine,   you   know, but does everybody else on your team know? Great, they know too. Now for the really important part — does what   you   know match what   they know? You’d be surprised how often that   semantic mismatch happens. The folks working on   component XXX   need to temporarily persist stuff, and use the postgres infrastructure that the   component YYY   folks are so conveniently running in production. Which is awesome, right up to the point that the   component YYY   folks finish their migration to ElasticSearch, and deprecate postgres… The moral of the story — document (and share!) the design assumptions behind the architecture across all your teams. Whats more, on a fairly regular basis, reassess these assumptions, and see if anything needs to be added, updated, or removed!

You think I'd have learned by now, but the following rules are ones that always hit me upside the head, even though I know better! I'm not saying that these rules are inviolable (this is software after all!). It's just that if you violate the rule, be sure to have an excellent reason involved, and even then, check again, and then document it. The documentation, in particular, will help you remind yourself what a butthead you are… 1. Make Scaling intrinsic to the design . It doesn't matter whether this means autoscale groups, k8s, or auto-instantiation of domain objects, the point here is that scale - at all levels - can not, and should not, be something that you bolt on afterwards. 2. Make Deployment a first class citizen . Ideally, a merge into master should trigger a production deployment. And yes, this implies code coverage, comprehensive testing, toolchains, and everything else you've (hopefully!) read about. Maybe you're not there yet, but you rea...

Let’s start with a somewhat innocuous question — “ How well does the design of your system map against the value that it delivers? ” A little bit of pondering reveals that this is a bit of a trick question, since it covers a whole range of possibilities.. After all,  System  is a ridiculously overloaded term, that can refer to anything ranging from Infrastructure (“ k8s on GCP! ,  Postgres! Swagger! React! ”), to Logic (“ CQRS, with event-sourcing tied into a scatter-gather approach! ”), and pretty much everything else in between, above, and below. Design  is equally loaded — is the “low-level” stuff ( k8s, Postgres, etc. ) actually part of the Design? After all, it  could  be, if it is going to inform a “build-vs buy” decision for you by, say, making you roll your own database! That said, the point here is that the question forces you to confront  Value , and actually spell out what it means to you. And the process of spelling it out will act...