Development Philosophy
Each and every of successful team leads has their own philosophy. And while there is no “one correct” philosophy (in the very same manner as there is no “one correct” religion), different philosophies lead to different results.
Of course, as successful team leads, IT Hares have their own philosophy, which they’re not ashamed to share.
Bringing Architecture of Operating Systems to XXI Century – Part I. Changes in IT Over Last 50 Years
April 15, 2019 by • “No Bugs” Bunny
Quote:
we’re using operating systems which were designed whopping 40-50 years from now
Another Quote:
Do not communicate by sharing memory; instead, share memory by communicating.
Filed under: On.System ArchitectureRequirement analysis(Re)ActorsOn.DevelopmentDevelopment Philosophy
Read moreC++: "model of the hardware" vs "model of the compiler"
October 3, 2018 by • “No Bugs” Bunny
Quote:
we MUST NOT care about compiler internals beyond our task definition (which is based on (a) humans, and (b) hardware, that’s it).
Another Quote:
My problem with introducing a ‘model of the compiler’ into the picture, is that it can be used to justify pretty much anything without any relation to real-world requirements.
Filed under: On.ProgrammingProgramming LanguagesOn.DevelopmentDevelopment Philosophy
Unchecked Exceptions for C++
June 7, 2018 by • “No Bugs” Bunny
Quote:
‘unchecked’ std::errors are treated as ‘something which should never ever happen, but in practice MAY occur as a result of potentially-recoverable bug'
Another Quote:
Failing-Fast does NOT mean we should necessarily Fail-Hard(!). In certain (production!) cases, Failing-Fast-AND-Soft IS a substantially better alternative.
Filed under: On.System ArchitectureDesign decisionsOn.ProgrammingProgramming LanguagesOn.DevelopmentDevelopment Philosophy
Knowledge-Sharing Architects As An Alternative to Coding Architects
July 25, 2016 by • “No Bugs” Bunny
Quote:
Yes, a coding architect might work (and is indeed orders of magnitude better than an architect who has no clue about the code), but a knowledge-sharing architect will generally work better.
Another Quote:
As a nice side effect, the very same knowledge sharing weakens a dependency on the architect (and reducing any dependency on a specific person is a Universally Good Thing™).
Filed under: On.DevelopmentDevelopment PhilosophyDevelopment ProcessesTeam structure
Read more


