Professionalism

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

JOAKIM SUNDÉN tisdag, 2009 januari 27

BODEN tisdag, 2009 januari 27 Born and raised.

tisdag, 2009 januari 27 Now I live in Stockholm.

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

tisdag, 2009 januari 27 As a consultant.

tisdag, 2009 januari 27 Who are you?

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

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.

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 speciﬁcation.

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

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

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

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

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

tisdag, 2009 januari 27 Clean-room engineering Semiconductor manufacturers ”clean rooms”. Code veriﬁed against formal methods.

tisdag, 2009 januari 27 Prototyping

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

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

tisdag, 2009 januari 27 Maybe we ﬁnally 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?

#include <stdio.h> main(t,_,a)char *a;{return!0<t?t<3?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:t<0?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) :0<t?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?

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”.

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?

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

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

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

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?

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?

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?

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.

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

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?

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

tisdag, 2009 januari 27

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

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.

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

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

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.

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

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

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.

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.

tisdag, 2009 januari 27 No bugs! If you ﬁnd 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.

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...

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!

tisdag, 2009 januari 27 Never be blocked (”The Prime Directive” according to Robert C. Martin.) E.g., don’t sit and wait for requirements - ﬁnd out yourself or start to deﬁne 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.

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

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

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

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

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.

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.

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

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.

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.

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

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

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

Professionalism

by Joakim Sundén on Jan 28, 2009

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 5

Statistics

Professionalism — Document Transcript