Professionalism

Vad utmärker en professionell utvecklare?

Joakim Sundéntisdag, 2009 januari 27

JOAKIMSUNDÉN

tisdag, 2009 januari 27

BODEN


Born and raised.


Now I live in Stockholm.

Kul bild här


Work at Avega.


As a consultant.


Who are you?


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

Foto: Kevlin Henneytisdag, 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.


Design by Contract. Bertrand Meyer (1986), Eiffel.

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.

Exempel i C#

Kevin McFarlanes Design by Contract Library,http://www.codeproject.com/KB/cs/designbycontract.aspx


Microsoft Research: Code Contract Library, .NET 4.0

http://www.codeproject.com/KB/cs/designbycontract.aspx

http://www.codeproject.com/KB/cs/designbycontract.aspx


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.


Code inspections, also Fagan inspections.Michael Fagan, IBM, 70s.

Defect discovery rate 60-70%

http://en.wikipedia.org/wiki/Fagan_inspection


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.




Other practices

Pair programmingSome studies point to efficiency close to code inspections.


Clean-room engineeringSemiconductor manufacturers ”clean rooms”. Code verified against formal methods.


Prototyping


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


Why do we note use them?

60-75% of projects have no unit tests.

40% does not use source control.


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?

#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,"%s %d %d\n"):9:16:t<0?t<-72?main(_,t, "@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' ')# }'+}##(!!/") :t<-50?_==*a?putchar(31[a]):main(-65,_,a+1):main((*a=='/')+t,_,a+1) :0<t?main(2,2,"%s"):*a=='/'||main(0,main(-61,*a, "!ek;dc i@bK'(q)-[w]*%n+r3#l,{}:\nuwloca-O;m .vpbks,fxntdCeghiry"),a+1);}


C program. What does it do?


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


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




Bad code slows you down.

We read and try to understand code more than we write it.


Broken window theory.

Bad code attracts more bad code.

”No one else seem to care, why should I?”


Bad code is hard to maintain. Easier to introduce defects.


We know that we should be writing clean code.We know of practices to prevent defects.

So why don’t we do it?


Ignorance?It can be difficult, but is it too difficult? Than maybe programming is too difficult altogether?

Even developers who know how to do it, don’t always do it. Why?


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?


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.


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.

Norstedts Ordbok, 2:a uppl 1988

pro|fess|ion|ell adj. -t -a som utförs på ett fackmässigt godtagbart sätt


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


Is it about choosing particular tools?


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


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.


Don’t write bad code! Just don’t do it. Refuse!


Write good clean code instead. Simple huh?


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


One of the most important ones.

Don’t Repeat Yourself


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

Single Responsibility Principle

Open Closed Principle

Liskov Substitution Principle

Interface Segregation Principle

Dependency Inversion Principletisdag, 2009 januari 27

Robert C. Martins SOLID design principles.


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.


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.


What to do with bad code and no tests? Throw away? Grand redesign? Sometimes, but often we choose this because the alternative seems so difficult...


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


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.


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


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


If you only have one tool it is easy to only see the same solution all the time.

http://altdotnet.se/


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.

http://www.altdotnet.se

http://www.altdotnet.se


Pair programming can be as efficient 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.


Continuous improvement and learningYou need to keep up if you want to be a professional.

Read books, blogs and code. Not just new stuff, 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.


What to do if not in a professional organisation?


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.


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.


By being a role model you can inspire others to follow.

If that fails...


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

[email protected]


mailto:[email protected]

mailto:[email protected]

http://blogg.joakimsunden.se

http://blogg.joakimsunden.se

Professionalism

Travel

Transcript of Professionalism