What comes after SOLID? Seeking Holistic Software Quality
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 68 | |
| Number of Parts | 86 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/31300 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
RailsConf 201768 / 86
1
8
10
12
18
19
23
30
35
42
49
52
53
55
56
59
65
74
77
79
82
83
84
00:00
TelecommunicationAxiom of choicePoint (geometry)Machine codeProcess (computing)Self-organizationDivisorFormal languageElectronic program guideBlogSurface of revolutionSoftware frameworkHuman migrationActive contour modelStatement (computer science)Software developerStrategy gameBitObject (grammar)Right angleFigurate numberThermal conductivityWritingWordArmField (computer science)Multiplication signData conversionMereologyVideo gameSoftwareRule of inferenceLevel (video gaming)Product (business)Metropolitan area networkDigital rights managementDecision theorySurgeryGoodness of fitTerm (mathematics)ImplementationDifferent (Kate Ryan album)EvoluteFamilyNatural languageNumberQuicksortOnline helpArithmetic meanLine (geometry)Projective planeForm (programming)Electronic mailing listXML
08:51
Right angleMultiplication signSoftwareOnline helpMaxima and minimaLattice (order)2 (number)Term (mathematics)Context awarenessPattern languageElectric generatorComputer architectureCASE <Informatik>Address spaceProcess (computing)Machine codeFitness functionComputer programGoodness of fitDivisorWordSineMobile appSpreadsheetProduct (business)Row (database)Point (geometry)Cartesian coordinate systemMenu (computing)BuildingData storage deviceTranslation (relic)Software developerScheduling (computing)MereologyControl flowAxiom of choiceEmailSorting algorithmBit rateStatement (computer science)Logic gateArithmetic meanHypermediaArithmetic progressionCue sportsError messageNP-hardBitSoftware frameworkEntropie <Informationstheorie>Slide ruleLimit (category theory)QuicksortScripting languageSoftware testingSurgeryMathematicsOctahedronStreaming mediaXMLComputer animation
17:19
Endliche ModelltheorieMathematicsAreaSoftware developerPublic domainObject (grammar)Arithmetic meanGoodness of fitPhysical systemTerm (mathematics)Service (economics)Machine codeGroup actionSurfacePerspective (visual)Inversion (music)Dependent and independent variablesAbstractionWebsiteMultiplication signChainWordBitElement (mathematics)Core dumpMereologyContext awarenessCircleCausalityDivisorData conversionDiagramQuicksortLevel (video gaming)Centralizer and normalizerPoint (geometry)Execution unitRight angleOpen setSingle-precision floating-point formatClosed setElectronic mailing listEvent horizonTheorySubstitute goodSocial classSoftwareDirection (geometry)Error messageConfluence (abstract rewriting)Thermal expansionInheritance (object-oriented programming)Traffic reportingKey (cryptography)Axiom of choiceReal numberWritingInstance (computer science)Information overloadSolid geometryPrincipal idealFunctional (mathematics)Product (business)Interface (computing)CognitionSoftware bugImplementationMetric systemProper mapVenn diagramXML
25:46
Level (video gaming)Computer programQuicksortShared memoryPhysical systemMachine codeSoftware testingBitAxiom of choiceDifferent (Kate Ryan album)Context awarenessFrequencySoftware developerMultiplication signPerspective (visual)Continuous integrationGoodness of fitSpacetimeChromosomal crossoverData conversionBuildingDirection (geometry)Systems integratorSound effectFormal languageScaling (geometry)Parameter (computer programming)FacebookTwitterScalabilityObject (grammar)Complex (psychology)Condition numberMetric systemMobile appFunctional programmingRight angleMeasurementElectronic program guideBus (computing)Term (mathematics)Machine codeStrategy gameSelf-organizationProcess (computing)Normal (geometry)Execution unitOrder (biology)Cartesian coordinate systemInteractive televisionDivisorRevision controlINTEGRALMathematicsBinary decision diagramObservational studyUnit testingPhysical lawVertex (graph theory)DemosceneOnline helpAreaGroup actionProper mapControl flowWhiteboardTriangleTheory of relativityWordCausalityProduct (business)Endliche ModelltheorieStructural loadOpen sourceResultantXMLComputer animation
34:14
Term (mathematics)Line (geometry)Multiplication signSoftwareRule of inferenceClient (computing)Projective planeINTEGRALDigital rights managementFrame problemComputer configurationMachine code1 (number)Near-ringLibrary (computing)Context awarenessOnline helpAreaSheaf (mathematics)Covering spaceTablet computerMathematicsFunctional (mathematics)MereologyRight angleSlide rule2 (number)Focus (optics)NumberCollaborationismBound stateSelf-organizationDivisorDialectBendingComputer sciencePoint (geometry)Sound effectArithmetic meanParticle systemSoftware developerFigurate numberScaling (geometry)Goodness of fitMathematical optimizationWritingWebsiteEndliche ModelltheorieMathematical analysisProduct (business)Directory serviceCodierung <Programmierung>Expected valueBuildingMachine codeSoftware frameworkProcess (computing)Code refactoringBitMobile appLattice (order)TrajectoryDiagram
42:41
XML
Transcript: English(auto-generated)
00:00
I want to start out today by doing a little exercise.
00:21
The exercise is lifted from a book called Nonviolent Communication and it's called Translating Have To To Choose To. The idea is that we all have things in our lives which we do not because we inherently enjoy them but just out of some kind of sense of obligation.
00:42
We feel that we have to do them. And the idea of the exercise is to acknowledge that there's a choice there and once we realize that it's a choice, figure out what we're going to do about it and think about maybe how to re-make that decision. So, you take all these things in your life that you don't really enjoy doing, you
01:02
make a big list of them and then you have to fill in one by one this sentence with each thing. So, you say, I choose to X because I want Y. You figure out what's the reason that you make the choice to do that thing and what you'll basically find is one of a few things will happen.
01:22
Maybe the thing that you want is actually really important and you'll find new meaning in the thing that you were doing and it'll feel more like an active choice that you want to make. Maybe you'll say, well the thing that I want wasn't really that important so I don't really have to do it. Or you'll say, well the thing that I want is important but maybe this isn't quite
01:42
the right way to get to that point. Or maybe there's just a different kind of broader set of strategies that I need to really get the thing that I want in some kind of better way. So, today we're going to ask the question, why do we choose to write good code?
02:03
And that's a little bit of a scary question, right? You know, what do you mean? We have to write good code, right? You know, it's ingrained into us, you know, we go to talks at conferences, we read books, we watch podcasts, or listen to podcasts I guess, we watch stuff online, we read blog posts all about good code, we have to do it, that's just, you know, that's what we do, right?
02:21
So, I'm here to tell you first of all today, you don't have to write good code. You choose to write good code hopefully and part of today will be figuring out why we choose to write good code. That second line, because I want what, what do we fill that in with? Maybe we fill it in with, well, if I don't write good code by some kind of arbitrary
02:42
standard then I'll get fired. A sad reason too, but that might be it. But ideally we find something meaningful and important in terms of why we're choosing to write good code. So why do we care about writing good code? And because this is a talk about software quality, and that's really the ultimate goal here,
03:02
we have to ask, is good code actually the same as quality software? So we'll get back to that, but first I want to talk about something somewhat but not entirely different. Dave Thomas, Bob Martin, others as well, but I mentioned them just because they were signatories on the original Agile Manifesto, have said that Agile is broken.
03:25
It didn't accomplish the revolution that it was supposed to accomplish. Here's a quote from Bob Martin quoting Ken Beck, who was also there. He said that one of the goals of the Agile Manifesto was to heal the divide between development and business.
03:41
There was a gap that had, that had been created, a chasm between the two sides and a lot of tension, and the goal was to relieve some of that tension and, and find ways to work energetically and harmoniously. Reality check? I don't think it really worked. They don't think it did either, so at least I have some people who were involved in Agile
04:02
right from the top saying, not great situation, but what it became was basically some kind of business person, project manager, whatever it is, would take a course, get certified in something, and basically tell developers, okay, now you're all going to do Agile because that will lead to better software.
04:24
It's something that developers do to keep business people happy, if you could even do, in quotes, Agile. Usually the form that this takes is Scrum. I forget the number, 60, 80 percent, something like that, of organizations that claim to be doing Agile are using Scrum as their implementation. Fun fact, as far as I can tell, because I've read through the
04:46
the Scrum guide and I've read through the Agile Manifesto and compared the two, it addresses maybe 50 percent of what Agile is and it kind of misses out on all the values. So I'm not saying that Scrum is bad. I don't want to give that impression. I think Scrum has a lot of really good ideas.
05:01
It's just not an implementation of Agile. It's a framework in which you can choose to be Agile or not. It makes it easier in some ways, but it's not actually agility. We don't need more processes. Sometimes processes can be helpful, but they're a tool toward something more important. And what I think that we need, and this is why I'm coming kind of coming down kind of hard on Scrum, is we need more trust.
05:22
Scrum focuses a lot on transparency. As far as I understand, transparency is basically we have two sides. Each side says to the other, I need to know what you're doing at all times. I need you to be transparent about it, so that when I see something going wrong, I can jump in and complain and micromanage you. Trust, on the other hand,
05:40
is let's, let's have a conversation. Let's understand that there are two sides to the situation here, and let's talk about the needs of each side. Each side will express their needs in a way that makes sense to the other side, and once we're confident that the other side has heard our needs and understands them, we can rely on the other side to think about our needs
06:00
and account for them in their own decisions. That's what trust is, to me at least, and that's what allows us to build effective organizations. I think we can solve this problem. I don't think it's, it's even too complex. It's difficult, but I don't think it's complex, and it starts with communication.
06:20
If we learn to communicate between developers and business people in a way that that makes sense to both sides, then we can start building the trust that we need to have highly effective organizations. So we have an ambitious goal today. We're going to create a common language for developers and business people to be able to express their needs in a way that makes sense to both sides.
06:44
And the way that we're going to achieve it is by going right for the jugular, taking, taking the thing that causes a lot of tension between the two sides, and trying to understand it again. Figuring out why we write good code. A lot of times we push for good code in whatever way we define it,
07:03
and, and good code takes time and takes investment, and it's, it's hard to explain that to the other side, and that causes a lot of tension. So we're gonna figure out why we write good code, but first let's figure out why do we write code? And I really mean that. Why do we write code ever? Seems like a strange question, right? You know, we're developers.
07:22
That's what we do. That's our job, right? Well, newsflash, controversial statement. Okay, but I think it's, I think it's, it's certainly pretty clear to me. Your job is not to write code. Your job is to solve problems. I want to give an anecdote from specifically in another field that will help us look at things a little bit more objectively.
07:45
So there's a, a man once came to a plastic surgeon, and he said I need you to do some surgery for me. My ears are very large, and I want you to make my ears smaller. Interesting. So the surgeon decided to probe further. Okay, why do you want this surgery? What problem
08:03
are you trying to solve? And this guy said well, it's, it's not a problem for me actually at this stage of my life at all. You know, I get along fine. We're all adults, right? But when I was a kid, I got teased a lot. I got bullied a lot over the size of my ears, and I don't want to pass on that problem to my kids.
08:22
I'm about to start a family, and I don't want them to get my ears. So how about you fix my ears so that I won't pass it on? So he clearly still had a Lamarckian understanding of evolution. I was curious how many laughs that would get. So,
08:41
and basically what the doctor did was say hey, let's talk about modern genetics. Let's understand how these things actually work, and why I can't solve your problem, and the solution that you suggested certainly doesn't help. If the doctor had said okay, that's nice. Let's, let's schedule a surgery. We would call that malpractice. But it's funny because that's very clear to all of us, I think.
09:02
But what happens when someone approaches a developer and says hey, I want you to build a mobile app for me, and the developer says okay. Without even understanding the problem that we're trying to solve, without understanding whether this is the right solution. Maybe they need a marketing director. Maybe they need to just have an email campaign. Maybe a lot of things.
09:21
There's thousands of apps out there in the App Store that reflect this problem. They don't do anything for anybody. They don't, they don't matter. I have a hard time calling them high-quality apps. Because they don't solve a problem. If you're not solving a problem, there's never a reason to write the code. Now this doesn't sound very businessy, so I'm going to give a little translation. Your job is to create value.
09:43
And that's kind of a loaded term. It means a lot of things to different people. So I'm just going to give a working definition that we're going to use for the rest of the talk. Value creation in the context of this talk means one of three things or more of those three things. Generating revenue,
10:01
lowering costs, or reducing risk. Those are the main things that matter in business. In the specific case of a nonprofit, instead of generating revenue, you can substitute doing whatever good the nonprofit is supposed to do. And but you know on the whole the same the same pattern still applies. Those are the three things that we mainly care about.
10:24
And where do users come in? Well generally the way that you do these three things is by meeting the needs of your users. So we're going to use meeting business needs and meeting user needs kind of interchangeably in the talk. Hopefully they go together when they don't is a whole discussion that I'm just not getting into today. So to recap why write code to create value. That's it. That's the only reason we should ever be writing code.
10:47
If that's the case, why do we care about writing good code? I think the answer is simple. It usually helps to create value. Does that mean that good code is the same as quality software?
11:00
According to this definition, I don't think so. So here's the second of two controversial statements. I would define software quality as just the amount of value that it creates. We're writing the code to create value. If it creates that value, it's there for a purpose. It is ergo high quality. If it doesn't meet the needs, then it can be, you know, really well written under the hood.
11:27
It doesn't really help because it's not actually solving a problem. So rather than asking how can you write better code? What we should really be asking is how do we target our efforts in coding to maximize value creation? And how does good code fit within that whole broad picture?
11:45
So I'm gonna commit a major programming sin now. Which is solving a problem by writing a framework. It's not JavaScript. It's just a human people framework. It's only three words. So, uh, hopefully it's, uh,
12:03
you know, not not too bad. I think that there are three factors that if we if we think about these three, we can pretty much fit anything about software quality as we've defined it into one of these three factors or two or three out of them. I call them usefulness,
12:21
sustainability and accuracy. We're gonna talk about what each of these means, but you'll notice there's an acronym there. I didn't I didn't choose these words over the acronym like that that that happened. Sometimes you just want a cool acronym. They it happened to be the acronym that came out. But if thinking about the USA helps you in terms of remembering the three words, all the better.
12:44
All right, so let's start with usefulness. Each of these is going to have a question and target. The question in terms of usefulness is does it solve a problem effectively? Pretty straightforward. But a lot of details there. The target here is our users. Again using users and business needs a little bit interchangeably. The question is
13:08
is it a problem that affects users first of all? Sometimes we spend a lot of money to code up a solution that doesn't actually address a need. We have to make sure in whatever way we can that we verify that the problem actually exists and that it affects the users
13:21
that we're going to be addressing. Then even if we've correctly identified a problem it's important to think about well, is this actually a solution to the problem? Or are we missing something? And it can't just solve a problem. It has to solve the problem in a way that works for the users because if it works
13:42
but doesn't work for them, you haven't really done an awful lot. I want to cite a story from Tara Turner de la Fuente who gave a keynote at RubyConf last year. Which I think absolutely illustrates this point really nicely. She was working with a user of one of their applications.
14:02
Just kind of seeing what they were experiencing. It was to upload a spreadsheet with a whole bunch of rows and anything that the application could figure out great. If not, then you had to kind of fill it in. So some of the one of the columns was a column of dates and
14:20
you know most of us think like okay date, date picker, great. In the case of this application they decided to allow inserting dates and putting dates by a drop-down menu. Without sorting the dates. So there were just hundreds of dates in a completely unsorted list that they had to look through. Somehow managed to find the right date and then repeat it again and again and again and again until the whole spreadsheet was done.
14:44
And if there was an error, by the way, you had to go back to the beginning and it wouldn't save what you had done so far. That meets the needs technically. You'll eventually get it done. I guess, but it's not in a way that works for the user. It's really hard to call that a high-quality product. Okay, that's usefulness.
15:02
Sustainability. What's it about? The question is can we keep building without unnecessary obstacles? And I thought about this a lot. I didn't want to say without obstacles because there are always going to be obstacles there. The question is are we identifying the most important obstacles and trying to account for them? Trying to limit the things that are going to stand in our way as we continue developing.
15:22
The targets, in this case, there's two targets, which I think are really one. The first is our software. Is the software resistant to change? That breaks down into two sub questions. One is an issue of understanding. Is the software written in a way that we just won't understand what it does and it's going to be hard to make changes?
15:41
The other piece of it is well, even if it's very clearly written, we understand what it does. But the architecture, some certain architecture choices we might have made make it hard to change things later on. So, it just takes longer. It's a lot more effort to do. The other target is a development team. We so often forget that
16:01
the development team is, I don't even want to say it's as much a part of our software as the code itself. It's more of a part of our software than the code itself. Think about how just care for you are when like deleting code, putting in new stuff. You don't do that with your team, right? The rate of churn is ideally a lot lower.
16:21
And, you know, you crash the development team, you basically don't have a product anymore. So, it's important to be aware whether the team is unstable in some kind of way that, you know, if things are tipped a little bit, is that going to prevent future progress? Is the team going to collapse? Or just become less effective in some way?
16:41
That's sustainability. Let's talk about accuracy. This is the one that we probably think about the most. The question that we're asking is pretty simple. Does the software work the way that we think it does? The target here, you think I'm going to say the code, right? The target is ourselves.
17:01
We have to ask four questions. Have we developed our understanding of the problem? Sometimes, we just don't understand the problem correctly. We do everything right in the coding step. But, we haven't taken the time or the effort to figure out first. Is this actually the problem? Does it solve the problem? Is it, you know, all the usefulness stuff leads into an accuracy problem?
17:22
Have we developed understanding of the code? Is there something about the code that makes it hard for us to get the next step done? And we're just coding the wrong thing. Sometimes, there could be issues of cognitive overload that even if the code is relatively clear, but there's so much going on, too many integrated systems, microservices, whatever,
17:42
that you just don't understand the full impact of your actions. And finally, our understanding of a problem changes over time. Sometimes, the problem itself changes over time. If we're not updating the code to reflect that, that ultimately appears as an accuracy problem. These seem like things that are maybe a little bit like mashed together that shouldn't be together.
18:05
But, if you think about it from the perspective of the user, if any of these are failing, your software is broken. That's a bug report. Any of those questions. So, to me, that means that they're all issues of accuracy. I can't speak for anybody else.
18:21
But, when I think about why I write good code, why I choose, actively choose to write good code, it's because I want software that's useful, sustainable, and accurate. And good code is a significant tool in helping me get there.
18:40
Here's the traditional model with the business development chasm pictured. In the right corner of the room, we have accuracy and sustainability. Those are seen as the domain of the developers to write, you know, good accurate code. And, on the left side, we have usefulness, which is the domain of designers, UX people, product people, etc.
19:01
And, never the twain shall meet. You really subdivide those responsibilities, and it's not surprising that each side advocates for the things that it cares about. Well, you said never the twain shall meet, but today the twain shall meet. What we actually need is to think about quality as all of those factors together.
19:23
We need to have, we can't leave out any element of that. And, we have to be part of that usefulness circle as well. So, this has all been pretty abstract, I realize. And, I don't want to leave you with just kind of abstract floating-in-the-air ideas.
19:40
I want to take this down to a very practical level. So, what we're going to do, clear out the diagram. We're going to ask the question, is it quality software? And, we're actually going to fill in the things that we do on a much more granular level to address each of these three points. Usefulness, accuracy, sorry, sustainability, and
20:01
accuracy. Now, this is a Venn diagram. There is going to be some overlap on occasion. Practices might contribute to more than one of these circles. Or, to something that we might think of as maybe the confluence between those two circles. So, I'll just give a little more definition. In the middle, we have
20:20
between accuracy and usefulness, the question of, does it work in the way that the users expect? All right, less thinking about ourselves, starting to think more in the direction of our users. Between accuracy and sustainability, we're asking the question, can we keep building our system without breaking our system? It's, it's future focused accuracy.
20:41
And, up top, between sustainability and usefulness, we have the question of, are there obstacles to future usefulness? Essentially, things that aren't threatening usefulness right now. But, we were aware that the choices that we make now might have some kind of impact in the future on how useful our product is.
21:00
Alright, so I titled this talk, what comes after solid? I thought it was a, you know, a nice juicy title. But, I also think it kind of makes sense to start by talking about solid, because it's just this traditional metric of software quality. And, you know, we, we, we think a lot about it. We talk a lot about it.
21:21
I'm actually not gonna talk a lot about it. I'm actually gonna run through it really, really fast. So, if you aren't familiar with all of the details of solid, that's okay. I could spend the whole, the whole 40 minutes just talking about that. So, you might be bored for about a minute, but we'll be fine after that. There's tons of stuff that you will understand. Fine. So, solid stands for five different principles that are related to creating whatever we might define as, as well-crafted software.
21:45
The single responsibility principle. The idea that every element in your system should do one thing and do it well. The open-close principle, which is short for open for extension, closed for modification. Meaning that you should be able to add new features without modifying existing code. How you do that is,
22:03
again, a long story. So, not gonna get into it. Liskov substitution principle. Basically use inheritance properly. Don't inherit from a superclass because you need like a method. You should inherit because it's actually a specialized instance, but it should fully implement the superclass in all of its functionality. Interface segregation. This is not that relevant for Ruby because we don't really have interfaces in the traditional sense.
22:26
But I think of it as, you know, ultimately it's about limiting the surface area of how objects depend on other objects. You can do that with adequate interfaces. Technically, I don't think it matches a principle, but it's close enough. And finally, dependency inversion.
22:41
Depends on abstractions, not concretions. You're basically pushing dependencies to the outside of your system. And then the core elements, the units, are depending on sort of a theoretical idea of what the dependency is doing without relating to too many of the implementation details. So, let's run through. We'll do this very quickly.
23:04
SRP, I think, is a big winner. If every item in your system does one thing and does it well, it's easy to tell if it's if it's doing the thing that it's supposed to do. It's much easier to change later because you know exactly what to go back to and modify. And this is sort of a personal opinion. There's gonna be a lot of personal opinions here. So, I apologize, but kind of sorry not sorry.
23:26
The main thing here is is not to learn the details. It's to see the way of thinking. And ultimately you're gonna apply it yourselves. But back to right here. So, usefulness. I think that single responsibility means that each part of your system has a very clear responsibility and that lets you start thinking about is this
23:43
the right responsibility? Is it something that actually creates value for people? Is this or is this something that shouldn't should or should not exist in our system? It opens up a pathway to those conversations. So, I think of it as a very very central practice. Open-closed is really just about the future. So, I put it all the way over in sustainability.
24:02
Liskov substitution is about avoiding certain classes of errors. So, I think about that as avoiding errors now and avoiding errors later accuracy sustainability. Interface segregation and dependency inversion again are really about the future. So, those go all the way in the sustainability camp.
24:22
So, that's where solid falls out in the way that we've expressed it. It's all in the sustainability camp. There are a few that get into other places and again SRP to me is a pretty central practice. Let's talk about some other stuff. Sandy Metz has her four principles which get the acronym true.
24:44
You can read about them in the first chapter of Poudre. Four principles that are meant to create systems that are that are much more much more robust in terms of their ability to accept change. Makes it much easier to change them in the future. Transparent meaning that the consequences of changing code should be obvious.
25:04
Reasonable, the cost of change should be proportional to the benefits. If it's a small change then it shouldn't be or sorry if it's not that beneficial change you know versus if it's a very very beneficial change the cost of change should be proportionally related.
25:24
Usable, basically is the code reusable in other contexts and Exemplary your code should set a good example for coders to come because of course we all kind of look at the system see that oh it is the way it is therefore like let's just perpetuate those qualities in the future because obviously whoever was here before did it right.
25:41
Those are all explicitly about the future. So, I put them right into that sustainability camp as well. So, we're pretty heavy on sustainability but let's try to diversify our strategy for quality just a little bit. Let's talk about testing. The first thing that very often in our community we forget is even a choice is testing at all. You could not test. There's a lot a lot of places that
26:06
and teams that don't test at all. So, choosing to test at all is a practice. Code coverage the the attempt to make sure that every piece of your system is exercised in a test. Different types of tests that we could talk about there's unit tests which tests a small piece of your system integration tests, which are
26:25
testing how pieces of your system interact with each other a much broader perspective and manual QA which is even further out. You have a person who probably hasn't worked on your system themselves thinking about a user perspective trying to use it as a user trying to break it etc.
26:44
Okay, then we have TDD and BDD. I'm not going to offer my own definition of it. I'm just going to try to give my understanding of how the RSpecBook defines them. Either way you write your tests first but with TDD you start out with very small units you build you build your way up out to the out towards the
27:00
edges of your system. With BDD it's the opposite you start out with the with the broader perspective of what you're trying to do for your whole system and then work your way down. So, how did those fall out? Well, not surprisingly they're all in the accuracy camp because they all help you write more accurate code. Coverage helps you out with the future as well. It's explicitly designed that if
27:20
anything about your code changes in a way that's that's going to break it you have a test alerting you to that fact. You have BDD manual QA and integration tests. I think actually do relate a little bit to usefulness because they're making you think about your system not in terms of is a code right, but what is the purpose of writing this code? And testing I put in the middle because I think that all these actually provide a pretty strong signal
27:40
in a bunch of different directions. So, I think of testing as a central practice as well. Alright, so that was a little dry. Let's talk about some hot new buzzwords. Everyone's talking about functional programming. DHH seems to be I'm not sure if he's in Twitter or not. Based on the keynote this morning, but everyone's talking about it type systems.
28:02
Everyone's talking now about gradual typing, soft typing, typescript, type type type. Immutability. Creating objects that should not change after they're created and scalability everyone talks it's all about now how you have to be Facebook style. You have to be Twitter scale. You have to be I don't even know.
28:20
So, most of these are actually really in the accuracy camp. You could make an argument to push over some of them into sustainability just a little bit. But ultimately they're about writing code that's accurate. It doesn't that doesn't have unexpected side effects. So, so that's most of them. Scalability is is a little different. It's about future usefulness and
28:43
the reason I say that is because if you actually need scalability right now that that's not called scalability anymore. That's called our app is down in production. That's a different problem an important one, but not the same. Scalability is about well one day we might need to you know, deal with a lot lot more load. So, let's think about that now which I don't know how useful that is, but for some apps
29:03
I guess it can be. All right complexity metrics. Those are fun. Cyclomatic complexity. How many assignments, branching and conditionals does your code have that make it more difficult to understand? If you use Flay, it's it's looking at that. Low canascence. This was introduced to me by the patron saint of wonder Jim Weirich in a talk that he gave a few years back.
29:26
Basically different places of your code that have to change in tandem are create canascence and we want to lower that. We want to minimize how much how many things you have to you have to change together to have your system not break.
29:40
So, I put that basically the more complex something is the harder it is to write correctly the first time and the harder it is to write correctly the next time also. So, that's that's where I see those falling out. Okay, now we get to something that's for me a lot of fun something I care about a lot which is team oriented practices.
30:01
Organization conventions. If you have something like, you know, we all use the same what we all use rails. We all you know use a certain certain tech stack a certain process tool anything that that is consistent across your organization that makes it easy to to move across teams if need be. That's that's one team oriented practice. A style guide and ideally enforcement of that style guide programmatically with
30:26
Rubocop, JSLint, whatever is the appropriate tool. Something that keeps your code consistent, so it's much easier to navigate and understand. The bus factor. This is the measurement of how many people on your team would have to be hit by a bus in order to destroy your application.
30:42
Fun fact most teams have a bus factor of one. Which is bad because occasionally aside from dying people also quit get fired or take vacations, get sick.
31:00
We want to ideally have have ruin our organizations for people to do normal people things and have our apps not be destroyed. So mainly knowledge sharing also upping the level of really everybody on the team rather than kind of hoarding knowledge or skill. Code review, okay. Stuff gets reviewed before it's checked into source control.
31:21
Pair programming or mob programming. The sort of like code review on steroids. Taking multiple developers however many it is and having them work on code at the same time each providing your own perspectives. Internal documentation, read me's, stuff like that. Things that help you both onboard new developers and also remind you of
31:45
things that you might have forgotten or you might have forgotten to share with other people on your team. Debugging tools, stuff that helps you out a lot when things break and you need more insight into your system. And the last thing is mentorship.
32:00
Which I'm choosing to define and it's a choice I'll admit it. I'm choosing to define as taking two people on your team who have different skill sets pairing them together in a formal context over a long period of time and having them share their skills with each other. So most of these fall into into sustainability because they're practices that help you build up your team.
32:20
Your team works better together. Your team is more stable. I put mentorship on that crossover with accuracy because it turns out that people who are more skilled end up writing better code. So both the first time as well as keeping again keeping your team healthy in the future. Code review I put in the crossover between accuracy and
32:41
usefulness because code review first of all is just a good check on whether your code is doing what it's supposed to do. But it also creates an opportunity for a conversation about should we be writing this code? Is this the right code to write right now? Is this the right solution to the problem that we're facing? And pairing and mobbing like I said are kind of code review on steroids. The cool thing about it is that it does all those things while also
33:04
building up your team. Building those relationships. I once saw something a Quora answer by Kent Beck where he was asked, you know, so actually someone just asked the world, you know, does Kent Beck believe that pair programming is always a good idea? So Kent Beck, I guess found that and answered.
33:22
He basically said when either the problem space is big the solution space is big or you need to build relationships on a team. Really important to remember that pair programming or mob programming also have that effect. All right, couple miscellaneous items. Continuous integration making sure that your code passes a build before you actually deploy it. Frequent releases.
33:42
Frequent releases kind of self-explanatory. Refactoring, not as a thing that you do once but as a thing that you do constantly always looking to improve the health of your code base. Conventional APIs. Basically using things like rails rest or or JSON API or just you know the normal ways of
34:05
doing stuff in the language of choice, you know things like add a reader and add a writer rather than you know get adder and get you know set adder in Ruby or the opposite I guess in Java. Just you know kind of using the things that people expect. So those fill out kind of all over CI is mainly an accuracy thing. You want to know that your code works.
34:24
Refactoring is on that border between accuracy and sustainability because it helps you write code correctly because usually you're refactoring in the context of writing new code helps you make sure that you got it right. It also helps you keep your code base healthy in the long run. Conventional APIs I put on up top because I think that they are usually well designed and they leave you room to grow in the future.
34:46
And frequent releases. So I did not think of frequent releases as a central practice for a long time. So it's kind of a recent revelation for me, but the truth is when you release things frequently first of all you figure out that things are broken really fast.
35:03
So that I guess helps your accuracy. Helps your sustainability because you're not building castles on top of foundations which you only later find out when you deploy are actually broken and helps out with usefulness because until you've actually shipped any changes that you've made you could think of as inventory, right? You haven't actually created value until you've shipped. And the faster that you ship even a small bit of functionality that the faster
35:24
it's going to create value. Okay, so we've covered a lot of ground we have a pretty diverse strategy, but we're kind of missing something. What goes in that red area? What's going in that usefulness section that we can use to balance out this picture of software quality?
35:42
To me it's practices that that's are centered on user-oriented thinking. The main one which kind of leads to all the others is a focus on delivering value. Rather than thinking about like what's you know a cool thing that we could do now or thinking about it from a very technical like okay, let's build it up you know from the ground up. Just focus on what's the next thing that I can do that will create value for our users.
36:05
To understand that better you have to actually talk to your users. You have to research their needs. You have to you have to if you can collaborate with them the closer collaboration you can do the better you'll be able to actually solve their problems because you'll understand what their problems are. Prioritization, it's really easy to get caught up in like what's what's a cool thing to build?
36:23
But if you're focused on delivering value, they'll prioritize the the actual most important things for delivering value. Discoverability, if you create a really cool feature, but nobody can find it, then you might as well have not done any of that coding because it's useless.
36:41
Empathetic UI was not a term until about three seconds ago as far as I know. I'm sure there's a real term, but what I mean is a UI that thinks about what are the needs of my users? What kind of situations are they going to be in when they're using our software and then how do we anticipate those needs and give them what they need in the way that they need it? On time, it depends on your
37:02
organization and on your users and their needs, but if you're writing tax software really try not to be a year late. Performance. We always think of performance as a computer science thing and and for the life of me, I can't figure out why.
37:21
I mean part of it is because yes, like so much of computer science curricula is about performance. But but it that it doesn't matter for some reason of technical accuracy or anything. It matters because users can't wait forever for for for your your app to work. It's just to meet a user need and when you do performance optimization,
37:41
you have to actually focus on meeting that user need and what are the things that they actually need me to optimize? So that's pretty good in the red area. I'm just going to add a couple more things for technical products. Documentation is the face of your product to your users. If they if they see a distinction between your documentation and what your software actually does, they don't think that your documentation is wrong. They think your software is broken.
38:02
It's something to think about. Writing client code may or may not be relevant in terms of what you're doing. But sometimes if you write a client library that will help your clients use the code that you're creating, the technical product that you're creating, that will actually be of more value to them than just kind of staying on your own making a more robust product. But they have to figure out how to integrate it.
38:22
All right, so that's the whole picture in my mind and there's more practice that I care about but you know, we only have limited time. But this is my brain right here on a slide. There's more to my brain than that but part of my brain. But ultimately in the question of is it quality software? I can't tell you. You have to decide.
38:41
So I'm going to leave you with this. A blank slate. I put it or I'm about to put it on my site. I tried to deploy before and it didn't appear so I'm going to try again right after. But bring this back to your teams. Think about these issues. Think about the practices that you do and that you care about as individuals and as teams and whether there's areas that are missing that are a little patchy in terms of of your software quality.
39:04
All right, so we're gonna wrap up a couple of parting thoughts. Number one is different projects require different balances of factors and actually Ken Beck has his 3x framework. You've been talking about recently. Which points out that even within one project it'll change over time which of these things matter.
39:20
Number two, I don't think it's bad to focus on good code first in terms of career development. Why? Because it's more straightforward. Business understanding takes a really long time to develop. It's really important, but it takes a long time. Good code. You can get really really much better at good code in a scale of months. Maybe a small number of years. And once that happens, by the way, it becomes more automatic. Like you you'll find yourself like
39:43
less able to write bad code if that's if that's a way that I can put it. Business understanding you can't automate. It's something that you have to constantly refresh because there are constantly new business realities. So the implication is start off really focused on good code and then move more into business understanding in terms of your focus as
40:01
you move on. So your career trajectory might look like this. The that middle line sloping down you start out focusing a lot on good code, but then it goes down. Business understanding is kind of coming in in its place. Those lines might cross. Those lines might cross really far if you're going into management or project a product management or stuff like that.
40:21
They might say far apart if you're an architect, but those lines should change over time. That's okay. That's expect. That's a good thing. The main thing is the line on top is how much value are you are you creating? So what can I do to build business understanding? It's basically a matter of learning. It's learning about your users, your industry, the organization of your organization, looking to solve dysfunctions within your organization,
40:42
ideas of business, ideas of organizations and processes. So that there's all that learning, but you also have to become better at empathy skills. And that's my last point is that empathy is going to become ever more important. What can you do to build empathy skills? Number one is read, learn,
41:00
find out about new ideas. Next slide we'll talk about that. But the other part is practice, meaning cultivating curiosity about others, especially if they're different from you, which is really hard. But you have to listen to them. You have to understand their needs and their feelings and see the humanity ultimately in everyone. That will make you a better person and it'll also make you a much more effective
41:20
developer and person in your business. So I started a club or I'm starting a club. It's launching officially at the end of RailsConf. We're gonna be reading books on on empathy. In the software context, in a general context and thinking about how they apply in our professional lives. You can check out the site DevEmpathyBook.Club if you're interested.
41:41
I'd really like there to be more discussion about these things in our community. So, you know check it out. But the bottom line is make your software valuable, high quality, creating value for users and make yourself valuable. I want to thank a few people. I'm not gonna name them there on the slide. But these what I've said today is not my ideas per se.
42:02
They're just my analysis and integration of ideas that I've learned from and through these people. I especially want to call out Gene Westbrook who was my mentor for my first year at Vitals and he's in the room today. So, thank you for for being there for me. And the last thing I'm going to say is
42:20
I spent a lot of time on airplanes to get here 18 hours in the air three flights. So, I'm a little like I have the airline thing still like haunting my dreams. So, I'm just gonna say I know you have a lot of options as to where you can spend your time at RailsConf. Thank you very much for spending it here.