thank you very much for it
view this often after two days hard work with calls were software and nothing
it's my pleasure so I'm Martin to me we prepared them questions and luckily our
questions went quite well together don't good so we several fields first one it's
not very surprising what we are
husky is about craftsmanship about professionalism quality metrics
interaction with management to questions in the end more general if we still are
having leaders ok I'm so I think and mark should start
ok the first questions press how would you define software cross mature what's
it mean for you
how do i define software craftsmanship so i'm i'm in midst of this dilemma
because i want to bring the notion of software professionalism and software
craftsmanship together in a craft craftsmanship seems to have something to
do with how well you perform your craft and professionalism is more the
relationship to others that you have so there's this mix between the two
software craftsmanship is really all about taking this profession that that
we have this job that we have and turning it into a real profession
turning it into something that professionals do it's about defining the
sets of disciplines and the minimum standard of behavior for someone who
claims to be a professional software developer and that includes how well
they perform their programming how well their code looks and also how well they
do their job in terms of estimating and communicating the managers and
communicating the other software developers imagines that
it's 300 years ago and we were talking about the medical profession and there
would be practitioners all around who would be willing to pull out your tooth
or willing to cure your aches and pains with whatever and a few people looked
around and said no there's got to be some way to raise the level here that's
what software craftsmanship means to me it's a way to raise the level to create
a group of software developers that employers and governments can trust
so to you it means more than just writing code it's part of writing clean
code but it's much more than that because our civilization is is heavily
dependent on software if you look around the room here there is software running
within just about every square foot of this room there's software in this
microphone software in that remote control that clock there's probably run
by software the camera that's filming this is run by software there is
software in everything
how many times per day do you put your life in the hands of some
twenty-two-year-old programmer at who wrote some code at three in the morning
and the answer to that is too often and at some point in the near future
there's going to be an accident and thousands of people will be killed
because of some piece of software written by somebody who got a little too
careless i would like to not prevent that from happening I don't know that
it's possible to prevent it but when it happens and when the governments of the
world rise up and say my god what what's happening how is that happened I would
like the software profession to be there saying but we did our job well this is
not because we've been sloppy and
see this is not because we are unprofessional
we have been doing our job well that's what I would like to have happen today I
couldn't say that
ok so just to start this out on a pleasant note sorry if I overloaded your
microphone there do you think that's one thing itself across them to do or
someone wants to become soft across with the most important thing
well the most important thing to do is first of all make sure you're in the
right job
there's a lot of people who are in software right now that just shouldn't
be because they consider it to be a job and not a profession when you go to a
doctor you want that dr. to love what he does or do you want them to think of it
as a job that I just do it
it pays the bills you want a doctor to be in love with this profession you want
a lawyer if you don't know your freedom is going to depend on a lawyer you want
that lawyer to be in love with this profession if you're going to commit a
massive project to software developers you want those software developers to be
in love with their profession so the first thing is to decide whether you're
in love with your profession if you're not find one that you are in love with
and don't be in this one second thing to do is to learn like crazy read as much
as you can
there we now have 50 years of experience in software that's not a lot almost in
most professions have centuries at this point we have five decades but within
those five decades there have been notable professionals who have written
about their job people like Tom DeMarco and add your heads good dykes drawn and
a whole realm of these people and you can read their works and understand what
they thought professionalism is learn the languages
of the past if your Java programmer my god learned some other language because
Java is not the end of this story and it's not the beginning of the story it's
just a little tiny brief segment and it's going to move onto something else
relatively soon find other languages learn those other languages communicate
with other programmers that's very difficult for programmers to do that
programmers you know we got into this business because we like people but it's
important for us to communicate with others to practice together to become a
community of practice and a community of professionals when they came here
yesterday morning i discovered made a list of and asking people how long their
bar coding yes life
yes so you're talking about falling in love with your job
yes and I have seen a lot of very many people you know who we're in love more
than 10 years so what the interesting cat question was for me
why does this need to become more perfect or better in love or more
addicted to it in burg is rising so late
wipe them younger people try to get better coding people
well I think there's I think there's always been a subgroup of programmers
who were in love with their in love it
ji it was a passion that struck them early in life and knew they knew what
they wanted to do
by the time they were 16 as I pulled the group out here most of the group started
writing code well before they went to college
many of them were pre teenagers as they started writing code they touched one of
their fathers computers or where they found some interesting device and they
realized they could program and they fell in love with it
there's a whole group of programmers who got into the profession because
it was the smart thing to do it was the the the profession of the future and
they never had the the passion for it
some of them i think can develop that passion I think that's alright but there
are many who view it as for years and then i'm off into management and that's
not helpful to the profession I don't think we want to encourage that kind of
participant but i think the people we need in our industry of the ones who who
are you find that passion early and nurture the passion and and and want to
stay programmers I don't know how things are in germany in the United States we
face a lot of pressure to move into management management if you're a
software developer for three or four years
well it's time for you two to leverage up and start running a group or
something like that
find that very unfortunate we do need good managers that's fine but software
developers typically don't have that skill don't want that skill and and they
feel the pressure to move in that direction
many of them do and many of them fail and then they maybe they will pursue
some career often marketing or sales or something and lose their original
passion for what they were doing
I've certainly face that several times and I've i have have been a programmer
then I run a group and then I went back to being a programmer and then he ran a
division and then I went back to being a programmer and then I ran a company and
i gave that up and remove them a programmer and now i'm a programmer who
does a lot of speaking and talking and I'm very happy with that so some people
don't have that love that was the question you asked me because they got
into it for the wrong reasons some of them
develop the love because they find out it's it's very good to be a programmer
it's one and some of them lose the love and they lose it because they find
themselves in an environment that crushes that love out of them there it's
an environment where they are driven by deadlines and driven by pressure and
they have to work overtime and and after a while they ask themselves why did I
get into this horrible situation and they go and become a chicken farmer well
you think that's professionalism this potential you think they can be software
high-quality for example without such as we have to
yes there can be software of high quality without that attitude that's
perfectly possible but is it essential it's absolutely essential because
although there can be software high-quality most of the software out
there is not most of the software out there is in fact of dismal quality and
as I wonder my more the way through the industry and i look at the the code
that's out there
the vast majority of it is terrible and that's very unfortunate our customers do
not have the capability of looking under the hood of the car
opening up the hood of the car looking at the engine and seeing that it's a
good engine they can't do that they have to trust us and we tell them the codes
working it's fine don't worry about it if if if our customers ever developed
the skill to look under the hood they'd be terrified in what they saw and they
realize they spent a lot of money for very rickety very fragile software that
has a great propensity to harm them that needs to change
so that's where professionalism comes in who is going to police the software
developers
and I wanted to be the software developers who police the software
developers just like the doctors police the doctors and the lawyers police the
lawyers it should be the software developers who set their own standards
and then and then keep them and right now we're not doing that something
what are you from managers is that clean colleges too expensive for kind of the
form of writing tests the cover like all the code that's it just do it i would
have responded chick
hey if I don't have to make the code work i can make it as cheap as you'd
like and deliver it on any schedule you want as long as it doesn't have to work
and actually it's not manager saying that oh you might find some low-level
manager saying stuff like that but you talk to the CEO of a company you ask
that CEO you thought years you want your software to be high quality and he's
going to walk it already was of course I wanted to be high-quality i'm betting my
business on it i'm running my business
imagine the company was running their payroll or their their invoicing or
something critical to the business on software that their software developers
are producing and ask the ask the CFO if he wants high-quality software that
doesn't make any mistake
damn right I do alright so the little manager off in the corner who's worried
about the schedule is going to say something silly about like oh we we
don't really have time to write tests course you've got time to test you don't
have time not to write tests how much debugging do you want to do how much
chasing down horrible invoices you want to or correcting corrupted databases do
you want to do course you have time to write tests and if you were to talk
upwards up to the managers above image with you mean they're not writing deaths
mean there any tests
what kind of professionals are these the people who complain most about not
having time are the program's themselves and and they do that because they're
afraid that their managers will say you don't have time to write tests they're
afraid that their managers will say you don't have time to clean code they have
cause to be a four
because they've been put under a lot of pressure to deliver and they've been put
under a lot of pressure to deliver because they haven't delivered
they have made estimates and they've missed them there's a huge amount of
distrust right now between the the software management and companies and
the developers themselves and that is directly because of a lack of
professionalism it's because of software developers bowing to schedules that they
should have said no I can't meet that schedule we have to come up with another
one it's because managers would manipulate low level managers would
manipulate developers into committing to things they knew they should not commit
to and the developers were two unprofessional to stand up and say no
we're not going to do that they wind up under pressure they wind up failing and
then this distrust grows and it's it's a terrible thing
developers need to learn that one of the marks of professionalism is that they be
able to say no a professional says no a professional is hired for the purpose of
saying no and then also offering what else they should do developers need to
learn how to say no developers need to learn how to define their boundaries
learn how to make their commitments learning when not to make commitments so
that the business can begin to trust them government expression except
because i've read the very interesting with dialogues in your new
between my god Peter oh yes about animation and commitment which is
exactly what you were describing their and everything that I can understand i'm
not a developer i can't understand why I should promise something where I don't
know what I'm promising I just promised things where I'm sure that i can deliver
so you said an interesting word is a distrust why the distrust is such an
important of obstacle in this kind of this field work would distrust is always
an obstacle in any kind of work if you don't trust you talk to your going to
get another doctor and if you don't trust your lawyer gonna get another
lawyer
unfortunately the business is locked into a bunch of developers that
generally the business doesn't trust and so they they try to find ways to
manipulate the developers in spite of this distrust so they will set deadlines
and and put massive amounts of pressure on developers to meet those deadlines
because they believe that's the only way they can get get anything done they will
attempt to manipulate or put pressure on developers to commit to things because
they believe that's the only way they can motivate the developers to actually
get things done when they say they'll get done and that all companies do this
and maybe not even most companies do it all the time but most developers have
been through that experience when there is trust something very different
happens management goes to development and says we need this by next $MONTH
november development says that's not going to happen
management says well what else can you do
developers layout what they believe they can do management chooses amongst those
options and everybody goes away knowing that
that's the best they can do in the midst of that there might be some heated
discussion managers might say you don't understand you know there's a customer
out here that we're going to lose if we don't deliver and the developers have to
have the courage to say I do understand you're gonna lose that customer because
we cannot deliver this and then the business goes oh and they trust the
developers who said that and they say alright we're going to have to work on
that customer instead of trying to push the developers to do the impossible and
then losing the customer anyway out of out of a failed failed expectations we
jumped over the quality metrics that whole different person
yes around and around and then I don't Google that it's okay so the common
issue of the magazine we doing this until you fall it's about quality
general Catanzaro yeah when it comes to quality many people transfer methods to
measure the quality you think that's worthwhile doing
does that help there are some reasonable metrics to measure the quality of
software in the internal quality of software is there's metrics like
cyclomatic complexity and and lines / method and so on and and they're useful
these are not management metrics I don't want managers looking at reports about
cyclomatic complexity that's nonsense
I don't want managers looking at reports about code coverage and test coverage
that's also nonsense
these are metrics that we as developers should use to police ourselves where
does quality really come from quality comes from developers writing good
software using goodra
requirements writing good tests making sure those tests pass and developing a
discipline to never rush in order to meet the deadline you rush to meet the
deadline you're going to go slower you're going to create lots of bugs
it's gonna make a mess so you develop a discipline never rush lots of companies
will create departments quality assurance departments QA apartment
departments they have done this
excuse me
they have done this out of defence as a defensive mechanism because the
development community is not done their job developers produce products that
have bugs and then the business decides out while we need a whole new department
to make sure that developers don't produce bugs they create a QA group QA
groups actually do have a good function but we use them the wrong way we take
the q a group and we put it at the end of the project we say okay
QA people now you're going to test this code that the developers wrote why did
the developers test that code with developers wrote it they're the ones who
want to test it
why do we have to hire another group of people to test the code that the that
the developers wrote and and then what are these QA people doing
are they manually testing the software are they actually touching keyboards and
looking at screens and making sure the software behaves correctly
how many times do they have to do that every year they have to repeat the same
set of tests every six weeks to make sure that the software is still working
the way it was supposed to
what a job that would be honest what a horrific job every six weeks I'm going
to do the same thing i'm going to log into the system the same way i'm going
to test it the same way
and my mind will turn into the modulus honey because i can't see it anymore
that's the wrong thing to do with people imagine a group of developers who
deliver late that like that would ever happen and the date can't change so what
group has to make up the difference
the QA group has to make up the difference they're the ones who have to
now execute their tests much faster than they would have before and now they're
put in the position of having to choose which tests to run in which does not to
run which ones are too expensive and they're under pressure and there is a
high-stress tedious job and so their approach just exactly the wrong thing
you wanted the back into the process what we want to do there is automate all
these tests
most of these tests should be automated and they should be run by the developers
developers should write the code they should run the tests if the test pass
then QA is already signed off i want QA writing those tests i want QA writing
the acceptance tests that the developers have to pass i want the developers
executing those tests automatically so they can push a button and know that
they're done with what they were supposed to do so do you think there's a
place for manual testing of course but not scripted manual testing is very
important I want someone with their eyes on the screen and their fingers on the
keyboard but I want their brain engaged i want them thinking about interesting
and and clever ways to break the system i want them going to bed at night
strategizing how they're going to destroy the system what interesting
sequence of inputs will confound and break it i want the the QA people to be
applying massive amounts of creative energy to find out ways to break the
system that the software developers never thought of that's where QA people
have real value on the backend and their value on the front end is that they're
writing the acceptance tests that specify the quality that needs to be put
into the system
this of course is what you a people have been telling us for decades
just now beginning to realize it so you put your right but you a should find
nothing right
yes so you think what they all try to renovate to break the system but you
won't find anything
exactly that's exactly what i want i want a bunch of ny's dreaming every
night about ways to break the system and feeling to break the system when I can't
find any way to do it that's a perfect situation and and of course that won't
happen with what will happen is the QA will find things and then I want the
developers going how the heck did that happen and they would change their
processes in their disciplines to make sure that can happen and then the QA
people have to get even more creative
I want an escalation in creativity over this issue the the developers and the QA
folks should be in a kind of competition development is absolutely certain and
not going to find a bug QA is determined to find a bug that's a very profitable
way of working it's more like an attitude of course it's an attitude yeah
we can get to the general part but it was you Christian
ok so you think there's some what the biggest challenge but the software
industry is facing today will face the next couple of years now what there's a
couple the the biggest challenge is this issue of professionalism we have a huge
deficit of professionalism and that needs to be resolved and we're in a race
over that because at some point as i said earlier there will be an event an
accident of some kind and the governments of the world will get
involved and then they will decide they have to police and that will be bad
that's happened to other industries in the past and it would be very nice if
our industry had achieved a level of professionalism where we could hold back
the laws and the imposition of governments upon us so that's the first
challenge and it's a big one
the second challenge is a technical one and it's it's no less daunting it's a
very interesting challenge our computers have been enjoying a an incredible
increase in power and speed over the last 40 years
Moore's law has said that the processor speed will double every 18 months and
the density of transistors on chips will double every 18 months we have seen that
happen for four decades since 1972 the extent where this machine is probably
twenty two orders of magnitude more powerful then the little computer i
started working on when i was 18 years old PDP eight but around 2000 2001 2002
Moore's law began to fail the speed of computers stopped doubling they've been
stuck now what about two-and-a-half gigahertz for five or six years
and to compensate for that the hardware developers have begun to change the game
they've added multiple cores so this laptop here that i'm working on has four
chords inside it for processors each running it about two-and-a-half
gigahertz what she'd think would mean that there's ten gears in here but no
it's not the way it works because the software is not written to use multiple
cores so we wind up with the inability to spread the execution of the software
across those course come back in a year and I'll have an eight-core laptop come
back here later i will have a 16-core laptop year or two after that I'll have
a 32 core laptop when does that stop
well it's going to stop at some point but probably not before we get to 32 64
maybe a hundred and twenty-eight course the systems that are out there are all
going to be heavily multi cord and our software doesn't deal with that and our
skills are not up to that most often developers think that they live in a
single machine with a single thread and every once in awhile they create another
thread and whatever they have no idea of the complexity of making a system that
can run in a hundred and twenty-eight course so the technical challenge is for
the software community to learn the much more mathematical much more scientific
much more technical skill of building software that can run in a heavily
multiprocessor environment that will become essential there are lots of
strategies out there to prevent software developers from having to learn that
there's a bunch of people who think they can create a framework that will make it
so that programmers can program as usual and the framework will take care of
everything
no they can't lots of people for years and years have tried to make it so that
programmers can be stupid
it is never a good idea for programmers to be
but languages were written so that programmers could be stupid cobol
language written for people who want to write in English instead of code
okay didn't work out all that well the the idea that object oriented design was
too complicated for mere mortals where we don't want
normal programmers to do objects it's just too hard
completely failed everybody's doing objects functional programming is going
to be the next turtle function everybody is going to have to learn how to be a
functional programmer they're going to have to learn the mathematical and
technical skills that will make them a functional programmer so that they can
live in the multi-core world that would be a very interesting time
sounds like yes when you book just started in kota guess the first one is
that on the one before what the King code link 0 new has been the next one
willing to order that the code esta will be the third well hopefully continue the
next book is called clean architecture and design and I'm in the midst of
writing that now and it it it talks about the next level up from clean code
once you know how to write clean functions clean algorithms once you
understand that
how do you create clean architectures and we have a huge problem with that
right now we've got massive amounts of systems being written and the people who
are writing them have no idea how to structure the architecture they have
been subverted by the marketing literature out there so there's this
massive amounts of stuff being done with service-oriented architecture has
nowhere in architecture a service-oriented architecture is going
to solve the architecture problems of the world
no it's not it's an interesting technique the useful in some cases but
it's not
massive big architecture that that's going to solve the world's problems and
lots of people did them three tier architecture for awhile tremendous
amount of architectural experimentation going on the problem with that is that a
lot of a lot of the architectural science was done 30 years ago 20 years
ago we know how to build these systems we've got books that tell us how to
write these systems and yet most of the developers out there just don't know
that I don't know what system architecture ought to look like don't
know what the rules of a system architecture are so this book attempts
to address that and it tries to address it in the same way that clean code and
clean code or did it by being as prescriptive as possible
these books take a different tack most books layout facts and issues and allow
developers to make up their own minds but these these books that i've been
writing become very prescriptive they say do this now i make it clear that
it's my opinion but I'm also telling people okay this is my opinion you
should do this
that puts a different slant on things
I'll just that like to emerge and architects room and things like that
idea of extreme programming but the architectural evolve or eventually so
that's an interesting one and and architecture emerges design emerges but
not without human brains it is not the design that emerges out of nothing
it is the design that emerges out of the activity of a programmer involving their
program forward and while doing so applying design principles that they
have learned all the design principles from the last 40 years to apply they're
all still valid and it's just that the order in which we do them has changed
instead of doing them all up front
and planning some massive software thing we apply those principles sideways we
write a little code we write some tests and then some code and we look at the
structure with there's a principle violated here let's shift a little bit
and we refactor it for that principle and then we write a little more code a
little more tests and we refactor for that principle and we begin to build a
system that starts to look like it needs in architecture and then we start to
build out the pieces of that architecture we evolve it emerges but
not without human thought that without all the principles that have always
existed people get into this religious war about all the agile stuff is about
not planning it's not it's about planning all the time people say wire
the design emerges you're not supposed to use your brain I had a guy last night
last night who said I've been told that I'm not supposed to use my brain I'm not
supposed to think it's absurd course you're supposed to think it's just that
you think get a different time in a slightly different way your next to
impossible architecture you could be could be any more questions
no you would like to have
oh goodness what happened we said to read this magazine that's who reads this
makeup then from four professors software engineers for the reason ok so
here is a message for all the software engineers in the region karlsruhe region
or the region around here there is a discipline you need to learn that
discipline is called test-driven development it has been controversial
for a number of years but the jury is in this is something you need to do
something you need to learn and something you need to practice we are we
are at a point now where in the industry
probably ten percent of developers are beginning to practice test driven
development it will become the definitely definition of professional
behavior one of the disciplines that helps define professional behavior over
the next 10 years
learn it understand it you are going to need it it will be probably the most
important thing for you to learn in the
