10. Abstraction: What we do all the time!
• Abstraction is to figure out what changes and what doesn’t over the
set of all concrete instances
• To identify one thing with a name, is to abstract it
• Is to identify what is invariant and ignore the rest
• Invariants are what we make public in our code, they will not change
12. Abstraction: Name things properly
• A proper name conveys a proper definition that is often commonly
shared and thoughtfully developed overtime
• A proper definition provides a proper list of invariants
• This is why we need to properly name our entities in software
13. Software Architecture: What is it?
• Architecture is the proper abstraction of a problem
• Proper is easy to implement in the programming language, efficient,
and infallible (there often is more criteria to meet)
• Infallible is often what is factually correct.
14. Software Architecture: What makes it
• Often trade-offs are necessary as not all might be achievable at the
• Architect optimizes over these variables
• These could be differently weighted depending on the problem
• Often efficiency disallows factually correct abstraction of problems
15. Software Architecture: What makes a good
• A good language allows better optimization over these variables
• In problems with less emphasis on efficiency, higher level languages
may prove more effective as they allow more factually correct
16. Software Architecture: How it fails!
• Of the aforementioned criteria, efficiency can be optimized later on in
• Easy to implement is often a non-issue, however in the lack of skilled
human resources, it is
• Factual correctness often is the cause for large scale refactoring, or
code rewrites due to architecture failure
17. Software Architecture: When does it fail?
• Architecture often fails when new features arrive
• Failure in ease of implementation is detectable while implementing
• Failure in efficiency is detectable right after implementation with
• Factual correctness of the abstractions fails when unexpected cases
arrive, often with new features
• This is often because your abstractions contradicts with parts of itself
• Reality never contradicts with itself, implement as much of the
factually know reality as possible
18. Software Architecture: How not to fail!
• Be consistent with the real world, as much as possible
• Don’t assume things on yourself, your assumption could result in
• Know your language well
• Know your intent well
• Implement your intent
19. Programing language: The friend
• A language is a means of communicating meanings
• A programmer is just as much of a writer as a writer is
• A writer transfers his intents well, only relying on his good grasp of
• A piece of code is a writing that has two separate audience,
computers and humans (well a sort of them, programmers!)
• A good grasp of the language is necessary for proper implementation
• The language use in teams are often culturally effected, teach and
learn the culture to avoid drastic code rewrites
20. Programing language: The enemy
• A programming language can lean towards either computers, or
humans too disproportionately
• Can hurt the computer by degrading the performance, a computer
performs more efficiently if the intent is well understood
• Can hurt the programmer by making development, and maintenance
• Bad cultures maintained well can result in painful code maintenance
• Find the bad cultures and eradicate them
21. Programing language: Humane
• Just as humans, a programming language is never perfect
• Often when you don’t implement your intent, you desire to
implement your intent but the language simply doesn’t allow it
• Compromise more on higher levels of abstraction rather than the
• Higher levels of abstraction often effect larger areas of the code
• Lower levels often effect less amount of code
• The less amount effected by the code the easier the change, rewrite,
and refactoring tasks
22. Programming language: ASM, Machine
• This is a language that in the spectrum leans completely towards
• The best tool to convey intents to computers
• Not really a good one for humans, is it
• Also not all computers talk the same
23. Programming language: C++, My beloved so
• Tries to maintain a good trade off between humans and computers
• Falls short sometimes in communication with humans
• Template meta-programming certainly worked well with computers,
not so well with humans
• Unique pointers seemingly do well with humans, but in some cases
that inlining isn’t available they seem to fall short to convey intent to
• The committee responds to these by figuring out the most prevalent
cause of unease in communications and remedies them by new
features, e.g. constexpr
That is one beautiful chair huh!
What is it we call a chair, should it always have legs? A back rest? We know what chair is don’t we? We certainly can recognize one when we see it, but what really is a chair?
Can any one provide a definition?
Maybe not all have four legs!
Does this one have a leg? If yes what is a leg?
Are those legs too?
What about this one?
Ok cars should be more simple! 4 wheels, some door, and there it is!
Umm ok, 3 or 4 wheels!
Well some wheels, but is 2 wheels ok too?
All cases considered, we are infallible, let the features rain in.