The document discusses what characterizes a professional developer. It argues that professionalism is about using best practices and disciplines, such as test-driven development, clean code, and continuous learning, even when under pressure. Writing unreadable or defective code is never acceptable for a professional. A professional developer maintains high standards for code quality and chooses best tools and practices for the job.

1. Vad utmärker en professionell
utvecklare?
Joakim Sundén
tisdag, 2009 januari 27

2. JOAKIM
SUNDÉN
tisdag, 2009 januari 27

3. BODEN
tisdag, 2009 januari 27
Born and raised.

4. tisdag, 2009 januari 27
Now I live in Stockholm.

5. Kul
bild
här
tisdag, 2009 januari 27
Work at Avega.

6. tisdag, 2009 januari 27
As a consultant.

7. tisdag, 2009 januari 27
Who are you?

8. tisdag, 2009 januari 27
Ariane 5. Estimated cost of accident: 370 million dollars. Caused by software malfunction,
defect.

9. Foto: Kevlin Henney
tisdag, 2009 januari 27
Cost of defects in US: 60 billion dollars a year.
50% of user software has non-trivial defects.
Does it have to be this way?
Developers introduce 5-8 defects an hour.
There are practices to prevent defects.

10. tisdag, 2009 januari 27
Design by Contract. Bertrand Meyer (1986), Eiel.
Contract as a metaphor to guide design process.
Preconditions and postconditions
What does the method require?
What does the method ensure?
Makes the developer think through the specification.

11. tisdag, 2009 januari 27
Design by Contract. Bertrand Meyer (1986), Eiel.
Contract as a metaphor to guide design process.
Preconditions and postconditions
What does the method require?
What does the method ensure?
Makes the developer think through the specification.

12. Exempel i C#
Kevin McFarlanes Design by Contract Library,
http://www.codeproject.com/KB/cs/designbycontract.aspx
tisdag, 2009 januari 27
Microsoft Research: Code Contract Library, .NET 4.0

13. tisdag, 2009 januari 27
Red-Green-Refactor.
Design technique where the developer has to think through the specification before she
writes code. Executable specification.
Suite of automated regression tests.
Kent Beck.

14. tisdag, 2009 januari 27
Red-Green-Refactor.
Design technique where the developer has to think through the specification before she
writes code. Executable specification.
Suite of automated regression tests.
Kent Beck.

15. tisdag, 2009 januari 27
Code inspections, also Fagan inspections.
Michael Fagan, IBM, 70s.
Defect discovery rate 60-70%

16. tisdag, 2009 januari 27
Code inspections, also Fagan inspections.
Michael Fagan, IBM, 70s.
Defect discovery rate 60-70%

17. http://en.wikipedia.org/wiki/Fagan_inspection
tisdag, 2009 januari 27
Formal process, focus on finding defects.
Checklists with known problems.
Specific roles: moderator, reviewer, scribe
150-200 lines of code per hour.
Up to 70-85% if combined with design inspections.

18. tisdag, 2009 januari 27
Other practices
Pair programming
Some studies point to eficiency close to code inspections.

19. tisdag, 2009 januari 27
Clean-room engineering
Semiconductor manufacturers ”clean rooms”. Code verified against formal methods.

20. tisdag, 2009 januari 27
Prototyping

21. tisdag, 2009 januari 27
Steer you away from complexity, makes you think about code and design, not programming
by coincidence.

22. tisdag, 2009 januari 27
Why do we note use them?
60-75% of projects have no unit tests.
40% does not use source control.

23. tisdag, 2009 januari 27
Maybe we finally get it right and with few defects.
Does it matter how or why it works?
Is it up to the individual developer how to solve the task? How to code?

24. #include stdio.h
main(t,_,a)char *a;{return!0t?t3?main(-79,-13,a
+main(-87,1-_, main(-86,0,a+1)+a)):1,t_?main(t
+1,_,a):3,main(-94,-27+t,a)t==2?_13? main(2,_
+1,quot;%s %d %dnquot;):9:16:t0?t-72?main(_,t, quot;@n'+,#'/
*{}w+/w#cdnr/+,{}r/*de}+,/*{*+,/w{%+,/w#q#n+,/#{l+,/
n{n+,/+#n+,/# ;#q#n+,/+k#;*+,/'r :'d*'3,}{w+K
w'K:'+}e#';dq#'l q#'+d'K#!/
+k#;q#'r}eKK#}w'r}eKK{nl]'/#;#q#n'){)#}w'){){nl]'/
+#n';d}rw' i;# ){nl]!/n{n#'; r{#w'r nc{nl]'/#{l,+'K
{rw' iK{;[{nl]'/w#q#n'wk nw' iwk{KK{nl]!/w{%'l##w#'
i; :{nl]'/*{q#'ld;r'}{nlwb!/*de}'c ;;{nl'-{}rw]'/
+,}##'*}#nc,',#nw]'/+kd'+e}+;#'rdq#w! nr'/ ') }+}
{rl#'{n' ')# }'+}##(!!/quot;) :t-50?_==*a?
putchar(31[a]):main(-65,_,a+1):main((*a=='/')+t,_,a
+1) :0t?main(2,2,quot;%squot;):*a=='/'||main(0,main(-61,*a,
quot;!ek;dc i@bK'(q)-[w]*%n+r3#l,{}:nuwloca-
O;m .vpbks,fxntdCeghiryquot;),a+1);}
tisdag, 2009 januari 27
C program. What does it do?

25. tisdag, 2009 januari 27
Complete lyrics of Christmas carol “Twelve Days of Christmas”.
Is this okay?
The code can be found on the Swedish wiki ”Susning” under the term ”ugly-code”.

26. ful|kod s. en blandning av
redundant kod och ad-hoc-kod
och gärna i ostrukturerad och
helt oläslig form
http://susning.nu/Fulkod
tisdag, 2009 januari 27
”Ugly-code (noun) A mix of redundant code and ad hoc code, often unstructured and totally
unreadable...”
Why do we write this kind of bad code?

27. tisdag, 2009 januari 27
Bad code slows you down.
We read and try to understand code more than we write it.

28. tisdag, 2009 januari 27
Broken window theory.
Bad code attracts more bad code.
”No one else seem to care, why should I?”

29. tisdag, 2009 januari 27
Bad code is hard to maintain. Easier to introduce defects.

30. tisdag, 2009 januari 27
We know that we should be writing clean code.
We know of practices to prevent defects.
So why don’t we do it?

31. tisdag, 2009 januari 27
Ignorance?
It can be dificult, but is it too dificult? Than maybe programming is too dificult altogether?
Even developers who know how to do it, don’t always do it. Why?

32. tisdag, 2009 januari 27
Don’t have the time?
I’ll do it later... which often means never.
Is being in a hurry an acceptable reason to write bad code?
What if you were a physician and the patient demanded that you did not wash your hands
because he was in a hurry?
What if an accountant would skip double entry bookkeeping in order to make a deadline?

33. tisdag, 2009 januari 27
Someone else is to blame?
Stupid managers with unreasonable deadlines or sudden requirement changes? It is your job
to make them understand why bad code is a bad thing.

34. tisdag, 2009 januari 27
A line must be drawn: not all ways of producing code are equally good. We need to define our
profession.
What sets us apart from anyone with a computer and a compiler/interpreter? We need
guidelines and practices to define our profession.

35. pro|fess|ion|ell adj. -t -a
som utförs på ett fackmässigt
godtagbart sätt
Norstedts Ordbok, 2:a uppl 1988
tisdag, 2009 januari 27
”Professional: that which is done in a
We need a common perception of what it means that something is professionally executed.
Sloppiness and excuses like ignorance and too tight deadlines are plausible only in the
context of a wider tolerance of shoddy work.
What does it mean to be professional?

36. tisdag, 2009 januari 27
Is it about choosing particular tools?

37. tisdag, 2009 januari 27

38. tisdag, 2009 januari 27
No, professionalism is not about tools or languages, no matter what some seem to want us to
think.

39. tisdag, 2009 januari 27
It’s about attitude and mindset.
It’s about the disciplined use of practices even when in a crisis.
There are no universal best practices, you use the ones that work for a given context and use
them in disciplined manner. There are however a number of practices that have proven to be
succesful in a lot of situations and circumstances.

40. tisdag, 2009 januari 27
Don’t write bad code! Just don’t do it. Refuse!

41. tisdag, 2009 januari 27
Write good clean code instead. Simple huh?

42. tisdag, 2009 januari 27
Good clean code is in short about maintainable code that is easy to evolve and modify.
There are design principles that will help you produce maintainable code.

43. DRY
tisdag, 2009 januari 27
One of the most important ones.

44. Don’t Repeat Yourself
tisdag, 2009 januari 27
Don’t Repeat Yourself.
”I often find that a nice design can come from just being really anal about getting rid of
duplicated code” - Martin Fowler

45. Single Responsibility Principle
Open Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
tisdag, 2009 januari 27
Robert C. Martins SOLID design principles.

46. tisdag, 2009 januari 27
Test-Driven Development.
More than unit tests. Forces you to write lots of tests, forces your code to be more testable,
i.e., easier to test. It is a design technique that supports good design principles: avoid
dependencies, decompose classes and methods, program to abstraction rather than
implementation etc.
TDD can also be extended to automated acceptance testing.

47. tisdag, 2009 januari 27
No bugs! If you find one, write an automated test for it and do root cause analysis to avoid
future bugs of the same kind.
Studies have shown that pair-programming and TDD can eliminate up to 90-97% of defects.

48. tisdag, 2009 januari 27
What to do with bad code and no tests? Throw away? Grand redesign? Sometimes, but often
we choose this because the alternative seems so dificult...

49. tisdag, 2009 januari 27
...to admit you have a mess and clean it up. Always leave the code a little better than you
found it. We often do the opposite and that’s not professional!

50. tisdag, 2009 januari 27
Never be blocked (”The Prime Directive” according to Robert C. Martin.)
E.g., don’t sit and wait for requirements - find out yourself or start to define them yourself;
don’t wait for the code to integrate with - help out by specifying an interface and use a stub/
mock.
Use tools and processes such as multiple check-out source control and continuous
integration.

51. tisdag, 2009 januari 27
Use the right tool for the right job, not just the same old tool you happen to know.

52. tisdag, 2009 januari 27
”When all you’ve got is a hammer, everything looks like a thumb.”

53. tisdag, 2009 januari 27
If you only have one tool it is easy to only see the same solution all the time.

54. http://altdotnet.se/
tisdag, 2009 januari 27
ALT.NET questions the Microsoft orthodoxy and actively tries to find the best tools and
practices, no matter what community they come from: Open Source, agile, Java, Ruby, etc.

55. tisdag, 2009 januari 27
Pair programming can be as eficient as code inspections when it comes to defect prevention.
Compared to inspections pair programming seem to be easier to pick up and persevere with,
maybe because of the disruptive nature of inspections.
Defects are discovered and corrected immediately.
Positive peer pressure to be disciplined, write tests etc.
Transfers knowledge - technical and domain - between team members.
Good for team spirit.

56. tisdag, 2009 januari 27
Continuous improvement and learning
You need to keep up if you want to be a professional.
Read books, blogs and code. Not just new stu, but the collective experience of our industry,
such as design principles, methods, problem solving.
Go to conferences, seminars, workshops.
Become a member of a user group or similar where you can meet other professionals.

57. tisdag, 2009 januari 27
What to do if not in a professional organisation?

58. tisdag, 2009 januari 27
Why bother at all?
Many don’t. Guess it’s okay if this is something you do to earn some money while waiting for
something else, but that can never be an excuse not to do a good job.
If you’ve chosen this as a career, life is too short to be dedicated to shoddy work. Quality is
not just an economic factor, people need to do work they can be proud of.

59. tisdag, 2009 januari 27
Change always start with yourself.
No matter how dysfunctional your organisation might be, you can always change your
behaviour. You can decide to stop writing bad code or start doing TDD.

60. tisdag, 2009 januari 27
By being a role model you can inspire others to follow.
If that fails...

61. tisdag, 2009 januari 27
...you can always take Martin Fowlers advice: “If you can't change your organisation, change
your organisation!”

62. joakim.sunden@avega.se
www.joakimsunden.com
tisdag, 2009 januari 27