1. Code Design: Back to Basic
Hosein Ghahramanzadeh

2. Abstractions: What is a chair?

3. Abstractions: Is this a chair?

4. Abstractions: Is this a chair?

5. Abstractions: Is this a chair?

6. Abstractions: Or is this a chair?

7. Abstractions: What is a car?

8. Abstraction: Is this a car?

9. Abstraction: Or is this a car?

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

11. Abstraction: Dictionary!
• A dictionary provides definition
for words
• A definition for a word is the list
of that concept’s invariants

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
difficult?
• Often trade-offs are necessary as not all might be achievable at the
same time
• 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
programming language?
• 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
abstractions

16. Software Architecture: How it fails!
• Of the aforementioned criteria, efficiency can be optimized later on in
implementation
• 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
performance tests
• 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
wrong invariants
• 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
the language
• 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
of intent
• 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
unbearable
• 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
lower
• 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
language?
• This is a language that in the spectrum leans completely towards
computers
• 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
far
• 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
computers
• 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

24. Code: The case of the chair

25. Code: No chair can grow legs? Chair races
don’t combine?

26. Code: No weird legs! Bigotry makes life easier
for our developers!

27. Code: Only four legged chairs allowed, we
love our CPU cycles!

28. Questions?