– [Guillaume] Thank you
very much for being here, tough to be scheduled at the same time as the keynote presentation so. – [Man] Totally, totally. (laughing) (background noise drowns out audio) – [Guillaume] So I am a senior
web application developer at the school of public health. You have my email and this is my Twitter slash Github slash Slack handle. I’m on the (background noise
drowns out audio) Slack group so feel free to contact me
if you have any questions about the presentation. Alright why are we here today to talk to you about code quality, why code quality really matters. Before we talk about it, I would like to start with two old
stories, two old analogies. The first one that I like to
use is the airline industry. And the airline industry
is really interesting because when you think about it, people in the airline industry build those incredibly complex machines from scratch and they get on the tarmac, they fly for thousands and thousands of hours and they have
very, very little room for mistakes, right? How many times do you hear
of a plane getting built, taking off, and crashing immediately? That never happens. Now how many times do you hear of a website being
built, getting launched, and crashing immediately? That happens all the time. So we can ask ourselves, how
do they airline industry- how can they pull off these crazy thing? Well there is many part to the answer, but two of them are, you know, really incredibly thorough QA process and, another one that’s
pretty interesting for us, is heavy reliance on
checklist, on process. And we’ll talk here a bit
more about that later. Another example is, you know,
the construction business. You just built your dream house and you used a very good contractor. They’re like very serious people. So you move into your house and, first of all, you’re
going to expect that house to be pretty solid, right? First storm you don’t want to
see your house falling down or first little sparkle in the kitchen and the house burns down, but also, you know, a year after moving in you want to move a light fixture. You bring in an electrician
and you’re like, okay I would like to move this lamp there and he’s like, well I
can certainly do that, but I don’t know who built this house. Honestly it will take me less time to redo the entire electricity (laughing) than to move your lamp, okay. You obviously don’t want to hear that. (laughing) Now, again, going back to our business, how many times do you hear
a developer telling you, well we can add this feature, but honestly it will take me less time to rebuild the entire app than
building this new feature. You see where I’m getting with. Again we can ask ourselves, okay, how does the construction business go around with it and how do they manage to fix those problems? Again, many potential answers, but one of them is, you
know, construction codes like standards like having
the entire industry working with some standards. So what is the software
industry doing about it? Obviously I’m not the first
one thinking about that. Many people make lots of
papers, books, etc. about it. And one of the answer that seems to be the common denominator
in the industry is agile, agile best practices. And people in early 2000’s gathered in a ski lodge Utah and they came up with this thing called
the Agile Manifesto. I don’t know if you are familiar with it, this is not necessarily the point of this talk so I’m gonna
go very quickly through it. It’s built around four foundational values plus supporting principles. All of them are available at this address, agilemanifesto.org, and
if we scan very quickly through them, individuals and
interaction over processes. It’s all about the humans, we always need to remember when you’re building software that it’s built by humans for humans so the human is at the
center of the entire process. Working software over
comprehensive documentation. Working software, that’s like obvious, but sometimes a little forgotten. Customer collaboration,
that’s maybe the notion that’s a little less
relevant to this talk. And responding to change
over following a plan. That’s another very
important one, you know. I don’t know about you,
but I’ve never worked on any project that, you know, we received specs and when we launched, it’s exactly the specs we received. There’s always change, so instead of dreading change, instead
of fighting against it, we’re gonna embrace it. We’re gonna accept it and make it part of the entire process. And so 12 principles, I’m not gonna go through the 12, but I’m gonna focus on the five that are the
most relevant for this talk. Welcome changing requirements,
we just talked about it. Deliver working software frequently. So, again, we focus on
the working software, but frequently is the important part here. You’ve probably heard the acronym of MVP, most valuable product, etc. so it’s focusing on your core ideas, on the core features before anything else. When you start a new
app, when someone comes to you with the idea for a website, you’ll have this like crazy long list of features, of things, or
super cool things this website or this app is gonna do, but what you really need to ask yourself if you want to become really, truly agile is what are the core features. Focus on those, build them, launch, and then add, add to it,
build some new features, extend your app. Working software is the primary measure of progress, again, they
seem to really insist on that working software
part, that’s interesting. (laughing) Continuous attention
to technical excellence and good design enhance agility. So if we pay attention
to technical excellence and good design, we’re
gonna become more agile and that’s what we’re
going to be talking about. And, finally, simplicity is the art of maximizing the amount of work not done. Okay and we’ll talk a little
more about this later on too. So agile is great and, again, I think a large amount of
the industry is agreeing that it’s the way to
build software nowadays. Some shops are doing it really well, some others not so much, but that’s okay. But if we go further than just agile and try to consider some other things. Money is obviously very
important for everybody. So this Austrian firm, and if you have downloaded the
slides all those are links, you can click and get
to the source material, came up with that number saying that in 2016, software failure cost the global economy
1.1 trillion US dollars. I don’t know how they came
up with that number exactly, I don’t know how accurate it is, but the point is it’s costing us a lot of money and it’s pretty
obvious, you know. We’re relying more and more on technology and when technology fails, this is our losing
money, that’s just life. IBM published a paper again
in the early 2000 saying that, “the cost of discovering defects “after release are significant: up “to 30 times more than if you catch them “during the design and
architectural phase.” Again there’s a lot of
debate about this number and how they came up with it and the fact that it’s like almost 15 years old paper so is it still accurate, etc. But, again, when you think about it, even if it’s not 30, even
if it’s a different number, whenever you have a bug into production, your customer is wasting time. Then they maybe they
send a ticket to support. Support’s to read the ticket, reach out, send it to the engineering
team, etc., etc., and all those steps, all this
time and money that’s spent, it’s like basically
taking you a lot more time and then costing your
business a lot more money than if you’re catching of this, you know, if your engineer is
finding the bug himself during the design process. And finally, there’s the
more philosophical one, the karma and happiness factor. As a developer, when I ship
a beautiful piece of code, when, you know, I put it on Github, that makes me really happy. That makes me happy to
be doing what I’m doing. And code is poetry, that’s
one of WordPress’ tagline. Some people laugh about
it because WordPress might not necessarily be the most known for the beauty of its core code, but, in any case, there’s a certain pride to writing beautiful software. And, on the other hand of the spectrum, there’s nothing worse than when you come in the morning to work,
you open your emails, and you’ve got a support ticket from a customer saying
I hate your website, it’s broken, blah blah blah. That doesn’t make me feel
really good about myself, you know, and I don’t necessarily
like spending my evenings at work because something is broken or, you know, that’s not good. So yeah that’s another consideration. Alright now let’s talk
about what is good code. Defining a goal. So before we define it, I would like to talk about dependencies, you know, there’s some requirements for good code. The first one is communication. Good code doesn’t happen by magic. It’s gonna require you to
talk and talk and talk. Your team is gonna have to spend some time discussing all of this and talk and remember,
again, that it’s all about the human and talk about it. Experience- not saying that
an experienced developer will necessarily write good code, but if you’re trying
to follow the practices that we’re gonna discuss later, experience will certainly help. And finally, be reasonable. When you work in a team, you have to make some choice and you
have to make some compromises. And you have to always remember that there will be some
times where you will have to do things you don’t like, but as long as it’s benefiting your team, as long as it’s benefiting the code, as long as it’s benefiting your product and your business, then it’s a good thing and you should do it. And also we’re gonna set up processes, we’re gonna set up work flows,
we’re gonna set up rules, but there’s always gonna be
that one edge-case scenario where you can’t follow those rules and that’s okay, it’s
okay to make an exception and you should never, you know, act like staying like fully
focused on your work flow or rules because, you know, it’s a rule. So always act with reason. Alright Robert C. Martin
in his book Clean Code, I think he borrowed this diagram from a blog author Thom Holwerda, I’m sorry I’m butchering
his name probably, defines good quality
measurement is calculated in what the fudge per minute. (laughing) It’s a pretty good representation and I would like to
point out your attention on the fact that even good
code still have a couple of what the fucks per minute and… (laughing) Alright, what is good code then? If we take from the
Agile Manifesto and many of the articles I read
preparing this talk, see KEY-OH’s defining what good code is, I think we can kinda regroup it into four major categories. First one- code that works,
okay, remember working code. Code that is easy to understand. Code that is easy to maintain. And code that ships fast. Now for those five
categories what I would like to do is giving you some ideas of how you can achieve
that, how you can do that. Code that works. Self testing. That’s probably a very obvious one, but it’s pretty crazy how many times you see
developers shipping code that they haven’t really tested correctly. Or we’ve all been lazy, you know, You do something, it
works, then you’re like, oh I forgot this, I just need to add those two lines of code. You add them and you don’t
test again and you ship. It’s happened to everybody and, obviously, in those two lines of code you added, there’s a bug, there’s a problem. You forgot a comma or something and you’re shipping a bug to production. Anyway, in any case, you should have a local
development environment. If you’re working with WordPress, you’re likely using something like VVV and Docker, plenty of solution. They key point here is having something that is easy to use and easy to spin up because the harder you’re
gonna make your life, the less likely you’re
gonna be self testing so you need something easy to spin up and that is always kind of ready for you to be able to test your code there. Second, automated testing. There’s a lot of debate
about automated testing so, again, in the WordPress
world we’re gonna be talking about unit tests and PHPUnit, front end testing with Selenium. There was a great talk last year, I’m sorry I don’t remember your name, but about testing with Selenium. I highly recommend. Anyway, a lot of people
are gonna tell you: you know, automated testing
is great, every single line of code you’re writing should be tested. Some other people are
gonna be telling you: testing is a waste of time,
you should do user testing. Automated testing will fail half of the time it’s a waste of time. I think, like many things in the world, it’s all a matter of the middle ground, finding some like a good middle ground. I think the critical
component of your app, the ones that really your
business are depending on, those you should have
some automated testing. You should have some
regression testing implemented. The other stuff, the more eye candy, the less critical business,
if you wanna shave off some time and be a little
lazy, maybe you can afford it. That’s up to you, but a minimum of automated testing is
usually a really good idea. And finally, code reviews. So code reviews, we started
at the school of public health on my team a year ago we
started using code reviews so now not a single
line of code is shipping to production without doing a code review, without your code being
reviewed by a peer. And for us it’s been like
really, really great. First of all, we use code reviews as our user-testing phase. So part of the code review
process is having the person actually pull the branch locally and actually test the feature, making sure it’s actually
doing what it’s supposed to do. So that has forced on us a second, you know, level of testing. Another benefit of code reviews, when I know that someone
is actually gonna look at my code and reading
it, all of a sudden, really I’m paying a
little bit more attention to what I’m doing. I’m trying to write it
in a slightly better way because, you know, I don’t
want my colleagues to judge me. Another benefit of code
reviews, it’s helping us having some good architectural
discussions a lot earlier in the process. You know, why did you
do something like that, shouldn’t we do it like this because we have this
coming next, etc, etc. This has been like a really,
really great benefit. And finally, the last one, if
you’re anything like our team, we’re a pretty small team,
three full-time developers, we usually work on our own projects. Everyone has his own little projects and, you know, Bob is creating his app in his corner and whenever Bob is on vacation and Bob’s app breaks, my manager comes to me and I’m like that’s Bob’s app I don’t know. And code reviews have slightly, or significantly should I say, diminished that, you know, discussion. Because now I have to review Bob’s app, I have to review his code so I’m aware of what he’s doing, I’m aware
of how his app is working. So there’s a sense of ownership of the code base that has
like completely shifted and that is like really
great when you work in an environment like ours. Anyway, code reviews are
a very fascinating topic. We could talk about it,
that could be an entire talk so I’m gonna skip ahead, but if you’re not doing
code reviews at all, I would definitely tell
you to consider them. Okay code that is easy to understand. One, I don’t remember
who, but I read this paper and one argument that
the author was making is, you know, your code
base should always look like one person wrote it
and you should not be able to tell who wrote it. And I think this is kind of
what you should be targeting. One way to achieve that
is using code standards and conventions. Developers spend way too much time arguing about spaces, tabs,
parentheses alignment, and, you know, snake case versus
camel case, all that stuff. When you work on a large
project like WordPress, you’re lucky, you don’t have
to have those conversations. Someone already had them for you and came up with an answer. And, in the case of WordPress,
we have this great tool called WordPress coding standards. It’s actually not a tool,
the tool is PHP Code Sniffer and the WPCS are a set
of rules for that tool. That’s gonna take the code base, scan it, and tell you all the mistakes, all the things you’re doing wrong. If you do it on an old
project, you don’t wanna do it because you’re gonna hate the amount of errors it’s gonna give you, etc. What we did in the case of our team, we agreed that any old code
would not be compliant, however any new code that we were writing, would now be following, 100%, all WordPress Coding Standard rules. Again, be reasonable, sometimes you need to make some exceptions
and, you know what, the tool actually gives
you some great ways to create those exceptions, but 99.9% of the time we’re gonna be
following those standards. And if you really, really don’t like the WordPress coding standards, that’s fine, there’s plenty of other coding standards
available out there. Google has some for JavaScript, for CSS, all you want, they’re there. The point is, pick one and follow it. That’s gonna help you
having this code base that looks like one person wrote it. Another important thing when you think about making your code easy
to understand is naming. I’m talking about function naming, variable naming, class naming. Comments are great, but you
should never really need to write a comment to explain
what a function is doing. The function name itself
should be like pretty obvious. And the parameters that
this function is taking should also be pretty obvious
about what they’re containing, what they’re doing, etc., okay. I’m not saying don’t write
comments, of course not. There’s always gonna be
a time where you need to be smart, where you need
to do something complex and you should always write
comments for those cases. You should always try to, you know, if you need to write a comment
to explain what you’re doing, ask yourself if there maybe an easier way to understand what I’m doing just by changing the way I wrote the code instead of needing to write a comment. Readability over optimization/smart. That kind of goes to
what I was saying before. Always favor readability. But how many times do you hear, yeah but that’s not
optimized blah blah blah. Honestly who cares about
that 0.111 millisecond of execution time if
then, when I’m gonna need to go into your code and change it, I’m going to spend 20 hours trying to understand what you did
and fix it and refactor. That’s gonna cost a
lot more to my business than that 0.111 millisecond
of execution time. Not saying that optimization
is not important. Obviously not, but, again, readability should always
be the main priority when you write code. Code that is easy to maintain. Architecture. That’s another very important point. Too many times, and that’s one of those where experience is gonna help a lot, too many times I see
people, they receive specs, they receive a story in
JIRA, and immediately (mimicking keyboard clicks) they start coding. Don’t do that. Take a minute, take two minutes, take 50 minutes, a walk, you know, paper, whiteboard, whatever you need. Think about what you’re about to do. Think about the general architecture. Think about how your class
is going to be built. Don’t start writing code immediately. Just a few seconds. Build for the present,
design for the future. Again we need to remember that… We’re in an agile world and
we’re building agile software and that code is going to change. Whether you like it or
not, it’s going to change. You might not know it
yet, you might know it because your customer doesn’t seem to see the big picture
and you know very well that once this code is past shipping that they’re gonna come back to you and say well actually we’d like this to do this differently
because we don’t like what we asked you for originally. Anyway. WordPress does some
great features to do that and one of my favorite thing about WordPress is
action and filter hooks, how you can change anything
or most of the things of the core behaviors like how you can completely
customize the way that WordPress works, that’s awesome. And not often enough do I see developers on smaller projects, you know, using those mechanisms, building them in. And obviously we said before that we want to maximize the amount of work not done. We don’t want to create
write use less code. We don’t wanna clutter our app. But still, sometimes a well placed filter, a well placed action hook, that’s gonna potentially save us a lot of time on the long term. Again that’s one point where
experience is gonna help you. That’s where down the line
you’re gonna start seeing, okay, here I have some raw
data, I’m doing some filtering on it, maybe I should build in a hook so whenever they ask us to add a new way of filtering the data, I can go back and very
easily change that behavior. Anyway. And finally, code that ships fast. One of the first step to do is to do some kind of agile
project management. There’s plenty of them, again,
that could be an entire talk. SCRUM is one of them. In our case as the
school of public health, we are using Kanban. The biggest reason is our
team is very heterogeneous. We have a DB administrator,
some support people. We’re not all developers and SCRUM is very developer-oriented. It works very well in agency setup where you have those projects
that you take in, etc. For us we’re jumping context all the time so Kanban seems to be
offering us a lot more agility in that manner. Anyway, Kanban might
not be the best solution for your team and the way you work. That I don’t have the
magical answer to it. You’ll have to do some research. You’ll have to do some testing on your end and figure out which
one works best for you. But you should be trying
to embrace some kind of agile project management methodology. And that’s gonna help you, you know, breaking down your work in smaller chunks. That’s gonna help you avoid working on too many things at the same time. And that’s gonna help you
on the long-term shipping, on the due date… Not breaking deadlines. Automation- going back to my
automated testing example, that’s something where you hear a lot of people saying you should
be automating everything and some people saying well, but you’re wasting so
much time configuring those automation tools
that, at the end of the day, you’re not saving any time blah blah blah and when the automation tool breaks. Again, middle ground. Identify the really painful processes, the really painful part of your work flow where you feel like this is boring, I’m wasting so much time doing this and automate those steps. And the rest, if you have to do a few
things manually, that’s fine. Be lazy, reuse, fork, extend. Minimizing the amount of work not done. We’re lucky we’re working
with WordPress open source, millions of plugins, millions of themes. Don’t reinvent the wheel. There’s probably already someone who, you know, built whatever you’re trying to do and even if you find a plugin, it seems to be doing whatever
you need, it’s actually not, there might be some part of the app that you can reuse or, if nothing else, it’s gonna give you some
ideas on the architecture, on things you should not be doing, etc. So always try to see what’s out there before you start coding, before
you start creating anything. But also if we go back
to the few last points, if you start building your code with some hooks, if you
start building some code that you can read and go
back to six months later and still understand, you’re gonna be able to reuse your own code much more easily. And, therefore, you’re gonna save a lot of time and ship faster. And finally, I was talking about it with the airline industry, checklists. Checklists is something we’re starting to implement and that I
think is really underrated. Speed is the enemy of quality or whatever you want to put it. As you start shipping code faster, as you start, you know, trying to do more things, you make
mistakes and it’s fine. And one of the reason
your plane works most of the time, pilots do very
little things by habits. They have those crazy detailed checklists and they follow them one by one and all the steps like I’ve done this, I’ve done that, etc., etc. Critical part of your process, the one that you can’t automate, that you’ve decided it’s
better that we do it manually, you should have a
checklist for that process because we’ve all, you
know, launched that website at three in the morning on Friday and you come back on Monday and your marketing team is screaming at you wow we’re out of Google. Oh yeah, I forgot to uncheck
that do not index the website on Google, right? Those checklists, that
will definitely help you with this kind of issues. Alright there’s obviously a lot to talk about and there’s a lot of ground to cover so and I could
not talk about everything so if you’re interested in going further, I would like to recommend
a couple of reads. I mentioned very early Clean
Code by Robert C Martin. That’s like the bible when
talking about code quality. It has some really, really good insights and a lot of things about naming, architecture, and all of this. I strongly recommend Agile
Project Management with Kanban. If you ever consider Kanban as your project management solution, this is a really good book. Eric Brechner, he is the
head of the development team at Xbox for Microsoft, and basically in this book he explains how they went from zero agile to full
Kanban with this team and all the steps and the hurdles and the problems and etc. Really good book and, on top of it, if you don’t read books there’s plenty of good YouTube videos about
him and interviews, etc. A little bit of Harvard self promotion, (laughing) The Checklist Manifesto, Atul Gawande, he’s one of our rockstar faculty. He wrote this awesome
book about checklists. This is not about software at all. This is mostly how they
implemented checklists in the medical industry,
in the operating room, but he is using a lot of analogies from the building industry,
from the airline industry, etc. And how checklists have changed, you know, the way he is doing some things and how they implemented
this in the operating room. Really good book, highly recommend. And finally, a really
good article that I like about code reviews from
the Slack Engineering team, How About Code Reviews. There’s plenty of resources
about code reviews, but I thought it was one good article that is kind of summarizing
all the drawbacks and advantages of doing code reviews and that was one that
talked the most to me. Okay, I’m sorry if I was talking too fast, but at this point I would
like to welcome any questions. – [Man] So you mentioned checklists and you said you’re
starting to use those more with your team, can you give an example of a checklist or a couple of or ways that you have build checklists? What was the first checklist that you kind of formalized with your team? – [Guillaume] So we’re still
formalizing those checklists, but the first two that we’re focusing on are launching websites
and creating websites, like the original first few steps when you create a website. We work with many offices and part of that work is creating that website on our staging environment,
making sure it’s not accessible to the public, activating a few plugins, and things like that
and we always missed one of the steps at some point so we’re trying to document that process of creating, like, a new website,
when we receive a request from a user and the launching part because the Google index example or we have a plugin that
will block public traffic and require you to sign in with the single sign on
solution from the university and we usually use this during the beta where we want everyone from the department to be able to see the website without exposing the
website to the public. Don’t forget to do that, don’t forget to ask the custom domain to be added to our SSL system, and things like that. So yeah launching and
creating new websites, that’s the two first
that we wanna focus on. But I envision many more of them in the future because we
have a lot of processes. – [Man] Can I ask you a question about automated or, not
even automated testing, but just testing in general? You mentioned Selenium as
you guys’ testing product of choice and not being
a fully-trained engineer, I have no idea how to even get started in that space or what that entails. Can you talk a little bit about how to get started doing
those kind of unit tests and those kind of things? – [Guillaume] To be very
honest, we don’t use Selenium and we do very little
automated testing right now. – [Man] Totally fair (laughing) – [Guillaume] We’re coming from far and we’ve been improving a
lot in the last few years and in a limited time we’ve
gotta pick our battles, but if you’re interested in looking into Selenium, again, I
can only refer you to- – [Man] That guy up there? (laughing) – [Guillaume] His presentation from last year was great,
it was exactly like how to get started with
Selenium and that, you know, and that’s gonna help you see, like, okay this critical part of my app whenever I push in a date, suddenly the menu is
not showing up anymore and those automated testing are
gonna help you tackle those. – [Man] Cool, okay. – [Guillaume] And unit tests
there’s really good talks. A lot of automatic people have
done some really good talks at different word camps
about PHPUnit so again. – [Man] I’ll keep looking, thanks, – [Guillaume] Sorry. – [Man] No, no you’re fine. – [Guillaume] Any other questions? – [Man] Okay hearing none from the room, let’s give Guillaume a big hand. (applause and cheering)