Vad utmärker en professionell utvecklare?

Joakim Sundéntisdag, 2009 januari 27

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

tisdag, 2009 januari 27

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.

tisdag, 2009 januari 27

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

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 specification before she writes code. Executable specification.

Suite of automated regression tests.

Kent Beck.

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.

tisdag, 2009 januari 27

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

Defect discovery rate 60-70%

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

tisdag, 2009 januari 27

Other practices

Pair programmingSome studies point to efficiency close to code inspections.

tisdag, 2009 januari 27

Clean-room engineeringSemiconductor manufacturers ”clean rooms”. Code verified 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 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);}

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

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

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

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

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

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

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

tisdag, 2009 januari 27

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.

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.sewww.joakimsunden.com

tisdag, 2009 januari 27