This presentation is all about software quality and it is specially prepared for the event named "Quality Conscious Day, 2011" organized by Vizrt Bangladesh Ltd. In this presentation, we will learn about quality, we will learn how to measure code quality and finally, we will try to grow our awareness on good quality code.

1. Q U A L I T Y
Learning - Measurement - Awareness

2. Super Heroes…

3. CodeMan
• There is also a super
hero inside you!
• Being as a…
Code Man
• Because you can
CODE!!!
Note: the idea of CodeMan is borrowed from one of my ex-colleagues, Hasan

4. CodeMan has Super Responsibility
But…
Super natural power comes with
Super responsibility!
Because…
Power without control
hardly has any value.

5. Responsibilities of a CodeMan
 Learn how to control power
 Measure the quality of work
 Awareness for quality work

6. What is QUALITY ?
Oxford American Dictionary says -
the standard of something
as measured against other things of a
similar kind.
It is NOT easy to define Quality.
―You may not know how to define it,
but you know it when you see it.‖
- Erik Doernenburg, Head of Technology, ThoughtWorks Europe

7. CodeMan – Story 1
- Manager asks CodeMan to upload his profile picture in Wiki.
- The CodeMan quickly uploads one of his photos.
- Now, imagine the immediate reaction of the manager!!!

8. CodeMan – Story 2
The CodeMan wrote a method and committed it to VCS as soon as he tested it successfully:
Few months later, a critical bug is found in this code.
While going through the code, the second CodeMan hardly gets any idea what this piece of
code block is doing.
And the immediate reaction that pops up in his mind: WTF !!!

9. Measuring Code Quality – WTFs / minute

10. Measuring Code Quality
 It is very important to measure the QUALITY of your CODE.
 If you don’t know whether your code quality is GOOD or BAD,
then you can never improve your code.

11. Why Quality Code ?
Single purpose
Changeability – keeping your code changeable
3 key factors
Readability: only easily readable code can easily be understood and therefore
changed
―Programs MUST be written for people to read, and only incidentally for machines to
execute.‖ - Abelson and Sussman
Simplicity: simple is always easier to change than complicated
Testability: only automatically tested code can be changed without fear of breaking
existing behavior.

12. How to Improve CODE Quality?
How can we improve our CODE
QUALITY?
How can we minimize
the number of WTFs
in our CODE?

13. How to Improve CODE Quality?
1. Code conventions
2. KISS - keeping it stupid simple
3. No RUSH
4. Code reviews
5. Pair programming
6. Automatic build and deployment
7. Incorporating QA process
8. Improve your own quality

14. Code Conventions
 Every programming language has some set of guidelines.
 Things you should strictly follow:
- Naming conventions
- Coding style guidelines
- Exception handling guidelines
- Unit testing principles
- Principles of object oriented design
 Configure your IDE, use necessary plugins. These tools eliminate the need for
reviews focusing on coding style and basic design. They allow us to put our
energy into higher concepts of quality.

15. KISS - Keep it Stupid Simple
Don’t build Rube Goldberg Machines – something complex to do simple things

16. KISS - Keep it Stupid Simple
There are two ways of constructing a software design.
One way is to make it so simple that there are obviously no deficiencies. And
the other way is to make it so complicated that there are no obvious deficiencies
- Sir Charles Antony Richard Hoare AKA Tony Hoare
KISS principles:
1. Split your task into smaller subtasks
2. Break down a complex problem into many smaller and simple problems
3. Keep your methods small, should not more than 30~40 lines
4. Keep your classes small – same methodology as for methods.
Follow OOP principles.
5. Solve the problem first, then code it.

17. Don’t be too clever , No RUSH
 Be not Clever too Clever
Clear, Clear, not
 Don’t code in a Hurry — ‖Haste is Waste‖
 Take your time to read the code and see if it is what you meant
 Take your time to write tests — make sure the code does what
you meant, not what you typed
 Code defensively
Act in haste and repent at leisure…
Code too soon and debug forever…

18. Code Reviews
Periodic inspection of selected parts of the code.
Normally, only critical code should be reviewed extensively
Compare the code at hand with the clean code guidelines and other quality goals.
Everyone writes bad code from time to time, but having code reviews eliminates a lot
of it.
 Always try to be nice to your colleagues, and never think that you know better.
Be humble since it's actually easy to be wrong about stuff. :-)
 Constructively propose changes.
Say positive things, what you really like.
Instead of ―that’s lousy long method‖ say, ―why don’t you split that method...‖
Code reviews doesn't only eliminate poor code written by team members (and
yourself), but is a great way to learn new things from each other.
Tools: Crucible, Sonar etc.

19. Code Reviews - Crucible

20. Code Reviews - Sonar

21. Pair Programming
 Pair programming is a key practice to quality.
 Advantages:
1. The code is already reviewed by a second developer.
2. The code is built with the combined technical excellence of two developers. This
includes the advantages that it is more likely that alternatives are discussed and a
better solution results than in the case of a single developer working on the task.
3. Know-how is transferred between the pairing developers. Know-how about the
problem domain, technical excellence and even tool usage is shared

22. Continuous Build and Deployment
Early build and deploy => Early discover bugs => Early Fix
Whenever a developer commits/checks-in code into the VCS, the
continuous integration server starts checking the code.
A typical scenario consists of
1. building the source code,
2. running all automated unit and acceptance tests,
3. checking coding guidelines automatically as far as possible
4. creating an installer package
5. finally deploying the installer package of the application on a test
system for additional manual testing.

23. Incorporating the QA process
Traditional software development process:
1) finish most of the developments first
2) then QA engineers start testing
But this doesn’t work:
1) QA engineers doesn’t get enough time
2) software is released with lots of untested
functionality
What actually works:
1) Incorporate QA process with
development
2) QA process starts as soon as a very small
functionality implemented.

24. Improve your own Quality
 Improve yourself first.
 Minimize the number of bugs.
 well, this a not a critical bug.
I can fix it within few minutes.
 Ask 3 questions before fixing
your bug:
1. Have I made this error
anywhere else?
2. What happens when I fix the
bug?
3. How can I change my ways to
make this kind of bug
impossible?

25. 3 Simple Tips
QUALITY should be possessed in your MIND,
not only in your CODE.
QUALITY has to be possessed in your MIND,
not only in your CODE.
QUALITY must be possessed in your MIND,
not only in your CODE.

26. THANK YOU
Ferdous Mahmud Shaon
Senior Consultant,
Professional Services, Vizrt
Email: fmshaon@vizrt.com
twitter: @fmshaon