Design decisions
When architecting a system, it is inevitable to make certain high-level design decisions.
Some of these decisions, if they’re wrong, can lead to the re-architecturing and re-writing of the whole system some months later, so there is an incentive to keep things rather generic. On the other hand, trying to make system too generic is just another recipe to disaster (usually expressed in terms of missed deadlines and unmanageable code).
IT Hares try to describe certain not-so-obvious architectural decisions, and some considerations which should be kept in mind while making them.
Size Matters - Is 64-bit App Always Better?
May 1, 2014 by • “No Bugs” Bunny
Abstract:
Sometimes it makes perfect sense to use 32-bit application on 64-bit platform.
Quote:
It is obvious that for N between 13,000,000 and 21,000,000, 64-bit application works about 1000x slower.
Filed under: On.System ArchitectureRequirement analysisDesign decisionsOn.ProgrammingOptimizations
Read moreKeep It Simple, Singleton!
November 1, 2012 by • “No Bugs” Bunny
Abstract:
Naïve mappings from business domain to programmer domain tend to survive requirement changes better
Quote:
How do we distinguish good assumptions from bad ones?
Filed under: On.System ArchitectureDesign decisionsOn.DevelopmentDevelopment Philosophy
Read moreOver-Generic Use of Abstractions as a Major Cause of Wasting Resources
September 1, 2011 by • “No Bugs” Bunny
Abstract:
Trying to be too generic can easily cause many-fold inefficiencies.
Quote:
It was a quiet night and I was downloading a 2G ZIP file with Internet Explorer...
Filed under: On.System ArchitectureDesign decisionsOn.ProgrammingOptimizations
Read moreOverused Code Reuse
March 1, 2011 by • “No Bugs” Bunny
Abstract:
When done imporerply, code reuse can cause severe problems, including loss of life.
Quote:
Reusing code from other projects or (even worse) from 3rd-parties SHOULD NOT be taken lightly. Or else...
Filed under: On.System ArchitectureDesign decisionsOn.DevelopmentDevelopment Philosophy
Read more