CF Summit Notes: Software Craftsmanship, Kev McCabe
October 17, 2014
Software Craftsmanship
Kev McCabe
Agile development
"we adopted Agile and now things will be ok"
...and the Agile transformation began
People really started to think about "how quickly can we get stuff done?"
The Agile Hangover
the PROCESS is perfect but we've lost our technical expertise
Many agile projects are now, steadily and iteratively producing MEDIOCRE software
We want to get things done but we're under pressure
"I haven't got time for this"
Nobody wakes up and says "today i'm going to write some really horrible code"
If we spend the extra 15 minutes fixing that item instead of marking it as 'TODO' it makes the software that much better, and takes less time than it will to fix months from now.
QA shouldn't find any bugs. QA finding 1000 bugs is a BAD thing.
You should be ashamed if QA finds bugs.
Developer: Every time you use my software you break it.
QA: How can I break it, if it was already BROKEN?
Agile doesn't SOLVE problems, it EXPOSES them.
Want to add these 'short feedback loops'
Agile Retrospectives
every week or so cover:
what went well
what didn't
what can we improve?
Don't change 10 things at once. Change ONE. Changing a lot at one time upsets people.
Concentrate on your testing infrastructure
The invisible threat of Technical Debt
as the code quality goes down, it takes longer to put a new feature in
Software Craftsman Manifesto:
not only working software, but also well crafted software
not only responding to change but also steadily adding value
not only individuals and interactions, but also a community of professionals
not only customer collaboration but also productive partnerships
you're not just employees, shouldn't "just do what your told"
you are a stakeholder in every project you work on
At the end of the day, it's OUR career.
Software Craftsmanship is all about putting responsibility, professionalism, pragmatism and pride back into software development
We're all on a long journey with what we're doing
How do we know we're building the right thing? And how do we know we're building the thing RIGHT?
"Apparently we have no time to write tests but we have plenty of time to fix bugs."
"You don't know my boss/company/codebase"
-- we're ALL writing software. There is NO difference
Adding value thru practice
-automated testing
-test first
(if you're in a lean startup this stuff doesn't work)
-Test Driven Development
-Pair programming -- an extra set of eyes to make sure you're going in the right direction
-Continuous integration (that "quick feedback loop" idea again).
Mob programming
put EVERYone in a room, 1 guy on the keyboard. write the software together at once. no meetings, no emails, nobody left out of the loop. can get software done much faster this way. But use it sparingly.
Mastering the practice is hard, and that's why we practice.
Don't be upset about deleting code.
When you wrote that code you LEARNED something about that system.
Even if your code is deleted, you still learned that "thing" and can provide expertise info to the team.
Software Craftsman Attitude:
owning your career
NOT a 9 to 5 profession
practice
boy scout rule
expecting promotions
Keep Learning --
Learn stuff all the time
small and often
You don't want to be out of work AND having a large learning curve
learning is remembering what's important
Seniority is subjective and transient
if they've "done 10 years" but it was the SAME all 10 years, it's not really 10 DIFFERENT years of experience
People liquidity --
Assign your less experienced people FIRST
stop -
being miserable and negative
spreading your frustrations
if you don't like your job, leave
The only way to have people buying into what you believe is if they see you happy.
If a company doesn't want to invest in their team of craftsmen, well, then good luck to them!
Clean Code --
meaningful names
short functions
-single responsibility principal
-minimal arguments
show intent
-don't have an IF statement that has 15 && op's. Take that OUT and put it in its own function
-no need for comments
-your thesaurus is your field ("staff list" might be clearer named "employees")
formatting
unit testing
Code layout matters
make it easy to read and scan
Book: The Elements of Programming Style
by Kernighan and Richie
a list of software development rules that are all still valid
books --
The Software Craftsman
by Sandro
Clean Code - a Handbook of Agile Software Craftsmanship
by Robert Martin
Extreme Programming Explained
by Kent Beck
Working Effectively With Legacy Code
by Michael Feathers
cfml-craftsmanship.com
2 online video discussions a month
1 is US centric
2nd Tuesday 3pm PST
1 is Euro centric
4th Thursday 9am PDT
"the only stupid question is the one you don't ask"
http://bigmadkev.com/resources
Kev McCabe
Agile development
"we adopted Agile and now things will be ok"
...and the Agile transformation began
People really started to think about "how quickly can we get stuff done?"
The Agile Hangover
the PROCESS is perfect but we've lost our technical expertise
Many agile projects are now, steadily and iteratively producing MEDIOCRE software
We want to get things done but we're under pressure
"I haven't got time for this"
Nobody wakes up and says "today i'm going to write some really horrible code"
If we spend the extra 15 minutes fixing that item instead of marking it as 'TODO' it makes the software that much better, and takes less time than it will to fix months from now.
QA shouldn't find any bugs. QA finding 1000 bugs is a BAD thing.
You should be ashamed if QA finds bugs.
Developer: Every time you use my software you break it.
QA: How can I break it, if it was already BROKEN?
Agile doesn't SOLVE problems, it EXPOSES them.
Want to add these 'short feedback loops'
Agile Retrospectives
every week or so cover:
what went well
what didn't
what can we improve?
Don't change 10 things at once. Change ONE. Changing a lot at one time upsets people.
Concentrate on your testing infrastructure
The invisible threat of Technical Debt
as the code quality goes down, it takes longer to put a new feature in
Software Craftsman Manifesto:
not only working software, but also well crafted software
not only responding to change but also steadily adding value
not only individuals and interactions, but also a community of professionals
not only customer collaboration but also productive partnerships
you're not just employees, shouldn't "just do what your told"
you are a stakeholder in every project you work on
At the end of the day, it's OUR career.
Software Craftsmanship is all about putting responsibility, professionalism, pragmatism and pride back into software development
We're all on a long journey with what we're doing
How do we know we're building the right thing? And how do we know we're building the thing RIGHT?
"Apparently we have no time to write tests but we have plenty of time to fix bugs."
"You don't know my boss/company/codebase"
-- we're ALL writing software. There is NO difference
Adding value thru practice
-automated testing
-test first
(if you're in a lean startup this stuff doesn't work)
-Test Driven Development
-Pair programming -- an extra set of eyes to make sure you're going in the right direction
-Continuous integration (that "quick feedback loop" idea again).
Mob programming
put EVERYone in a room, 1 guy on the keyboard. write the software together at once. no meetings, no emails, nobody left out of the loop. can get software done much faster this way. But use it sparingly.
Mastering the practice is hard, and that's why we practice.
Don't be upset about deleting code.
When you wrote that code you LEARNED something about that system.
Even if your code is deleted, you still learned that "thing" and can provide expertise info to the team.
Software Craftsman Attitude:
owning your career
NOT a 9 to 5 profession
practice
boy scout rule
expecting promotions
Keep Learning --
Learn stuff all the time
small and often
You don't want to be out of work AND having a large learning curve
learning is remembering what's important
Seniority is subjective and transient
if they've "done 10 years" but it was the SAME all 10 years, it's not really 10 DIFFERENT years of experience
People liquidity --
Assign your less experienced people FIRST
stop -
being miserable and negative
spreading your frustrations
if you don't like your job, leave
The only way to have people buying into what you believe is if they see you happy.
If a company doesn't want to invest in their team of craftsmen, well, then good luck to them!
Clean Code --
meaningful names
short functions
-single responsibility principal
-minimal arguments
show intent
-don't have an IF statement that has 15 && op's. Take that OUT and put it in its own function
-no need for comments
-your thesaurus is your field ("staff list" might be clearer named "employees")
formatting
unit testing
Code layout matters
make it easy to read and scan
Book: The Elements of Programming Style
by Kernighan and Richie
a list of software development rules that are all still valid
books --
The Software Craftsman
by Sandro
Clean Code - a Handbook of Agile Software Craftsmanship
by Robert Martin
Extreme Programming Explained
by Kent Beck
Working Effectively With Legacy Code
by Michael Feathers
cfml-craftsmanship.com
2 online video discussions a month
1 is US centric
2nd Tuesday 3pm PST
1 is Euro centric
4th Thursday 9am PDT
"the only stupid question is the one you don't ask"
http://bigmadkev.com/resources