Summarized using AI

Code Design and the Science of Pleasure

Jonas Nicklas • September 29, 2011 • New Orleans, Louisiana • Talk

In his talk at RubyConf 2011, Jonas Nicklas explores the intersection of code design and human pleasure in programming, emphasizing that code should be designed with people in mind rather than just for machines. He challenges the audience to think about the emotional impact of the code they write, similar to principles studied in product design and industrial design.

Key points discussed in the video include:

- The Diversity in Programming Backgrounds: Nicklas highlights the varied backgrounds of Ruby programmers, noting that many do not have formal degrees in computer science, which enriches the community's perspectives and approaches.

- Programming as Design for People: He argues that programming should be viewed as making tools for others rather than for oneself, advocating for coding practices that prioritize the user experiences of other developers and end-users.
- Understanding Personas: Nicklas introduces the concept of personas in software design, stressing the importance of recognizing different user backgrounds, skill levels, and needs when writing code.
- Three Tiers of Product Design: He discusses a model describing three tiers of design that influence user satisfaction: functionality, usability, and pleasure.

- Functionality: The product must solve user problems effectively.

- Usability: The product should be easy to use and not oversaturated with unnecessary features.

- Pleasure: The experience of using the product should be enjoyable, as this fosters engagement and recommendation.

- Types of Pleasures: Nicklas outlines four types of pleasures: physical, social, psycho, and ideal, demonstrating how they relate to product design and user experiences.
- Prototyping and Iteration: He encourages developers to prototype and iterate their designs, stressing the importance of refactoring and maintaining code consistency to enhance user experience.
- Avoiding Anti-Patterns: The talk addresses common coding anti-patterns like feature envy and emphasizes organizing code more effectively.
- Humanizing Code: Nicklas concludes that programmers should add personality to their code, making it relatable and enjoyable to use, ultimately reinforcing that programming should be a pleasurable experience.

The takeaways from Nicklas's presentation encourage programmers to shift their mindset towards designing code that is not only functional and usable but also pleasurable, insisting that programming should be a fun and enriching experience.

Code Design and the Science of Pleasure
Jonas Nicklas • New Orleans, Louisiana • Talk

Date: September 29, 2011
Published: December 12, 2011
Announced: unknown

As Rails programmers we talk a lot about the beauty, not only of the products we build, but the code we write. Why is this beauty important? Can we think systematically about the emotional effects of the code we are writing? Code is meant to be read and used, not just by machines, but perhaps even more importantly by people. How people are affected by the products they use has been studied extensively in the field of industrial design, can we apply these lessons to the code we write?

RubyConf 2011

00:00:17.520 my name is jonas nicholas um i work at a company in gothenburg in sweden called elabs or else consultancy
00:00:25.600 if you're even in town you should come by we have an awesome new office it's pretty cool
00:00:33.040 i'm not not a software engineer i guess many of you who are here today aren't really software engineers i don't really
00:00:39.120 have a formal degree i don't i never went to to college for software
00:00:44.800 engineering or computer science or anything um even close to that um just a quick
00:00:50.160 question how many of you don't actually have a software engineering or cs degree that's pretty much almost
00:00:56.840 everyone does anyone actually have a software digital engineering degree all right
00:01:02.559 that was a couple of people all right okay cool um that's actually one thing i really like
00:01:07.680 about the rugby community we come from all kinds of different backgrounds i have a couple of friends
00:01:13.040 who are artists who got into the ruby community i know a pianist who's now a high profile
00:01:19.680 rubiness rubyist psychologists and business people
00:01:24.960 we come from everywhere and i think that's a that's a really cool thing um and it's a good thing that we sort of
00:01:30.880 share this background of where we come from and that's kind of why why i'm here today um while i was at college i
00:01:36.720 studied um a field called industrial design engineering which is kind of like industrial design but
00:01:42.960 looking at it more from an engineering perspective and i feel that i learned some interesting
00:01:49.119 stuff and that's why i'm here today and that's what i want to share with you guys
00:01:54.320 so we've been talking a lot about what programming is and some people say that programming is
00:02:00.240 engineering and glenn vanderbilt has this really interesting presentation called real software engineering if you haven't seen it you should check it out
00:02:06.640 he talks about how this notion of programming as software engineering is really misunderstood and how we can make
00:02:13.599 a better model out of that and how software how software engineering and programming
00:02:20.480 can be mapped better together and we've also talked about
00:02:26.080 programming as a craft and that's really interesting to me i really like like the idea of sort of
00:02:31.760 learning from master programmers and and sharing our knowledge and learning
00:02:37.519 from each other and we've talked about programming as art and i think they're elements of art
00:02:42.959 and programming but the way i've i've been taught what art is is that art
00:02:50.800 is something you make for yourself whereas design is something you make for someone else
00:02:57.599 i really hope that when we're building software we're building software not just for our own interests but for the
00:03:04.000 for other people who will be working with our code for other people who will be using our software project projects
00:03:10.159 for other people who will be um will be using our libraries
00:03:15.440 i really hope that we're not just making everything for ourselves and i think certainly there are aspects
00:03:21.440 of art and programming um a lot of the stuff that y made i think can be called art um a lot of the sort of more
00:03:29.120 esoteric projects if you were at railsconf this year that had this really amazing presentation i think it was called 99
00:03:35.760 programming languages or something um and they were they were showing off a lot of different languages in a really
00:03:41.280 short space of time it was all very arty and very weird and i think that's fantastic and i i really love that that
00:03:47.120 aspect of programming but even in traditional design there are lots of aspects of art i think we can look at
00:03:53.840 coding as making something for someone else
00:03:58.959 for someone else we could because i think code is designed for people not machines this is for me the sort of principle
00:04:05.439 innovation that ruby came with it's not really different from other languages in a feature perspective it's not really
00:04:11.680 different um from a technical perspective except that it's slower
00:04:17.600 but it is the it it is the first language that was
00:04:23.199 kind of designed with people in mind it was designed to make people happy
00:04:28.479 all other programming languages pretty much were designed with some kind of technical goal in mind perl was designed for shell scripting
00:04:35.759 javascript was designed as a programming language for the web java was designed as a portable cross platform language
00:04:42.479 so always we have a kind of technical motivation for building something whereas with ruby we had a human
00:04:48.400 motivation to make people happy i really want to encourage you to when
00:04:53.520 you're writing code to look at it the same way that you're building your code for people not machines
00:04:59.040 so today i'm going to talk a bit about the theory um a bit of theory behind product design
00:05:05.680 and how we can apply that to our code i'm going to talk about personas i'm going to talk about what makes a
00:05:11.919 well-designed product i'm going to talk about what pleasure is
00:05:17.120 and i'm going to give some practical tips on tools you can use to apply this
00:05:22.960 this knowledge to your software projects so let's talk a bit about personas
00:05:29.680 personas is basically describing what a person
00:05:34.880 using your product is like and in this case your product is your code um so another person using using your
00:05:41.840 product would be another developer and you could be thinking that um well i can just look at myself and
00:05:48.160 look at what i'm like because all the other people who look at this program surely they must be exactly like me
00:05:56.639 but i think you'd be wrong i think you'd find that in this community we we are very diverse and we come from lots of
00:06:03.280 different backgrounds so know who you are designing for who are they and what do they want
00:06:12.319 who is your target audience because you always have a target audience when you're building code
00:06:17.680 your target audience could be just the other developers at your company or the target audience could even be you a
00:06:24.880 month in the future because you've most likely forget gotten pretty much everything about your code
00:06:29.919 at that point know what their skill level is like it's a very different game designing pro code
00:06:35.520 for a haskell programmer as opposed to for a qbasic programmer i remember i i started out when i was
00:06:42.240 seven and i built all this awesome stuff with basic um so obviously a seven-year-old can
00:06:49.360 understand basic but a seven-year-old is not going to be able to understand his skill um
00:06:55.600 i think um even in our community there can be vast cultural differences between um
00:07:01.280 between programmers we come from europe we come from japan we come from america
00:07:07.520 and even being over here i always notice how how hugely different the culture is so keep that in mind
00:07:14.639 what makes a well-designed product one of my personal heroes is a guy called patrick jordan he's a
00:07:20.880 usability expert and he's been working in the field of usability for quite a while um he's been publishing books and holding
00:07:27.680 talks sort of pushing the boundary of what usability is
00:07:32.720 and trying to get companies to take a more holistic view of their products
00:07:39.199 and he's proposed this model of what makes a well-designed product it's basically a three-tier model
00:07:46.800 where in the first year we have functionality if your problem if your product if your code doesn't solve the
00:07:53.039 problem that is that the user wants it to solve is useless to your user
00:08:01.199 and on the second tier we have usability if the user cannot actually physically
00:08:08.240 use your product even if it has the right functionality it is useless to them
00:08:14.720 so for physical products here we're talking about
00:08:20.800 maybe the strength required to move a lever or the distance between controls
00:08:27.120 um anthropometric uh data on people so that
00:08:32.159 um you can actually physically use a product um obviously that's not really
00:08:39.039 as important for us as software people because usually our products aren't physical but
00:08:45.200 here we even talk about cognitive demands understanding things places cognitive
00:08:51.200 strain on people so in order to to be able to understand how something works we need to spend
00:08:57.279 effort and the amount of effort we can spend is limited and the third here in this model is
00:09:03.440 called pleasure and by that he means that
00:09:10.399 if the product is functional if it provides the correct functionality and if it is usable to the
00:09:16.080 user it is then important that the user actually enjoys using the product because if he enjoys the product he's
00:09:22.399 going to use it more and he's going to recommend it more um and in the end it's going to make you more money or fame or
00:09:28.720 whatever it is you you want so let's look at each of these in turn a
00:09:34.880 bit functionality it's actually really difficult to find
00:09:41.600 examples of of products which do this really badly because most of the most of the products that do
00:09:48.480 this badly um just fail very early on and i never heard from again this is one
00:09:54.160 of those examples it's called the itop it's a wearable dvd player which you can
00:10:00.000 so you can watch dvds while you're walking around town or while you're driving your car
00:10:08.800 terrible idea right absolutely terrible idea and unsurprisingly i totally failed um no
00:10:16.160 one wants to watch dvds while they're driving around their car um or at least i hope they don't uh
00:10:22.800 i i think this is this is an i i really struggle to find an example for this from the ruby community uh i think this
00:10:29.600 is this is this might be one um jewel kind of um
00:10:36.000 makes you move your gem spec file from your gem select file to your rake file and then generate the gem spec file
00:10:41.519 again i don't really know how that's useful at all um when you can just write the gemstric
00:10:46.720 file to begin with so i don't know a lot of people still use it
00:10:54.240 google i think did this really well when google came into the market
00:10:59.600 what they came with and what they brought to the market wasn't some kind of superior usability i think the clean
00:11:06.079 innovation interface they had one was pretty innovative but i think what really made them
00:11:11.279 successful was that they were the first ones to actually get the functionality
00:11:16.480 right people were sort of screaming for a better search engine it was really tough finding good stuff on the web i remember
00:11:22.640 in the early days i was sort of constantly switching back between different search engines trying to find something and it never really quite
00:11:28.560 worked and then google came and it was like whoa so they they got the functionality right
00:11:34.560 also php at a time when web development was really complicated they just
00:11:41.360 came with everything that you needed built into the language it had a
00:11:46.480 templating system it had database drivers that everything built in so it just had all the right functionality it
00:11:51.839 might not have been the super most pleasant experience out there but they got the functionality right and
00:11:57.760 that made them win so if we look at that second tier layer usability we can see stuff like
00:12:04.720 microwaves i hate microwaves death to microwaves my
00:12:10.079 microwaves are terrible um because they always look like this essentially a microwave is a very simple
00:12:17.360 thing you put food on it and you make it warm um and it should really have two controls time and power and nothing else
00:12:25.120 um what are all these 15 million buttons for i have no idea it's like a pizza functionality and like i don't know you
00:12:32.079 can play tetris on it i think it's completely ridiculous but
00:12:39.200 i think the reason that um that microwaves do this is kind of interesting it's because it sells
00:12:45.360 um people look look at this and they think that whoa it must be advanced um
00:12:51.120 and i think that's that's really why why they do this not not because it's better but because it sells more
00:12:57.920 um j2ee i think is a fantastic example of
00:13:03.120 of terrible usability um i'm a web developer um and when i look at the
00:13:08.480 documentation for this stuff i don't even understand how it works i don't think anyone understands how how
00:13:14.160 it works i don't think the people who build it understand how it works um so yeah
00:13:19.200 terrible from a usability point of view 37 signals do this really well i think um
00:13:25.519 sinatra is a really cool example of of a good usability i think um
00:13:31.360 they they've sort of um distilled web development down to to its simplest
00:13:37.920 its simplest form and if you look at the the first example they provide the hello world example it's just so beautifully
00:13:44.160 simple um so i really think that's a that's a good example of of this this tier
00:13:50.000 um and finally pleasure um atms they are terrible at this
00:13:57.199 they get the right functionality they give me money i like that um they're pretty usable everyone can understand
00:14:03.760 how an atm works but they're usually miserable to use they're slow they're clunky they're ugly
00:14:11.120 it's just not very pleasant to use them also java um
00:14:17.920 um i i think this is this is really where java kind of fails it's it's got the
00:14:24.240 right functionality it's a it's a very capable programming language it's fast it's it's very good
00:14:30.959 it's also got the usability it's very easy to learn i would i would say it's easier to learn than ruby um it's
00:14:36.560 quite a small programming language at its core but it's just a miserable experience to
00:14:42.880 use it it's just so worthy and so so clunky and you need all these
00:14:48.000 extra tools and all the tools are terrible and it's just an unbearably terrible experience
00:14:55.360 and also the google maps api i think it's the same thing it's it's easy to understand it does the job
00:15:01.279 but it's just not very pleasant to use um bmw i think is a company who does this
00:15:07.360 really well they really look at their product holistically and they tried in in every
00:15:12.560 way to make it as nice as possible also apple obviously i think i think actually
00:15:17.839 this is where apple wins um people often talk about the this usability of apple
00:15:23.440 products and actually think their usability is not much better um than their
00:15:29.279 competitors um they've they they've always been very innovative but i think their competitors have
00:15:35.360 caught up and now if you look at an android phone and an iphone the android phone is actually not harder to use um
00:15:42.480 but the iphone is nicer to use this is more pleasurable to use so i think this is where apple wins and i also think
00:15:49.199 this is where ruby wins i think ruby is the one of the only languages i think
00:15:55.040 coffeescript is another one one of my favorites and i i place it here as well but um ruby is one of the one of the
00:16:00.880 only languages to really look at this top tier and to look at this um
00:16:06.160 pleasure tea and to try to improve that so let's look at pleasure in more detail
00:16:12.480 um again my friend patrick jordan that's why i'd like to call him my friend um
00:16:20.240 he's he's been uh talking about this four pleasures model and that was originally um proposed by a guy called
00:16:26.639 lionel tiger who has the most awesome name in history um i would want to be
00:16:32.399 called lionel tiger um yeah so so lionel tiger proposed this
00:16:39.360 model of the four pleasures um this is what he actually looks like um i
00:16:44.399 still think he looks pretty badass um
00:16:49.440 and the model goes like this it's um physio pleasure pleasures social pleasures psycho pleasures and ideal
00:16:55.600 pleasures and i'm going to go over these in turn and explain a little bit more about what
00:17:01.040 they mean physio pleasures as you can guess from the names and pleasure to everything related to the physical world
00:17:07.039 so um things your senses pick up touch smell um
00:17:12.480 taste possibly i don't know if you swallow your products usually um
00:17:18.000 that that kind of thing um so um
00:17:23.199 for us as software developers it's not really very irrelevant um our products usually don't
00:17:30.080 manifest in the physical world i hope um
00:17:36.000 on the other hand social pleasures might be very relevant to us maybe not so much for the actual code in our
00:17:42.400 in our projects as for everything around them social pleasures are how you relate to other people
00:17:48.559 um how you you are seen your self-image status among your peers those sort of
00:17:54.000 things linux is terrible at this i think
00:18:00.480 they've sort of managed to position themselves in a place where linux is for nods
00:18:06.880 and if you don't and if you use linux you sort of self-identify as a nod and i think this
00:18:13.760 prevents a lot of people from using the product i think a lot of people would be very happy using linux but they are
00:18:19.919 turned off by this idea of having to appear as part of this social circle
00:18:26.000 so i actually think this is kind of hurting the adoption of linux in the desktop marketplace
00:18:31.280 um also quite recently in our community rbn came out as an alternative to rvm
00:18:40.160 and the um the author of the project said some not so nice things about rvm and the in the
00:18:46.799 project's readme which got a lot of people very upset wayne is a very
00:18:51.919 wayne segwin the guy who wrote ivm is a very well-liked person in the community and
00:18:56.960 and so a lot of people came to side and supported him and said we're not going to use rbn just because
00:19:03.360 the guy who wrote it was kind of being a dick in the readme
00:19:09.520 and um so these kinds of things do have an impact on what people what people choose
00:19:16.880 a good example here would be something like this product it's called the novel pen which is a product for diabetics um
00:19:22.880 to to measure their insulin levels um and the idea here is that um
00:19:29.520 to make it look as innocuous as possible so that people who use this product don't feel like there's some kind of
00:19:35.919 part of some kind of diseased or
00:19:42.080 sick culture it feels more like an everyday device like it looks like a pen it just looks normal
00:19:49.120 and the idea is to help diabetic people feel more normal and so in that sense it provides
00:19:55.440 social pleasure ruby on rails i think has a really interesting relationship with this
00:20:02.240 because in a sense ruby on rails through its code and through also through its community
00:20:10.559 has sort of provided a feeling of
00:20:18.480 expertise and we're really good at this and uh sort of sort of an elite clique
00:20:23.679 of developers and i i think that's both a good thing for people coming into this community to feel like um they are part
00:20:30.640 of a really great group of people but it also makes
00:20:35.679 people outside the community look on us as kind of arrogant
00:20:41.039 and i think that's a problem because it means that people who come into this community kind of feel
00:20:46.640 that they don't want to be perceived as part of this
00:20:52.880 fanboy ruby on rails
00:20:58.559 clique and i actually think this is driving some people away from the community
00:21:07.679 so what can you do to improve these things be inclusive um think about everyone who would want to use that use
00:21:13.919 your product and try not to not to exclude them be humble when you when you talk about
00:21:20.960 other projects most likely you've learned something from them so give credit
00:21:27.280 even you've probably even learned something from the failings of other projects so be humble about that your
00:21:32.559 project is probably going to fail in one way or another and some smartass is going to stand there and point it out
00:21:39.840 just be friendly in general be friendly to other people trying to understand your code be friendly um
00:21:47.360 on on mailing lists if you're running an open source project
00:21:54.559 i know it's hard people come asking stupid questions all the time um and you just want to sort of
00:22:02.080 um tell them to go read the manual um but just
00:22:09.440 think about the fact that you might be in that position at some point just be friendly
00:22:15.440 so next up psycho pleasures contribute to what you might think this is not about designing the perfect
00:22:21.600 business card or explaining the benefits of huey lewis and the news
00:22:30.080 psycho pleasures are about your emotional reaction to things
00:22:36.480 about frustration for example or the joy of having something
00:22:42.799 work simply about your cognitive response to your product
00:22:49.600 so a bad example would be cassandra the nosql database i don't know if you've guys if you guys have ever looked
00:22:55.840 into that um but it basically um gets the naming of everything wrong
00:23:02.159 um things don't really map to what you
00:23:08.159 would expect them to be called and there's actually tables on the internet where there's this is what it's called in cassandra and this is what it should
00:23:14.240 have been called because that would have made a lot more sense um so um
00:23:19.600 that actually makes it a lot harder to get into into it as a as a project and makes it very frustrating in the
00:23:25.280 beginning is because you can constantly have to sort of map over
00:23:30.320 what you would actually want and things to be called also soap is miserable or miserable in
00:23:36.000 this experience because you always think that you've got it figure figured out and then you realize that you don't
00:23:42.480 sinatra again i think is very good in this aspect also text mate i think when it first came out
00:23:48.480 editors are hard right um and textmate just had this air of being easy and not being accessible um
00:23:55.679 and i think when david um demoed rails for the first time and i think when was it 2005 or something i think that was a
00:24:02.080 big part of the draw this very simple editor that he was using which is just pretty and nice and and human
00:24:10.559 so make it easy for people to get going provide good examples
00:24:15.919 be consistent uh if things look similar they should work the same way
00:24:21.919 and make it smaller um smaller components are always easier to understand than big components
00:24:28.080 so split your projects into smaller parts finally ideal pleasures
00:24:36.159 all right i should explain what this is ideal pleasures are pleasures relating to your values to your perception of the
00:24:43.440 world to your ethics to your religious beliefs maybe those kinds of
00:24:49.039 things um we here we have for example this library in
00:24:54.720 which came up in the ruby community called red carpet which i'm not going to go into how but it's a
00:25:01.200 sexual pun and this made a lot of people very angry um and they said it was
00:25:06.320 misogynistic um and um it's not really important whether it is
00:25:12.400 or it isn't the the point is that
00:25:17.760 people felt that uh felt uncomfortable using this product um
00:25:23.919 and this in turn made it less pleasurable for them to use the product than if it
00:25:29.120 would have been given a more neutral name ruby cones is a counter example um
00:25:36.640 we're sort of trying to i think follow the values of most people in this
00:25:42.960 community to try to to get people who aren't usually into programming into programming and
00:25:50.400 and teaching them and then another good example i think is
00:25:56.159 aspect just because it sort of embodies the values of this commun community of
00:26:01.279 communication of expressiveness of creativity
00:26:06.480 um when it first came out i think it really sort of changed um and changed the game
00:26:13.200 and that um up until then all testing frameworks and almost all the libraries
00:26:18.480 of any kind were kind of written from from a machine perspective if you look
00:26:23.600 at test units it's very focused on on
00:26:28.720 on just working with machines whereas aspect was meant for communication it
00:26:33.919 was meant for people so know your audience know who you're working for working for don't be afraid
00:26:41.120 to adopt an aesthetic i really think that's that's one of the key things you can do to make your code more human i really
00:26:47.360 like for example machinist in this aspect if you ever use that a factory girl to sort of um
00:26:54.000 adopt an aesthetic of this idea of of a machine worker building stuff um and it
00:26:59.520 shows not only in in the name of the library but actually in the code itself and i think that's a really nice thing
00:27:04.880 to do i think that's a that's a good way to make your code more human consider cultural differences because we
00:27:11.200 are a global community and what might be considered offensive in one place
00:27:16.240 could be fine in another and you wouldn't even know so this is one way of
00:27:22.559 mapping cultural differences i'm not going to go into this a lot but these are five different vectors against which
00:27:28.480 you can map a culture um and this is backed by some science and according to
00:27:34.960 these you can cluster cultures into different groups and that's really interesting and i encourage you to check that out but
00:27:40.640 that's really a topic for a presentation in of itself so i'm not going to go into that too much here
00:27:48.640 um so let's get into the practice of things
00:27:55.200 and i'm just going to check i don't have a clock yes okay um right
00:28:04.559 prototyping i think this is a really important tool and i think it's very underused
00:28:11.600 don't be afraid to build stuff and throw it away to sketch out ideas um even even
00:28:17.200 if you're just writing code as part of your normal application try different things try to see what
00:28:23.919 works try different ideas so for for
00:28:29.120 for entire projects this idea of readme driven development was was proposed and i really like that um
00:28:37.919 i really like the idea of writing a narrative first and to to sort of look at
00:28:43.840 who is your audience what would they want to use this for can you give a typical use case
00:28:50.080 what would a normal example of this look like and so on and so forth so write your examples first um
00:28:58.080 also this idea of top-down design i think that's really um that really helps with this if you're building the top
00:29:04.320 layer for say in say in a rails app you're building your controller um
00:29:10.240 then you've already sketched out which model methods you need you've already sketched out
00:29:15.520 how you're going to talk with the underlying layer even though you actually haven't written that code yet i think that's immensely useful useful
00:29:22.320 because then you can try different ideas in your controller very cheaply you can see that yeah this interface looks
00:29:28.640 really nice and i would like to use something like this and even though it's not built yet
00:29:33.679 you can play around with that this is something we talked about at college a lot kill your darlings
00:29:41.279 the idea is that you might come up with an idea of the top of your head and you cling to that idea
00:29:48.480 you think that this is the best possible solution and it prevents you from trying out
00:29:54.240 different stuff so if you come up with an idea for solving a problem don't be afraid to just put it aside
00:30:01.039 and try something else try something new maybe you could use a block instead maybe you could use a hash argument
00:30:08.799 maybe you could use a module or a class or whatever there are lots of different design tools we have on our belt and
00:30:14.559 ruby so don't be afraid to to chuck out the initial idea you had and to try something else
00:30:21.760 and iterate try lots of different stuff
00:30:26.880 refactoring i really think this is the most important tool you have as a software developer developer refactoring
00:30:32.799 is hugely underrated talk a lot about tdd
00:30:39.200 and often tdd is is taken as write a test and make it pass
00:30:46.080 but i think this is much better red green refactor this is a much better motor because if you're just writing a test
00:30:52.399 and making it pass i think you're missing the most important benefit of tdd which is that it makes refactoring
00:30:58.240 easier so how do you refactor don't change
00:31:04.720 functionality if you're changing functionality you're just changing you're not refactoring at all um
00:31:10.159 so um um we sort of lose with with the word refactoring and i'm guilty of that
00:31:16.000 myself we say like yeah i refracted this code to do something else but that's not really a refactoring
00:31:25.039 don't change the interface even if you're refactoring just look at for example a method or
00:31:31.679 something and just change the code below it um then you're truly refactoring um and
00:31:37.679 that also means don't change tests a lot um as you're making these changes you want
00:31:43.919 you want your tests to stay roughly the same this is kind of why i don't like mocks so much because i think they um
00:31:51.679 they expose too much of the internals of the code to the test um and i i know there was a talk about this
00:31:58.720 this morning and i'm probably wrong but this is
00:32:04.559 this is why i tend to prefer to not not to use marks
00:32:10.000 i want to talk about anti-patterns and i want to talk about a particular anti-pattern i want to talk about feature envy
00:32:16.240 i really think this is the most commonly occurring anti-pattern in code
00:32:22.640 it just basically means that shit's not in the right place so um you have code in one class which
00:32:30.320 is supposed to be in another um you are you have given this object responsibilities which it's not supposed
00:32:36.799 to have so i just want to illustrate this with a with an example can you guys read that
00:32:44.880 so this this invoice which has a payment method does a lot of credit card stuff
00:32:51.760 and this method i think is pretty ugly um but in order to change it you could
00:32:57.039 think that oh yeah i could iterate over all these different um credit card
00:33:02.399 number and credit card date and set all of those or something to that effect um
00:33:08.640 but actually um in this in this code um we have a lot of stuff here about credit
00:33:14.000 card processing which really doesn't have anything to do with the invoice so maybe we should extract that into its
00:33:19.200 own object um and we're doing a lot of stuff with this this order object
00:33:25.039 with this order association and
00:33:31.120 also that doesn't really belong here so we could change it to something like this where we're initializing a credit
00:33:36.640 card we're asking it if it's it's valid and we're checking for the balance and now we can do these microwave
00:33:42.320 refactorings and make it look somewhat nicer
00:33:47.760 so does everything have the right name and is everything in the right place those are i think the the really
00:33:54.080 important questions to ask yourself when you're doing refactoring consistency and style
00:34:01.679 this is i think the worst thing you can do when designing code rails has this nice method called link
00:34:08.000 to which takes a text in a destination and you would expect it's just the method
00:34:13.760 mail to to do the same but actually it doesn't it's the other way around
00:34:19.839 mail to destination and text um this is this is i think the worst thing you can do in in code just
00:34:26.879 when you have similar stuff make it consistent it's not important which style you pick just pick one
00:34:34.159 don't be afraid to add some flavor to your code i think it's really important for code
00:34:39.359 to have a personality and you would think that that would sort of take the code back to being art
00:34:47.040 but i think it really takes it to being design because design usually does have
00:34:53.119 personality so make your code human because programming is fun
00:34:59.119 um this is sort of what i want to take you and what i want you to take for away from this presentation make your code a
00:35:04.800 pleasure to reuse and modify thank you guys
00:35:50.880 you
Explore all talks recorded at RubyConf 2011
+55