Writing better code and managing complexity following the principals of the all times programming classic Code Complete by Steve McConnell Check out the video: http://goo.gl/hbXLPZ

1. NEW PERSPECTIVE
Asher Barak

2. PART ONE
ne principle to rule them all

3. 1920 - 2012
one of the founders of the cognitive
psychology field
GEORGE A.
MILLER

4. THE MAGICAL
NUMBER
2

5. 1930 - 2002
Dutch computer scientist
Edsger W.
Dijkstra
Go To Statement Considered Harmful

6. SOFTWARE
Is Too Complex
For Our
BRAIN

7. MANAGING
COMPLEXITY
Your #1 goal should be

8. ARISTOTLE
Geek philosopher
384 – 322 BCE

9. Essential Accidentalvs

10. SOFTWARE COMPLEXITY
• Computers speak a binary language
• Computers are batch machines
• There is a wide gap between coding and
running software
• Computers are terrible with concurrency
• Computers have physical limitations
• Computer software model a complex world
Essential

11. ONE THING AT A TIME

12. CARE ABOUT LESS
• Do as little as possible
• Divide (& conquer)
• Hide the details - Work
with layered
abstractions
• Reduce the noise

13. LANGUAGE
FUNDAMENTALS

14. Class
Method
Procedural
Code

15. Layer
Module
Class

16. USE INTERFACES
• Do as little as possible
• Divide (And Conquer)
• Hide the details - Work
with layered
abstractions
• Reduce the noise

17. CODING
PRACTICES

18. THINK OF YOUR
AUDIENCE
(It’s not the compiler)

19. NAME STUFF
• With the right name
• In a standard way
• Methods – For what they do
• Functions – For what they return
• Classes – For what they represent
• Modules – For what they pack

20. USE CONVENTIONS
Any convention is better than no convention
Every convention is one less thing to think about

21. USE CONVENTIONS
• Naming Conventions
• Method parameters conventions
• Resources placing conventions
• Documenting conventions
• Code layout conventions
• Meeting conventions
• Everything conventions

22. USE CONVENTIONS

23. CONSISTENT ABSTRACTIONS
Problem Domain
Language/Platform

24. CONSISTENT ABSTRACTIONS
Problem Domain
Problem Domain Lower Level

25. USE DESIGN PATTERNS
• They represent a higher abstraction
over coding details
• They simplify communications in the
team
• They are conceptual standard reusable
units

26. TDD
• Promotes better divisions
• Promotes better abstractions
• Promotes better documentation
• Promotes better personal
character
• Restrains complexity

27. DESIGN BEST
PRACTICES

28. • Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise

29. • Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise

30. • Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise

31. • Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise

32. • Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise

33. • Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise

34. • Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise

36. • Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise

37. • Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise

38. • Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise

39. • Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise

40. • Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise

41. PART TWO
Make it your own

42. PROGRAMMING IS
DONE SOLO
Creating a culture requires communication

43. FACE THE TRUTH
Some people program
for the wrong reasons

44. ACTIVELY ENCOURAGE
SOCIALIZING
Preferably of people who like their job

45. TALK
ABOUT
THE
PROCESS

46. BE OPENLY EXCITED
ABOUT GOOD
CRAFTSMANSHIP
(With tears if possible)

47. TALK ABOUT
READABILITY
Is it good for readability or is it bad?

48. TALK ABOUT
ABSTRACTIONS
Try splitting discussion the way code is split

49. ACTIVELY ENCOURAGE
MORE DESIGN
This is hardly ever a problem

50. ACTIVELY ENCOURAGE
DESIGN CONSULTING
Everyone ends up smarter

51. PUT PERFORMANCE &
EFFICIENCY SECOND
Maintainability first

52. PUT PERFORMANCE &
EFFICIENCY SECOND
• We are not good at anticipating
resources issues
• We are not good at anticipating
performance issues
• KISS until otherwise proven

53. HAVE EXPECTATIONS
• Read (and understand) error messages
• Read (and understand) compiler warning
• Document and read documentation
• Know (and avoid) code smells (Keep a
document)

54. TALK ABOUT
CONVENTIONS
• Keep a document
• Make newbie's read the document
• Discuss conventions with your team
• Make any code feel at home to
everyone in the company

55. TALK ABOUT CODE
• Code reviews
• Code analysis sessions
• Talk about code when you give advice
• Talk about code when you take a
break – be creative

56. TALK ABOUT CODE
• Talk about your experience with the
code
• This made me expect that…
• From this I understood right away
that…
• This was misleading/ did not follow
the standard/ was too long / short

57. DON’T
TALK ABOUT CODE
When you cannot understand it

58. USE TOOLING
• To measure (size, relations complexity
etc.) – do not count lines
• To enforce quality standards and
conventions
• To boost productivity
• To avoid human errors

59. MAKE SURE
EVERYONE
READS
CODE COMPLETE

60. PART THREE
Trade secrets

61. CULTURE CLASH
SW Business and SW craftsmanship
are not the same

62. THINGS ARE IMPROVING
• Human factor weighs in
• AGILE – development as a partnership
• Costs and benefits of quality are better
understood
• SW management is more experienced

63. STILL, THIS
Is sometimes applicable to the quality
of your code

64. USE YOUR BRAIN
• Say what you think
• Stick to your estimates
• Accept lower quality
as a legitimate
business decision
• Pick your battles
• Keep doing what you love
in acceptable conditions

65. KEEP CALM !!!

66. THANK YOU,

67. 972-54-8003775
Asher . Barak @ gmail . com
CONNECT WITH ME

68. GET THE SLIDES
http://goo.gl/AWWUKf
If you want to reuse
the slides for your
talk, Please contact
me first.