The ultimate software development tool

Best practices on project management, issue tracking and support

Category: Coding (page 1 of 2)

10X Programmer and other Myths in Software Engineering


We’ve interviewed Laurent Bossavit, a consultant and Director at Institut Agile in Paris, France. We discuss his book ’The Leprechauns of Software Engineering’, which debunks myths common in Software Engineering. He explains how folklore turns into fact and what to do about it. More specifically we hear about findings of his research into the primary sources of theories like the 10X Programmer, the Exponential Defect Cost Curve and the Software Crisis.

Content and Timings

  • Introduction (0:00)
  • About Laurent (0:22)
  • The 10X Programmer (1:52)
  • Exponential Defect Cost Curve (5:57)
  • Software Crisis (8:15)
  • Reaction to His Findings (11:05)
  • Why Myths Matter (14:44)

Transcript

Introduction

Derrick:
Laurent Bossavit is a consultant and Director at Institut Agile in Paris, France. An active member of the agile community he co-authored the first French book on Extreme Programming. He is also the author of “The Leprechauns of Software Engineering”. Laurent, thank you so much for joining us today, can you share a little bit about yourself.

About Laurent

Laurent:
I am a freelance consultant working in Paris, I have this great privilege. My background is as a developer. I try to learn a little from anything that I do, so after a bit over 20 years of that I’ve amassed a fair amount of insight, I think, I hope.

Derrick:
Your book, “The Leprechauns of Software Engineering”, questions many claims that are entrenched as facts and widely accepted in the software engineering profession, what made you want to write this book?

Laurent:
I didn’t wake up one morning and think to myself, ‘I’m going to write a debunkers book on software engineering’ but it actually was the other way around. I was looking for empirical evidence anything that could serve as proof for agile practices. And while I looked at this I was also looking at evidence for other things which are in some cases, were, related to agile practices for instance the economics of defects and just stuff that I was curious about like the 10X programmers thing. So, basically, because I was really immersed in the literature and I’ve always been kind of curious about things in general, I went looking for old articles, for primary sources, and basically all of a sudden I found myself writing a book.

The 10X Programmer

Derrick:
So, let’s dig into a few of the the examples of engineering folklore that you’ve examined, and tell us what you found. The first one you’ve already mentioned is the 10X programmer. So this is the notion that there is a 10 fold difference between productivity and quality of work between different programmers with the same amount of experience. Is this fact or fiction?

Laurent:
It’s actually one that I would love to be true if I could somehow become or if I should find myself as a 10X programmer. Maybe I would have an argument for selling myself for ten times the price of cheaper programmers. When I looked into it, what was advanced as evidence for those claims, what I found was not really what I had expected, what you think would be the case for something people say, and what you think is supported by tens of scientific studies and research into software engineering. In fact what I found when I actually investigated, all the citations that people give in support for that claim, was that in many cases the research was done on very small groups and not extremely representative, the research was old so this whole set of evidence was done in the seventies, on programs like Fortran or COBOL and in some cases on non-interactive programming, so systems where the program was input, you get results of the compiling the next day. The original study, the one cited as the first was actually one of those, it was designed initially not to investigate productivity differences but to investigate the difference between online and offline programming conditions.

So how much of that is still relevant today is debatable. How much we understand about the concept of productivity itself is also debatable. And also many of the papers and books that were pointed to were not properly scientific papers. They were opinion pieces or books like Peopleware, which I have a lot of respect for but it’s not exactly academic. The other thing was that some of these papers did not actually bring any original evidence in support of the notion that some programmers are 10X better than others, they were actually saying, “it is well known and supported by ‘this and that’ paper” and when I looked at that the original paper they were referencing, they were in turn saying rather than referencing their own evidence, saying things like “everybody knows since the seventies that some programmers are ten times more than others” and very often after chasing after all the references of old papers, you ended up back at the original paper. So a lot of the evidence was also double counted. So my conclusion was, and this was the original leprechaun, my conclusion was that the claim was not actually supported. I’m not actually coming out and saying that its false, because what would that mean? Some people have taken me to task for saying that all programmers are the same, and that’s obviously stupid, so I can not have been saying that. What I’ve been saying is that the data is not actually there, so we do not have any strong proof of the actual claim.

Exponential Defect Cost Curve

Derrick:
There is another folklore item called the “exponential defect cost curve”. This is the claim that it can cost one dollar to fix a bug during the requirements stage, then it will take ten times as much to fix in code, one hundred times in testing, one thousand times in production. Right or wrong?

Laurent:
That one is even more clear cut. When you look at the data and you try to find what exactly was measured, because those are actual dollars and cents, right? So it should be the case, at some point a ledger or some kind of accounting document originates the claim. So I went looking for the books that people pointed me to and typically found that rather than saying we did the measurements from this or that project, books said or the articles said, ‘this is something everybody knows’, and references were ‘this or that article or book’. So I kept digging, basically always following the pointers back to what I thought was the primary source. And in many cases I was really astonished to find that at some point along the chain basically someone just made evidence up. I could not find any solid proof that someone had measured something and came up with those fantastic costs, sometimes come across like, fourteen hundred and three dollars on average per bug, but what does that even mean? Is that nineteen-nineties dollars? These claims have been repeated exactly using the same numbers for I think at least three decades now. You can find some empirical data in Barry Boehm’s books and he’s often cited as the originator of the claim. But it’s much less convincing when you look at the original data than when you look at the derived citations.

The Software Crisis

Derrick:
There is a third folklore, called “The Software Crisis”. Common in mainstream media reporting of large IT projects. These are studies that highlight high failure rates in software projects, suggesting that all such projects are doomed to fail. Are they wrong?

Laurent:
This is a softer claim right, so there’s no hard figures, although some people try. So, one of the ways one sees software crises exemplified is by someone claiming that software bugs cost the U.S. economy so many billions, hundreds of billions of dollars per year. A more subjective aspect of the notion of the software crisis, historically what’s interesting, is the very notion of the software crisis was introduced to justify the creation of a group for researching software engineering. So the initial act was the convening of the conference on software engineering, that’s when the term was actually coined and that was back in 1968, and one of the tropes if you will, to justify the interest in the discipline was the existence of the software crisis. But today we’ve been basically living with this for over forty years and things are not going so bad, right? When you show people a dancing bear one wonders not if the bear dances well. That it dances at all. And to me technology is like that. It makes amazing things possible, it doesn’t always do them very well but its amazing that it does them at all. So anyway I think the crisis is very much over exploited, very overblown, but where I really start getting into my own, getting on firmer ground is when people try to attach numbers to that. And typically those are things like a study that supposedly found that bugs were costing the U.S. sixty billion dollars per year and when you actually take a scalpel to the study, when you read it very closely and try to understand what methodology they were following and exactly how they went about their calculations, what you found out is that they basically picked up the phone and interviewed over the phone a very small sample of developers and asked them for their opinion, which is not credible at all.

Reaction to His Findings

Derrick:
What is a typical reaction to your findings debunking these long held claims?

Laurent:
Well, somewhat cynically it varies between, “Why does that matter?” and a kind of violent denial. Oddly enough I haven’t quite figured out why, what makes people so into one view point or the other and there’s a small but substantial faction of people who tell me ‘oh that’s an eye opener’ and would like to know more, but some people respond with protectiveness when they see for instance the 10X claim being attacked. I’m not quite sure I understand that.

Derrick:
So how do myths like these come about?

Laurent:
In some cases you can actually witness the birth of a leprechaun. Its kind of exciting. So, some of them come about from misunderstandings. I found out in one case for instance that an industry speaker gave a talk at a conference and apparently he was misunderstood. So people repeated what they thought they had heard and one thing led to another. After some iterations of this telephone game, a few people, including some people that I know personally, were claiming in the nineties that the waterfall methodology was causing 75% failure rates in defence projects, and it was all a misunderstanding when I went back and looked at the original sources the speaker was actually referring to a paper from the seventies which was about a sample of nine projects. So not an industry wide study. So I think that was an honest mistake, it just snow-balled. In some cases people are just making things up, so that’s one way to convince people, just make something up. And one problem is that it takes a lot more energy to debunk a claim than it takes to just make things up. So if enough people play that little game some of that stuff is going to just sneak past. I think the software profession kind of amplify the problem by offering fertile ground, we tend to be very fashion driven, so we enthusiastically jump onto bandwagons. That makes it easy for some people to invite others to jump, to propagate. So I think we should be more critical, there has been a movement towards evidence-based software engineering which I think is in some ways misguided, but is good news to my way of thinking that anyone is able to think, maybe we shouldn’t be so gullible.

Why Myths Matter

Derrick:
Even if the claims are in fact wrong, why does it matter?

Laurent:
To me, one of the key activities in what we do, its not typing code, its not design, its not even listening to customers, although, that comes close. The key activity that we perform is learning. We are very much a learning-centered profession so to speak. Because the very act of programming when looked at from a certain perspective is just about capturing knowledge of the world about businesses, about… other stuff that exists out there in the real world or is written about that is already virtual, but in any way capturing knowledge and encoding that knowledge, capturing it in code, in executable forms, so learning is one of the primary things that we do anyway already. I don’t think we can be good at that if we are bad at learning in general in a more usual sense. But what happens to those claims which are easy to remember, easy to trot out, they act as curiosity stoppers, basically. So they prevent us from learning further and trying to get at the reality, at what actually goes on in the software development project, what determines whether a software project is a success or failure, and I think that we should actually find answers to these questions. So it is possible to know more than we do right now, I am excited every time that I learn something that makes more sense for me that helps me have a better grip on developing software.

Derrick:
Are there any tell-tale signs that we can look out for to help stop ourselves from accepting such myths?

Laurent:
Numbers, statistics, citations, strangely. I know that citations are a staple inside of academic and scientific writing but when you find someone inside the software engineering profession that is whipping out citations at the drop of a hat, you should take that as a warning sign. And there is more but you know we would have to devote an hour or so to that.

Derrick:
Thank you so much for joining us today, it has been great.

Laurent:
Thanks for having me, bye

A Guide to Developer Mentoring

 

In this interview with Rachel Ober, Senior Developer at Paperless Post, we discuss developer mentoring. Rachel teaches us the lessons learned from mentoring developers at Paperless Post, General Assembly, Turing School and beyond. These cover how to get started, tips on building successful mentor-mentee relationships, the benefits of mentoring as well as common mistakes. She writes more about teaching and mentoring on her blog.

Content and Timings

  • Introduction (0:00)
  • The Benefits of Mentoring (0:47)
  • Mentoring Myths (3:30)
  • Tips for new Mentors (6:20)
  • Successful Mentor-Mentee Relationships (7:52)
  • Finding Mentors and Mentees (9:53)

Transcript

Introduction

Derrick:
Rachel Ober is a Senior Developer at Paperless Post, and an experienced mentor. She’s a Ruby On Rails instructor for General Assembly, Co-organizer of the Write/Speak/Code conferences, and Founder of the New York chapter of RailsBridge. Rachel, thank you so much for joining us today. Do you have a bit to share about yourself?

Rachel:
Sure. I work as a a Senior front-end developer at Paperless Post. I work with a team of five other front-end developers building the different pretty things that you see on our website. I feel that it’s really important to kind of build your team around what you want to see in the work that you do.


“Be fearless and say, ‘Hey, I need help on this!’”


The Benefits of Mentoring

Derrick:
I kind of wanted to focus our conversation a bit around mentoring. You seem to have a lot of experience with that, so what are some of the benefits you’ve seen of mentorship?

Rachel:
Some of the benefits that I’ve seen about mentorship are a two-way street between the mentee and the mentor. For the mentee obviously the biggest benefits that you’ll see is that they will have confidence in their work, they have somebody that they can talk to or just sling questions back and forth. They trust this mentor relationship to be realistic, not just telling you what the mentor thinks the mentee wants to hear. You don’t feel as a mentee, that your trying to impress this other person. It’s a much more open relationship. For the mentor, for me it’s a gigantic reminder of where I’ve come from as well as … I’ve been working with Ruby on Rails now since I think 2005. Wow, that’s like a decade. Every time I meet somebody who’s just learning or is a few years behind me in terms of their career, I learn new ways of thinking about problems. I think mentoring is really a great relationship for both people.

Derrick:
How should people go about getting started with mentoring within a company?

Rachel:
As an individual person, it’s great to talk to people and to first gauge other people who would be interested in participating in something like that. Now at Paperless Post we are pretty equal between our Engineering Department as well as the other people in our company. We have people who design cards, people who are in charge of marketing, so it would be good as an individual to kind of weigh whether or not you’re looking for mentoring for the entire company or just to the Engineering department to figure out what your expectations are and what your goals are for your mentoring program. At that point you might get a group of people together to start some type of pilot program.

I would say even asking HR what their opinions are and whether or not doing some type of mentoring program, an official one, at your company, would be something that they would also support. Obviously having upper management is going to make sure that this is actually going to get integrated into your culture, you company culture. They will support you making sure that you’re following up with them. Maybe it can even be integrated into your review process that might happen once or twice a year.


“I would advise against having your mentor be your manager”


Mentoring Myths

Derrick:
What are some myths that stop people from getting into mentoring?

Rachel:
The biggest one is that people think that they don’t have anything to offer. I think it’s probably tied into Impostor Syndrome. That they think that they would instead hurt the other person maybe, or that they don’t have any accomplishments to really share with a person to be a role model. I think that is definitely not true. My most successful relationship with a mentor, was whenever I did admit to her my weaknesses and saying, “Hey, I had this issue right out of college. I worked at a place for a year and it was a really bad relationship for both ends. It wasn’t the right hire, it wasn’t the right fit.” She was able to admit to me that one of her biggest challenges, and after that mark in our relationship, I saw a great change in her where she believed then that because I had admit to this great failure in my life or this personal failure that I felt about, that she could kind of open up, admit that she was having difficulties in certain areas, and be able to regain her confidence, move forward, and do an excellent job.

I think especially with people who are just learning the program, they have this idea … It’s kind of strange because when I was learning how to be a developer, or learning about development in general, there was very stereotypically, you spend all day in front of the computer. Now it seems like it’s turned into something glamorous, because you have this ability to change your life and to earn a lot of money by becoming a computer software developer. My first class that I taught at General Assembly somebody asked me, “What does your daily life look like at Paperless Post?” I said, “Seriously I spend most of my day trying to fix bugs and most of the time it doesn’t work.” I think I blew his mind.

It was a very interesting experience, but you as a mentor, just by explaining what your daily life is and how you interact with other people on your team, is some really fantastic advice for somebody who is either thinking about becoming a developer, or about to take that step after either graduating college or taking one of these code boot camps. Just giving your experience is very valuable. They want to know how you go about interviews, and obviously if you currently have a job you’ve been through a couple of interviews. Nobody just gives you a job usually. That type of advice is just invaluable for somebody who really has no point in which to reference.

Tips for new Mentors

Derrick:
Any additional tips that you can give for new mentors about the types of things that they should be doing with their mentees to help them learn?

Rachel:
The tips that I give to people that are thinking about getting into mentoring, or people who are looking for mentors, is to really start off the relationship figuring out what the goals of the relationship are. Figuring out how often you’re going to meet, how long these meetings are, whether or not you’re going to have some type of assignment that that this mentee is going to give, and how involved your mentor relationship will be. I’ve had different relationships … Some of it is based on just talking. Talking through issues, and more of the social aspect of becoming a developer or navigating either their job or their learning environment. Other relationships have been very deep into code, working through problems, and learning how to break down problems.

I think figuring that out earlier, it really puts everything out on the table and saying like, “This is what I’m having issues with. This is what I’d like to improve on,” and just kind of like talking about each other, talking about yourself. I feel like it’s very hard at least for me to go in and start getting advice, if I don’t know at least the motivations for the mentee. What they want to learn, how they want to see themselves in a couple months after we’ve been working together.


“Having a whole network of people will really help you share your success in achieving your goals”


Successful Mentor-Mentee Relationships

Derrick:
What do you think are the essential elements of a successful mentor-mentee relationship?

Rachel:
I think that successful elements are definitely meeting regularly. I don’t think kind of having on the fly meetings is really helpful for either person. As a mentee you want to make sure that you’re checking in and goal setting. Making sure these goals are met and that you have this accountability person. Your accountability partner, that you are actually fulfilling the things that you set out to do. I think if you are a mentor and you see that your mentee is not fulfilling these requirements, then you have to have like a really good heart-to-heart and say, “Hey, I’m putting in this time. I’m volunteering, I’m not getting paid for this, and I chose to help you because I really believe that you can do some amazing things.”

Sometimes guilting them helps. If they’re part of a Code school you can contact their teacher or the administration and say, “Hey you know, we set up this relationship and I wanted to check in with them. Have you noticed anything on their side?” You don’t want to be meddling, but you also want to set yourself up for success both as a mentee and as a mentor. Keep assessing the relationship, making sure that it’s working, and also if you are a mentor, being knowlegeable of what they are learning or what their work entails, and anticipating questions that they may have. I think just being yourself and admitting whenever you don’t know what the answer is, or giving them advice on other people to talk to. Just being realistic about yourself, where you’ve been and giving that advice to somebody else, is really the crux of a relationship like that.

Finding Mentors and Mentees

Derrick:
Where can people find mentors, or people to mentor?

Rachel:
That is a very interesting problem. I don’t think it’s easy to find a mentor, because there’s a certain level of trust and understanding. For me, I have always mentored other people. I’ve found mentees with volunteering for Code schools. I’ve mentored students from the Turing School out in Colorado, which may sound odd since I’m in New York city, but I’ve been fairly successful working with people over Google Hangouts and Screen Hero, and Slack, and just leaving myself available over text message and phone. I’ve also mentored people either through organizations that I work through … I would say that’s mentorship even if maybe you haven’t said exactly what that relationship is, or have a steady schedule. Also through the classes that I’ve taught at General Assembly. People asked to meet regularly, they want really advice on where to go next. They become voracious and they want to learn as much as they can.

For me, I’ve been searching for my own mentor for awhile. I’m particularly looking for somebody who is five to ten years ahead of me in their career. It took me a little while to kind of formulate the idea of what I was looking for in my relationship. As a woman it was important for me to find a woman who was doing the type of thing I wanted to be doing. I had to really extrapolate and think about what I wanted to be doing in five to ten years. Really be honest with myself. Where am I going to be in my family life, where am I going to be maybe in the country. Assess these things that are important to you, and then see if there is somebody out there that you really admire and just ask them, and you don’t have to limit this to one person either.

Having a whole network of people will really help you share your success in achieving your goals, because you have more accountability partners and more opinions. There’s a couple online services as well. For women there is a site called Glass-breakers, which will link up people, via the LinkedIn Network. There I’ve had a couple introductions, and I actually met somebody in person who happened to be on a business trip from London. We had dinner and it was amazing how well we connected. I would be fearless and say, “Hey, I need help on this,” and admit that you need help, and these natural relationships will form.

Derrick:
Is there something in that relationship that says your mentor should or should not be your manager?

Rachel:
I would advise against having your mentor be your manager. Here we do have Technical Managers who are in charge of making sure our project is on time, making sure that everybody’s being productive, and basically are leading the projects, leading the teams. They’re also in charge of writing reviews for the team members. We then have other people who are available such as myself, who are really focused on making sure that the other employees are happy, they’re doing the type of work they want, and then also if there’s something they need to get off their chest, it’s a safe environment because you’re talking to somebody who isn’t reporting on you or needs to also … They’re kind of the neutral Switzerland or something. They’re to necessarily involved in the review process of you and your team, but they’re there to help focus on your happiness and the growth of your career.

I think whenever you’re the manager you have to constantly have that balance of the best interest of the company and the person, whereas I think an independent party really is concentrating on the person. It doesn’t mean that this relationship with your manager is bad, it just means that maybe you also need to take in a mentor who’s not in a manager role.

Derrick:
Rachel I think this was really great conversation. I hope a lot of people take the next steps to either find a mentor or become a mentor.

Rachel:
Great, thank you for having me.

Going Beyond Code to Become a Better Programmer – Interview with Pete Goodliffe

In this interview with Pete Goodliffe, author of ‘Becoming a Better Programmer‘, we dive into issues that go beyond code and separate the good from the great developers. We cover things like attitude, communication skills, managing complexity and what you can do to learn more and keep your skills up to date.

Content and Timings

  • Introduction (0:00)
  • About Pete (0:23)
  • A Great Developer’s Attitude (0:49)
  • Write Less Code (2:00)
  • Communicating Effectively (3:10)
  • Handling Complexity (4:24)
  • Keeping Your Skills Up to Date (7:07)
  • Recommended Resources (8:27)

Transcript

Introduction

Derrick:
Pete Goodliffe is a programmer and software development writer, perhaps best known for his software development book, ‘Code Craft’. He speaks regularly at conferences on software development topics and recently published ‘Becoming a Better Programmer: A Handbook for People Who Care About Code’. Pete, thank you so much for joining us. Would you like to share a bit about yourself?

About Pete

Pete:
Sure. I’m a geek. I’m a developer. I like to say I’m a conscientious coder, making the world better one line of code at a time. I am a regular magazine columnist. I’ve been writing a column for more than 15 years now, which is probably some kind of record, I suspect. My day job, I’m a coder. I work in a really awesome team making fun stuff. I’m a musician and I get the opportunity to write code for musical instruments.

A Great Developer’s Attitude

Derrick:
In the book, Becoming a Better Programmer, you say the real difference between adequate programmers and great programmers is attitude. What are the characteristics of a great programming attitude?

Pete:
The standout difference between the really good coders that I’ve worked with and the guys that aren’t so great, is attitude. It’s not a hand-wavey thing. I’ve worked with guys who know technology and who know the idioms, and how to do all this stuff. If they don’t have the right attitude they’re just not effective programmers and they’re not great guys to work with. The kind of stuff I’m talking about here, is humility. You don’t want to work with guys who think they know it all but don’t. Being humble is the key thing.

It doesn’t mean that’s an excuse to not know stuff, but just not believing that you’re better than you are. Specifically, being in a state of constant learning, which I guess ties in with humility, so constantly looking for new stuff, absorbing new knowledge, wanting to learn off other people, the desire to do the best thing you can. It doesn’t necessarily mean be a perfectionist and wanting to make everything perfect before you ship. It’s doing the best you can in the time you have, with the resources you have. That kind of attitude really drives through to great code, great products rather than sloppy work.


“I’ll mis-quote Sartre and say ‘Hell is other people’s code’”


Write Less Code

Derrick:
You’re an advocate for writing less code. Why is this and how can programmers actively work on coding more concisely?

Pete:
Yeah, less code. It seems kind of counter-intuitive for a coder but I think most old-hands know what talking about. It’s kind of the case of working smarter not harder. It’s entirely possible to write thousands of lines of code and achieve nothing in it. Think about it, no unnecessary logic, don’t write stuff that doesn’t need to be said, don’t write verbose code. Sometimes you can stretch out boolean expressions into massive if statements which just hide what is being said.

It’s really a pointless comment, we’ve all seen that haven’t we, code with an essay, and then the function body is really small. Somewhere in the essay there’s some important information but you didn’t need the fifteen paragraphs of comments. No pointless comments, the code just does what it does. The writing of simple but not simplistic code. If you don’t write enough code, it doesn’t do what it’s supposed to do, but just avoiding all those points of needless generality. Don’t make abstracts interfaces, don’t make deep hierarchies that don’t need to be extended, if you don’t need to extend them.

Communicating Effectively

Derrick:
For most professional programmers, development is a social activity in which communication is key, how can programmers begin to communicate more effectively?

Pete:
Code is communication. You’re communicating not just to the computer, you are communicating to other people writing the code. Even if you are working by yourself, you are communicating to yourself in two years time when you pick up the same section of code. It’s a skill, and it’s something you learn, and it’s something you consciously practice. I don’t know of courses, Uni courses or practical courses that really focus on something that’s really quite an important skill for programmers. It’s something that you need to consciously practice, you need to consciously work on, you need to be consciously aware of.

It’s true some people come out the gate better placed than others. Some people can talk well, some people are shy and retiring, but that doesn’t necessarily mean you are stuck like that. That doesn’t necessarily make you a bad communicator. Some people communicate better in different media and it’s worth bearing that in mind. Some guys are really great on email, they can write concise, clear descriptions, they can follow a line of argument writing and explaining something really well. Other people struggle to put it together in words. Learning how you communicate well, playing to your own strengths, then picking the right medium.

Handling Complexity

Derrick:
What are some ways developers can approach managing complexity in software development?

Pete:
A key thing to understand is the difference between necessary complexity and unnecessary complexity. The reason people pay us to write software, unless we’re doing it for fun, is because there’s a complicated problem that needs to be solved. There is some level of necessary level of complexity in software engineering and we have to embrace and understand. The problem is the unnecessary complexity. You can take something, a problem you need to solve, add a little bit of complexity, but then if you wrap it up in class design and higher up it reveals itself in architecture.

One thing I know about well crafted software that basically has the necessary complexity but none of the unnecessary complexity is when I look at it, it looks obvious. That is the key hallmark of some excellent code. You look at it and you just think, “You’ve been working on that for a while” and I look at it and I go, “That’s clearly right.” And you know it wasn’t simple to write. When you look at it the solution’s simple, the shape is simple. All I can say is, that’s what we should strive for.


“I have learned the most in my career when I have been around excellent people”


Derrick:
What are some things developers can do to tackle messy or bad code bases?

Pete:
The most important thing is when you get into your codebase, is to ask people. I see so many developers who just won’t sort of swallow their pride and say, “I don’t quite know what this is doing, but I know Fred over there does. I’ll just go talk to Fred about it.” Often those little bit of insights give you a super fast route through something intractable, a little explanation sort of takes you in there. I’ll mis-quote Sartre and say “Hell is other people’s code.” We all kind of go into that, I do this, and I really struggle with this. I pick up some code, I look at it, that’s a bit dodgy isn’t it. “I really wouldn’t do it like that, what were they thinking, they must be idiots!”

Then my code, I think it’s great. I understand it perfectly, but then somebody else picks it up, they’ll make that same judgement call on my code. What I think is their terrible hack, is actually some pragmatic thing they did for very good reason. When you’re reading messy code, looking at messy code, enter with humility. Nobody really goes out of their way to write badly. Nobody goes out of their way to write messy code, in general. I can’t say that I’ve found anyone that really tried to ruin a project. Approach code with that attitude.

The retrospective prime directive, I can’t remember how it goes, we truly believe everyone did the best they could to the best of their abilities at the time given what they knew, etc., etc. This stops you from making judgement calls, stops you from saying oh, I’m going to rip this whole thing out and start again. This teaches you humility to look a little deeper first.


“The standout difference between the really good coders… and the guys that aren’t so great, is attitude”


Keeping Your Skills Up to Date

Derrick:
The stuff that we work with is constantly changing and it’s all too easy to find yourself becoming something of a coding dinosaur. What can programmers do to ensure that they keep learning and developing their skills?

Pete:
If we value our careers and our skill sets, then this is something you should really be caring about. This is something I find really challenging for myself right now as well. The things I’m focusing on and learning right now are not necessarily coding-related stuff. I’m challenged with learning management, some high-level decision and tactical thinking on a project, rather than dipping into low-level coding stuff. Which is also really fun, but it does mean that I’m pulled away from thinking about the lower-level technical stuff. I want to challenge myself, not get stale and not become that coding dinosaur.

It’s interesting because I know the tools that I know well, and I do use them regularly, but it is really easy to become stale if I’m not pushing the envelope on my technical skills. The biggest take away I guess though is passion. If you don’t want to become a coding dinosaur you probably won’t, because you care about it enough that you will learn, you will read, you will spend time, you will look at web casts, whatever. If you don’t have the desire to learn. If you don’t have the motivation to do it, that’s when you stagnate. That’s when you become a dinosaur.

Recommended Resources

Derrick:
What are some resources you can recommend for those seeking to become better programmers?

Pete:
The biggest thing for me, and that I have done personally and continue to do, is to sit at the feet of great coders. I have learned the most in my career when I have been around excellent people who I can learn off of. Whose skills can rub off on me and I have moved jobs. I have moved myself physically to be able to work with those guys. If you have the liberty to do that, do that. It’s joining in those conversations replying on Twitter, blogging yourself, joining the local user-groups, and all that good stuff.

You want to become a better programmer? Again it’s the want to be a better programmer, and just stoking that passion. I’m enthusiastic. I love this stuff. If you have an enthusiasm, that passion for programming, it tells out in the code that you write.

Derrick:
Really appreciate your passion today. We can definitely see it, and we hope the viewers enjoy it.

Pete:
Excellent. Thank you. Cool.

Code Review Best Practices

As developers, we all know that code reviews are a good thing in theory. They should help us:

  • Find bugs and security issues early
  • Improve the readability of our code
  • Provide a safety net to ensure all tasks are fully completed

The reality is that code reviews can frequently be an uncomfortable experience for everyone involved, leading to reviews that are combative, ineffective, or even worse, simply not happening.

Here is a quick guide to help you to create an effective code review process.

WHY do we do code reviews?

The first question to answer when reviewing your code review process is: what’s the purpose of our code reviews? When you ask this question, you soon realise that there are many reasons to perform code reviews.  You might even find that everyone in the team has a different idea of why they’re reviewing code. They might think they’re reviewing

  1. To find bugs
  2. To check for potential performance or security problems
  3. To ensure readable code
  4. To verify the functionality does what was required
  5. To make sure the design is sound
  6. To share knowledge of the features that have been implemented and the updated design
  7. To check the code meets standards
  8. …or one of hundreds of other reasons

If everyone in the team has a different “why”, they’re looking for different things in the code. This can lead to a number of anti-patterns:

  • Code reviews take a long time as every reviewer will find a different set of problems that need to be addressed
  • Reviewers become demotivated as every review throws up different types of problems depending upon who reviews it
  • Reviews can ping pong between the reviewer the code author as each new iteration exposes a different set of problems

Having a single purpose for your code reviews ensures that everyone taking part in the review, whether they’re a code author or a reviewer, knows the reason for the review and can focus their efforts in making sure their suggestions fit that reason.

WHAT are we looking for?

Only when we understand why we’re doing the review can we figure out the things we want to look for during the review. As we’ve already started to see, there are a huge number of different things we could be looking for during our review,  we need to narrow down the specific things we really care about.

For example, if we’ve decided the main purpose of our reviews is to ensure the code is readable and understandable, we’ll spend less time worrying about a design that has already been implemented, and more time focusing on whether we understand the methods and whether the functionality is in a place that makes sense. The nice side effect of this particular choice is that with more readable code it’s easier to spot bugs or incorrect logic. Simpler code is often better performance too.

We should always automate as much as possible, so human code reviewers should never be worrying about the following:

  • Formatting & style checks
  • Test coverage
  • If performance meets specific requirements
  • Common security problems

In fact, what a human reviewer should be focusing on might be fairly simple after all – is the code “usable”? Is it:

  • Readable
  • Maintainable
  • Extensible

These are checks that cannot be automated. And these are the features of code that matter most to developers in the long run.

Developers are not the only people who matter though, ultimately the code has a job to do. Our business cares about: does the code do what it’s supposed to do? And is there an automated test or set of tests to prove it?

Finally, does it meet so-called non-functional requirements? It is important to consider things like regulatory requirements (e.g. auditing) or user needs (like documentation) if these checks.

WHO is involved in code reviews?

With a clear purpose and a set of things to be looking for in a review, it’s much simpler to decide who should be involved in the review.  We need to decide:

Who reviews the code? It’s tempting to assume that it should be one or more senior or experienced developers.  But if the focus is something like making sure the code is easy to understand, juniors might be the correct people to review – if an inexperienced developer can understand what’s happening in the code, it’s probably easy for everyone to understand.  If the focus of the review is sharing knowledge, then you probably want everyone to review the code. For reviews with other purposes, you may have a pool of reviewers and a couple of them are randomly picked for each review.

Who signs off the review? If we have more than one reviewer, it’s important to understand who ultimately is responsible for saying the review is complete. This could be a single person, a specific set of people, a quorum of reviewers, specified experts for particular areas of the code, or the review could even be stopped by a single veto. In teams with high levels of trust, the code author might be the one to decide when enough feedback is enough and the code has been updated to adequately reflect concerns that were raised.

Who resolves differences of opinion? Reviews may have more than one reviewer.  If different reviewers have conflicting advice, how does the author resolve this? Is it down to the author to decide? Or is there a lead or expert who can arbitrate and decide the best course? It’s important to understand how conflicts are resolved during a code review.

WHEN?

When has two important components:

When do we review? Traditional code reviews happen when all the code is complete and ready to go to production. Often code will not be merged to trunk/master until a review is complete, for example the pull request model. This is not the only approach. If a code review is for knowledge sharing, the review could happen after the code has been merged (or the code could be committed straight to master). If the code review is an incremental review that is supposed to help evolve the design of the code, reviews will be happening during implementation.  Once we know: why we do reviews; what we’re looking for; and who takes part, we can more easily decide when is the best time to perform the review.

When is the review complete? Not understanding when a review is complete is major factor that can lead to reviews dragging on indefinitely. There’s nothing more de-motivating than a review that never ends, a developer feels like they’ve been working on the same thing forever and it’s still not in production. Guidelines for deciding when the review is complete will depend upon who is taking part in the review, and when the review is taking place:

  • With knowledge sharing reviews, it could be signed off once everyone has had a chance to look at the code
  • With gateway reviews, usually a single nominated senior (the gatekeeper) says it’s complete when all their points are addressed
  • Other types of reviews may have a set of criteria that need to be passed before the review is complete.  For example:
    • All comments have been addressed by fixes in the code
    • All comments have either led to code changes, or to tickets in the issue tracker (e.g. creating tickets for new features or design changes; adding additional information to upcoming feature tickets; or creating tech-debt tickets)
    • Comments flagged as showstoppers have all been addressed in some way, comments that were observations or lessons to learn from in the future do not need to have been “fixed”

WHERE do we review?

Code reviews don’t have to happen inside a code review tool. Pair programming is a form of code review. A review could be simply pulling aside a colleague and walking through your code with them. Reviews might be done by checking out a branch and making comments in a document, and email or a chat channel. Or code reviews might happen via GitHub pull request or a piece of code review software.

Summary

There are lots of things to consider when doing a code review, and if we worried about all of them for every code review, it would be nearly impossible for any code to pass the review process. The best way to implement a code review process that works for us is to consider:

  • Why are we doing reviews? Reviewers have an easier job with a clearly defined purpose, and code authors will have fewer nasty surprises from the review process
  • What are we looking for? When we have a purpose, we can create a more focused set of things to check when reviewing code
  • Who is involved? Who does the reviews, who is responsible for resolving conflicts of opinion, and who ultimately decides if the code is good to go?
  • When do we review, and when is the review complete? Reviews could happen iteratively while working on the code, or at the end of the process. A review could go on forever if we don’t have clear guidance on when the code is finally good to go.
  • Where do we review? Code reviews don’t need a specific tool, a review could be as simple as walking a colleague through our code at  our desk.

Once these questions are answered we should be able to create a code review process which works well for the team. Remember, the goal of a review should be to get the code into production, not to prove how clever we are.

Working Effectively with Unit Tests: Unit test best practices (Interview with Jay Fields)


In this interview with Jay Fields, Senior Software Engineer at DRW Trading, we discuss his approach to writing maintainable Unit Tests, described in his book ’Working Effectively with Unit Tests’. We cover unit test best practices; how to write tests that are maintainable and can be used by all team members, when to use TDD, the limits of DRY within tests and how to approach adding tests to untested codebases.

For further reading on unit test best practices, check out Jay’s blog where he writes about software development.

Content and Timings

  • Introduction (0:00)
  • About Jay (0:30)
  • Writing Unit Tests in a Team (2:27)
  • DRY as an Anti-Pattern (3:37)
  • When to use TDD (5:12)
  • Don’t Strive for 100% Test Coverage (6:25)
  • Adding Tests to an Untested Codebase (7:50)
  • Common Mistakes with Unit Tests (10:10)

Transcript

Introduction

Derrick:
Jay Fields is the author of Working Effectively with Unit Tests, the author of Refactoring: Ruby Edition, a software engineer at DRW Trading. He has a passion for discovering and maturing innovative solutions. He has worked as both a full-time employee and consultant for many years. The two environments are very different; however, a constant in Jay’s career has been how to deliver more with less. Jay, thank you so much for joining us today. We really appreciate it. Can you share a bit about yourself?

About Jay

Jay:
Thanks for having me. My career has not really been focused in a specific area. Every job I’ve ever taken has been in a domain I don’t know at all, and a programming language, which I don’t really know very well. Starting with joining ThoughtWorks and being a consultant was a new thing for me. I was supposed to join and work on C# and ended up in the Ruby world very quickly. I did that for about five years, and then went over to DRW Trading to do finance, again something I’ve never done, and to do Java, something I had no experience with. That worked okay, and then I quickly found myself working with Clojure. It’s been interesting always learning new things.

Derrick:
Picking up on the book Working Effectively with Unit Tests, most developers now see unit testing as a necessity in software projects. What made you want to write a book about it?

Jay:
I think it is a necessity in pretty much every project these days, but the problem is, I think, really a lack of literature beyond the intro books. You have the intro books that are great, and I guess we have the xUnit Patterns book, which is nice enough as a reference. It’s not very opinionated, and that’s great, we need books like that also. But, if I were to say, I prefer this style of testing, and it’s very similar to Michael Feather’s approach to testing. There’s no literature out there that really shows that. Or, I prefer Martin Fowler’s style of testing, there’s no literature out there for that. I really don’t know of any books that say, “Let’s build upon the simple idea of unit testing, and let’s show how we can tie things together.” You can see some of that in conference discussions, but you really don’t see extensive writing about it. You see it in blog books, and that’s actually how my book started. It was a bunch of blog books that I had over 10 years that didn’t really come together. I thought, if I were to say to someone, “Oh, yeah just troll my blog for 10-year old posts, they’re not really going to learn a lot.” If I could put something together that reads nicely, that’s concise, people can see what it looks like to kind of pull all the ideas together.

Writing Unit Tests in a Team

Derrick:
In the book you say, “Any fool can write a test that helps them today. Good programmers write tests that help the entire team in the future.” How do you go about writing such tests?

Jay:
It’s really tough. I don’t see a lot written about this either, and I think it’s a shame. I think you first have to start out asking yourself, “Why?” You go read an article on unit testing, and you go, “Wow! That’s amazing! This will give me confidence to write software.” You go about doing it, and it’s great because it does give you confidence about the software you’re writing. But the first step I think a lot of developers don’t take is thinking about, “Okay, this is great for writing. It’s great for knowing that what I’ve just written work, but if I come back to this test in a month, am I going to even understand what I’m looking at?” If you ask yourself that, I think you start to write different tests. Then once you evolve past that, you’re really going to need to ask yourself, “If someone comes to this test for the first time, someone goes to this line of code in this test, and they read this line of code, how long is it going to take for them to be productive with that test?” Are they going to look at that test and say, “I have no idea what’s going on here.” Or, is it going to be obvious that you’re calling this piece of the domain that hopefully everyone on the team knows, and if they don’t, it follows a pattern that you can get to pretty easily. I think it’s a lot about establishing patterns within your tests that are focused on team value and on maintenance of existing tests, instead of focused on getting you to your immediate goal.

DRY as an Anti-Pattern

Derrick:
You also mentioned that applying DRY, or don’t repeat yourself, for a subset of tests is an anti-pattern. Why is this?

Jay:
It’s not necessarily an anti-pattern, I think it’s a tradeoff. I think people don’t recognize that merely enough. You’re the programmer on the team. You didn’t write the test. The test is now failing. You go to that test, and you look at it, and you go, “I don’t know what’s going on here. This is not helpful at all. I see some field that’s magically being initialized. I don’t know why it’s being initialized.” At least if you’re an experienced programmer, then hopefully you know to go look for a setup method. But imagine you have some junior guy, just graduated, fantastic programmer. He’s just not really familiar with xUnit frameworks that much. Maybe he doesn’t know that he needs to look for a setup method, so he’s basically stuck. He can’t even help you at that point without asking for help from someone else. DRY’s great. If you can apply DRY on a local scale within a test. It’s fantastic if you can apply it on a global scale, or across the whole suite, so that everybody’s familiar with whatever you’re doing then that’s great too. That helps the team, but if you’re saying that this group of tests within this trial behave differently than these tests up here, you’re starting to confuse people. You’re taking away some maintainability, and that’s fine, maybe you work by yourself so no one’s confused because you did it, but recognize that tradeoff.

When to use TDD

Derrick:
You’re a proponent of the selective use of Test-Driven Development. What type of scenarios are helped by TDD, and when should a developer not apply such techniques?

Jay:
It’s a personal thing. For me, I think I can definitely give you the answer, but I would say everybody needs to try TDD, just try it all the time. Try to do it 100% of the time, and I think you’ll very likely find that it’s extremely helpful for some scenarios, and not for others. Maybe that’ll differ by person, so everyone should give it a try. For me personally, I’ve found when I know what I want to do, if I pretty have a pretty mature idea of what needs to happen, than TDD is fantastic because I can write out what I expect, and then I can make the code work, and I have confidence that it worked okay. The opposite scenario where I find it less helpful is when I’m not quite sure what I want, so writing out what I want is going to be hard and probably wrong. I find myself in what I think is kind of a wasted cycle of writing the wrong thing, making the code do the wrong thing, realizing it’s wrong, writing the new thing that I expect which is probably also wrong, making code do that, and then repeating that over and over, and asking myself, “Why do I keep writing these tests that are not helpful? I should just brainstorm, or play around with the code a little bit, and then see what the test could look like to once I have a good idea of the direction it is going.

Don’t Strive for 100% Test Coverage

Derrick:
You say you’re suspicious of software projects approaching 100% test coverage. Why is this, and why is 100% coverage not necessarily a goal we should all strive for?

Jay:
Earlier on I thought it was a good idea, 100%, because I think a lot of people did. I remember when Relevance used to write in their contracts that they would do 100%, and I thought, “Man, that’s really great for them, their clients.” Then you start to realize you need a test things like, say you’re writing in C#, and you have to automatically generate a set. Do you really want to test that? I think all of us trust that C# is not going to break that functionality in the core language, but if you put that field in there, then you have to test it if you want to give 100% coverage. I think there will be cases where you would actually want to do that. Let’s say you’re using some library, and you don’t really upgrade that library very often, and even though you trust it, maybe you’re writing for NASA or maybe you’re writing for a hospital system – something where if it goes wrong, it’s catastrophic. Then you probably want to write those tests. But if you’re building some web 2.0 start up, not even sure if the company is going to be around in a month, you’re writing a Rails app, do you really want to test the way Rails internals work? Because you have to, if you want 100% coverage. If you start testing the way Rails internals work, you may never get the product out there. You’ll have a great test suite for when your company runs out of money.

Adding Tests to an Untested Codebase

Derrick:
So that’s what’s wrong with too many tests. What about a code base with no tests? How can you approach getting test coverage on an untested code base?

Jay:
I think the focus for me is really return on investment. Do you really need to test everything equally when the business value is not the same? Let’s say for instance, you’re an insurance company. You want to sell insurance policies. So you need a customer’s address, and you need a social security number, probably, to look them up, some type of unique key, and after that, you just want to charge them. Maybe you need their billing details, but you don’t really care if you got their name wrong, you don’t really care if you got their age wrong. There are so many things that aren’t really important to you. As long as you can keep sending them bills and keep getting paid and find the customer when you need to, the rest of the stuff is not as important. It’s nice. Whenever you send them the bill, you want to make sure the name is correct, but it’s not necessary for your software to continue working.

When I’m writing tests, I focus first on the things that are mission critical. If the software can’t succeed without a function working correctly, or a method working correctly, then you probably need some tests around that. After that you start to do tradeoff, basically looking at it and figuring out, “Well, I want to get the name right. If I get the name wrong, what’s the cost?” Well, getting the name wrong I’m not sure if there’s much of a cost other than maybe an annoyed customer that calls up and says, “Can you fix my name?” So, you have maybe have some call center support. I’m guessing that the call center is going to be cheaper than the developer time. So do we want to write a test with a Regex for someone’s name and now we need UTF support, and now we need to support integers because someone put an integer in their name? And you get in to this scenario where you are maintaining the code and the tests. Then maintaining the tests is stopping you from getting a call center call. It’s probably not a good tradeoff. I just look at the return in investment of the tests, and if I have way too many tests, every amount of code needs to be maintained. If I have too many tests, than I need to delete some because I’m spending too much time maintaining tests that aren’t helping me. If I have not enough tests, then it’s very simple, just start to write some more. I guess I tend to do that with whenever a bug comes in for something that’s critical. Hopefully, you caught it before then, but occasionally they get into production, and you write tests around that. I always think to myself, whenever the bug comes in, what was the real impact here?

Common Mistakes with Unit Tests

Derrick:
What are some of the common mistakes you see people making when writing unit tests?

Jay:
I think the biggest one is just not considering the rest of the team, to be honest. It’s really easy to do TDD. You write a test, and then you write the associated code, and you just stop there. Or, you do that, and you then you apply your standard software development patterns, so you say, “How can I DRY this up? How can I apply all the other rules that have been drilled into me that I need to do with production code? What’s really important?” Now if understanding the maintenance, understanding that what will help you write the code doesn’t necessarily mean it’s going to help you maintain the code. What I find myself often doing, actually, is writing the test until I can develop the code, so I know that everything works as I expect, then deleting that test and writing a different test that I know will help me maintain it. I think the largest mistake people make is they don’t think about the most junior member of the team. Think about this very talented junior member on your team that joined not that long ago. Are they going to be able to look at this test and figure out where to go from there? And if the answer’s no, then that might not be the best test you could write for the code.

Derrick:
Beyond your book, can you recommend some resources for developers interested in learning more about writing effective tests?

Jay:
I think that there are great books that help you get started. I think the Art of Unit Testing is a great book to help you get started. There’s the xUnit Patterns book that’s really good. The problem is, I really don’t think there’s much after that. At least I haven’t found much. Kevlin Henney has done some great presentations about test-driven development. I personally really like Martin Fowler’s writing and Michael Feathers’ writing and Brian Marick, but I don’t know of any books. I really think that there’s room for some new books. I think that, hopefully, people will write some more because unit testing’s only going to be more important. It’s not going away, it’s not like people think this is a bad idea. Everybody thinks this is a great idea. They just want to know how to do it better.

Derrick:
Jay, thank you so much for joining us today. It was a pleasure.

Jay:
Yeah, it was great! Thank you very much for your time.

 

For further reading on unit test best practices and software development, check out Jay Field’s blog.

How to build a code review culture: An Interview with Derek Prior

We’ve interviewed Derek Prior, a Developer at Thoughtbot and host of The Bikeshed Podcast. We discuss how to build a code review culture, diving into the benefits of code reviews, the essential elements to make them effective and how to handle conflict if it arises.

Content and Timings

  • Introduction (0:00)
  • Code Reviews Vs. Pair Programming (0:26)
  • Benefits of Code Reviews (1:10)
  • What to cover in a Code Review (4:48)
  • Code Review Author and Reviewer Best Practice (6:47)
  • Handling Conflict in Code Reviews (10:21)
  • Recommended Resources (12:45)

Transcript

Introduction

Derrick:

Derek Prior is a developer for Thoughtbot in Boston. He co-hosts a web development podcast called, “The Bike Shed”. He speaks about development practices at conferences, including the talk, “Cultivating a Code Review Culture”. Derek, thank you so much for taking time to join us today. Do you have a bit to share about yourself?

Derek:

I’ve been speaking at conferences and meet-ups lately about code reviews, like you said. It’s something that I’ve had a lot of experience with over the last 10 years or so.

Code Reviews Vs. Pair Programming

Derrick:

Some people mean different things when they use the term “code review”, like “pair programming”. What do you mean by code reviews?

Derek:

There’s this term, and it’s not my term, called, “modern code review”, and that’s what I’m talking about. What that means… The definition of that is basically, asynchronous or tool-driven, generally like, lightweight reviews. Most of the people I work with that means a GitHub pull request. That’s typically what I’m talking about. Pair programming is great, and has a lot of the same benefits. But when I’m doing pair programming, I still like to have another person to review the code… I still like to have that other person, also review the code.

The reason for that is in pair programming, you’re kind of building up a solution with your pair, as you go. I really like to see at the end, if that holds up for another developer who might have to work on this next week kind of thing. Like, does this make sense to somebody who wasn’t there all along the way.

“It’s much more helpful to focus on the cultural benefits of code reviews”

Benefits of Code Reviews

Derrick:

Why are code reviews important?

Derek:

Everybody here, when they hear about this, everybody’s natural reaction is to say that they catch bugs. That is true. If I have code reviewed that’s going to have less bugs, than code that isn’t reviewed. But I think that that puts too much importance on the “finding bugs” part. Microsoft actually did a study of this, Microsoft Research, in 2013. Where they found that people consistently said the number one benefit from code reviews is finding defects in code.

But then when they looked at actual data collected in their code review tools, and talked to people after they did code reviews, what they actually found was that people got way more benefit, way more cultural benefits, out of sharing knowledge with each other, or keeping up with what everybody’s doing, and knowing what’s going on in that other part of the code base. Finding a really interesting alternative solution to a problem that they hadn’t thought of, just by getting somebody else’s viewpoint.

Those are the much more important things. I feel like they’re much more interesting than finding defects. Finding defects is actually, frankly, really hard. A lot of times I’ll talk to people about code reviews, and they’ll say, “Well we did code reviews, but we still had all these bugs. They weren’t helping us catch the bugs”, and yeah, they’re not going to catch all the bugs. By saying, ‘The chief thing we get out of code reviews is “defects finding”’, what we’re really doing is setting ourselves up for those situations where people say, “But you did a code review on this, and there’s still a bug.” Right?

It’s hard to find all the bugs, because when you’re doing one of these lightweight code reviews, you’re really just looking at a slice of a change. You’re looking at the diff, and to know exactly how that’s really going to impact your system, you have to know the entire system. You can catch edge cases where, “Oh, you didn’t check to see if this was nil”, or whatever the case may be. Knowing exactly where this is going to screw up your data, is hard to know, without knowing the whole system. Code review is great for some defect tracking, or defect finding, but it’s not a panacea. Instead, I think it’s much more helpful to focus on the cultural benefits of code reviews.

Derrick:

How should you work code reviews into your workflow?

Derek:

What we typically do at Thoughtbot is, when I finish up a PR, I will paste it into Slack, or whatever. We’ll paste that in and say, “Can I get a review for this please?” If it’s not urgent, that’s basically all that happens, right? If it’s urgent, I will ping somebody directly. Ping a couple people directly and say, “Hey, this is a production fix, can you take a look at this?” Generally, that’s enough, with the way we work, to get your code reviewed within the next few hours. Which is, generally sufficient.

You can move on to something else. You can review somebody else’s code in that time. You can kind of trade, if somebody else is coming up and finishing something up. You can be, “Oh yeah, I’ll take a look at that. You take a look at this one for me.” That kind of thing. We take a really, lightweight approach to it.

When you think about it, there’s a lot of natural breaks throughout your day that you can work these in to right? For me, I come in in the morning, “are there any PRs outstanding I can look at?” Then I get started. Then, right before lunch, or in the afternoon, if I’m going to take a coffee walk around Boston Common or something, I’ll look then. Either before or after. There’s plenty of times I find, that I can just work these in naturally. There’s no need to schedule them.

I’ve worked with teams that try to schedule them, or try to say, “This person is going to be the one, that’s going to be chiefly doing code reviews this week”, and I’ve never seen that work particularly well. I just try to say, “Keep it lightweight, friendly”, things like that. People are really surprised, or skeptical, to hear that this works. The biggest thing that makes this work is, keeping small, discrete, pull requests, that are going to be much easier reviewed, and providing some excellent context. That’s the “why” you’re making this change, not necessarily the “what”. Ultimately, the big secret to this is that, most of these code reviews only take me five minutes. It’s not a big commitment.

What to cover in a Code Review

Derrick:

What type of things should a code review cover?

Derek:

It’s really important that each person involved in the code review, doesn’t operate from a central checklist, but rather just looks at things that interest them about a change right? Or interests you overall. Maybe you just got finished reading this great book on design patterns. You’re looking for a way to apply this one design pattern. That’s what you’re going to look for. Great. Fine. That’s valuable. You’re going to teach somebody something.

Or maybe you’re really interested in web security, and you’re going to take a look at things from that perspective. Or accessibility, you’re going to take a look at things from that perspective. That’s where having a good blend, on your team, of people who are interested in different things, really pays off, in code review. We’re all going to look at code reviews, and try and see if there’s an obvious bug. I said, not stressing the bug finding, is a big key to this.

But yes, you’re going to look for them, and you’re going to comment on them when you find them. What I really like when people do, is just sort of take their slant on how they think software development should be. Just kind of look at it with their lenses and see, “Oh, did you consider doing this alternative thing over here?” I typically look at … I’m always harping on naming. Right? Part of what I think makes code review so great, is that it’s a great place to have a technical discussion about your actual software. Rather than in the abstract, like when we go to conferences and things like that.

I harp on naming a lot to say, “Do these names give us a good basis for a conversation, about this? Are they descriptive?” That’s really important to me. I look for test coverage, to see … Like I said, I’m not hunting for bugs throughout the entire system … But I am looking to see, “Is this adequately covered, by test?” I’m not going to look at every single test, but I’m just going to to kind of get an idea of “What kind of tests would I expect to see in this change?” I’d expect to see a feature spec. Or I’d expect to see a unit test. That kind of thing. Just make sure that those are there. Stuff like that.

Like I said earlier, the biggest thing is just everybody kind of, bringing whatever it is that they’re interested in … Whatever they’re an expert at … To the table, so that we can all learn from each other.

“Having conflict in your code reviews is actually really beneficial”

Code Review Author and Reviewer Best Practice

Derrick:

As a code author, what should you do to get the most from a code review?

Derek:

The number one thing is context. When you’re submitting a pull request, you’ve been working on this thing for four hours, or eight hours, or two days, or sometimes even a week, or whatever the case may be. You have a lot of context built up in your head. Some things seem really obvious to you at this point. But, to the person reviewing it, they weren’t there for you. They don’t have that context. What you really need to do is think about… It really helps if you’ve been making several small commits along the way, where you’re describing what was in your head.

But as you prepare the change… If you’re going to use a GitHub pull request, and you’re going to submit your pull request to GitHub, make sure you give a nice description of, a summary, of everything … What I really like to see is, not what … A lot of people will summarize what they did? That’s kind of important, the bigger the change gets, so I know what to expect when I’m looking through the change? But it’s not the only thing I want to see, right?

I can figure out what a change does by looking at the code. Unless it’s totally obfuscated. What’s really interesting is why. Why are we changing it? Why is this the best solution? What other solutions did you consider? What problems did you run into? Is there an area of the code you’re really unsure about, that you’d really like some extra eyes on? That kind of thing. Those are going to help you get a much better review, by setting up everybody else to be on the same page as you.

Derrick:

When you’re reviewing code, how do you do it without being overly critical or needlessly pedantic?

Derek:

This happens a lot. Where code reviews that aren’t done particularly well, or overly critical, can kind of, lead to resentment among the team. The big thing there is, negativity bias, that you need to be aware of. If I’m talking to you … Like I am in this conversation, and I give you some technical feedback, and I say, “Oh, why didn’t you use this pattern here”, whatever. You’re going to perceive that in one way. But if I say that same exact thing written down, it comes off more harsh. You’re going to perceive that more negatively.

It’s much more subject to your particular mood. I can’t influence it with the way I say something. It’s just a fact that, the same feedback written, is going to be perceived more negatively. One excellent way to get around that, is to give feedback in a manner that’s more of a conversation. What I like to do is ask questions. At Thoughtbot, we call this “asking questions, rather than making demands”, right?

Instead of saying, “Extract the service object here, to reduce some of this duplication”, I would say, “Hey, what do you think about extracting a service object here, to eliminate this duplication?” Right? They’re very similar comments, but now I’m opening it up to a conversation, by asking you a question. Like, “Oh, what do you think …?” Sometimes I’ll even say something like, “What do you think about doing it this way?”, and I’ll provide a code sample. Then afterwards, if I don’t really feel particularly strongly about it, I’ll be like, “No, I’m not really sure though, what do you think?” Just to kind of say, “I can see how this would go either way.” “What do you think?”

Clarifying how strongly you feel about a piece of feedback, is also something that can help. Making sure that you’re addressing people’s feedback. That’s basically, how to avoid being overly critical. Is just asking nice, friendly questions, that open up a conversation? The pedantic part, I guess would be like, when you start arguing in circles. When you’re not coming to a good conclusion here, right? What I’d say there is just, make sure you’re focusing on high value things. Don’t go edge case hunting everywhere.

There’s a lot of times you can find edge cases that, just aren’t going to come up. Or, maybe they are and they’re important. But really, what you want to be focusing on is, the more higher value type stuff that we talked about earlier. Try and focus on those, to stay away from these like, pedantic arguments that you can into in code review.

“The big secret is that most of these code reviews only take me five minutes”

Handling Conflict in Code Reviews

Derrick:

Inevitably, with discussions between developers in code, disagreements are going to occur, from time to time. How should you handle this type of conflict?

Derek:

I think the first thing to recognize, is that, having conflict in your code reviews like this, is actually really beneficial. Right? As long as they’re the right types of conflict and nobody feels bad about them afterwards, that kind of thing … Because if you’re agreeing with your teammates all the time, and nothing interesting is happening in your code reviews, you basically have a monoculture, and those are dangerous on their own right.

Like I eluded to before, you want everybody bringing their own experiences, and their own expertise, and sometimes those are going to clash with each other. My experience was, doing things this way, led to these problems, and your experience was, doing things this way, was actually really beneficial. We’re going to have conflict about that. The key is that, handling those conflicts properly, is how everybody on the team is going to learn.

What I suggest, when you find yourself going back and forth, a couple comments about something, and you don’t seem to be getting anywhere … Nobody’s yielding, right? What I try to do is take a step back and be like, “How strongly do I feel about this?” Do I feel like, “This is a quality issue, that if we go out with this code, like it is today, it’s going to be a serious problem immediately?” Or is this kind of like, “It’s not really the approach I would have taken, but, maybe it will work. Or it’s a reasonable solution.” That kind of thing right?

Often times, that’s actually what it is. Once we get beyond a certain level of quality, what we’re talking about is trade-offs, all the time. That’s basically all we’re talking about when we’re doing computer programming. Like I said, once we get past the initial quality is, the trade-offs involved. If you’re arguing about what is essentially a trade-off, maybe it’s time to be like, “Okay. You know what? I would prefer to do it this way, but I can see why you’re doing it that way, and why don’t we just revisit this, if we need to, when we have more information?”, right?

Sometimes, you’ll argue about code, for a while, and then it goes into production. Then you don’t touch it for six months. Which means, it was fine. Even if you didn’t think it was the greatest looking code in the world, like it was written, and it doesn’t have bugs that are obvious. It doesn’t need to be continually improved so, whatever, it’s fine.

If you can table the arguments you’re having until you have more information, and then kind of revisit them. Be like, “Oh, okay. I see now we have this bug, or we have this additional feature we need. I can see how that thing you said earlier, would be a better approach here.” That kind of thing. Waiting until you have more information to, really dig in again, is probably a good thing to do.

Recommended Resources

Derrick:

Can you recommend any resources for those wanting to improve the effectiveness of their code reviews?

Derek:

We have guides. If you go to github.com/thoughtbot/guides, there’s a bunch of guides in there. Some of them are like style, and protocol and things like that. But there’s also a code review guide in there. Whether or not you agree with everything in there, I think it’s a good example of something that I’d like to see more teams do. Where they provide, “This is what we write down, and agree to.” Then have pull requests against, when we want to change. What we think code reviews should be. How we think they should operate.

Every piece of feedback, should it be addressed? Yes, I think so. At least to explain, “Okay, I see what you said there, but I’m going to go in this direction instead.” That kind of thing. I’d like see more people take a look at that, and then adopt it for their team. Other things that can really help with code reviews, are style guides. Which we also have in that repo but, there’s also many community style guides. Just avoiding those arguments about, “Oh, I’d really like see you call …” Like in Ruby, we have map and collect under the same method, right?

Let’s be consistent. Let’s pick map, or let’s pick collect. Or something like, just writing that down somewhere, making that decision once. Rather than arguing about it on all pull requests, those types of things. That’s basically it. I’d like to see more people, get on board with and kind of documenting their experiences and, their expectations out of these things.

Derrick:

Derek, thanks so much for taking time and joining us today.

Derek:

Yeah, thanks for having me. It was good fun.

——–

Its extremely important to learn how to build a code review culture. Code reviews are great for code quality as they reduce errors, help deliver better code and encourage teams be more compassionate towards one another.

Refactoring to a happier development team

 

In this interview with Coraline Ada Ehmke, Lead Software Engineer at Instructure, we discuss data-driven refactoring and developer happiness teams. Coraline gives some great advice on the kinds of tests we should write for refactoring, tools to use and metrics to monitor, to make sure our refactoring is effective. We also learn about the role of refactoring in the Developer Happiness team at Instructure. You can read more from Coraline on her site.

Content and Timings

  • Introduction (0:00)
  • Useful Tests for Refactoring (0:57)
  • Data-driven Refactoring Metrics (4:13)
  • Winning Management Over to Refactoring (6:34)
  • The Developer Happiness Team (8:36)
  • Recommended Resources (13:58)

Transcript

Introduction

Derrick:
Coraline Ada Ehmke is Lead Engineer at Instructure. She is the creator of the Contributor Covenant, a code of conduct for open source projects, and Founder of OS4W, an organization encouraging greater diversity in open source projects. She speaks regularly at conferences about software development, including the talk ‘Data-Driven Refactoring’. Coraline, thank you so much for joining us today. Do you have any more to share about yourself?

Coraline:
I want to say I’ve been doing web development for about 20 years now, which is forever. I actually wrote my first website before there was a graphical browser to view it in. I started out in Perl, went into ASP for a little while, did some Java, and then discovered Ruby in 2007, and I haven’t looked back. All that experience has led me to be very opinionated about what makes good software. I have some very strong opinions that I’m always flexible about changing, but I have a sense of what good software looks like, and that sort of drives me in my daily work.

“A lot of problems come with code that’s just good enough”

Useful Tests for Refactoring

Derrick:
I want to dig into your experience with refactoring a bit. You say that without tests, you shouldn’t refactor. Why are tests so important to refactoring?

Coraline:
I think it was Michael Feathers who once said that ‘if you’re refactoring without testing, you’re just changing shit’. Basically, the importance of testing is you want to challenge and document what your assumptions are about the way that a piece of code works currently, which can be really difficult, because you might look at a method or a class name and assume its role based on its name, but that name could have drifted over time. You need to ensure that you’re documenting what you think it does and then testing to see that it does what you think it does. Testing can also help you stay within the guardrails through refactoring efforts. It’s hard to know where to stop sometimes, so tests can help you identify when you’re doing too much. You want to make sure you’re doing the minimum rework with the maximum results.

Derrick:
Yeah, that sounds great. It’s so easy with refactoring to just continue down that rabbit hole. What kind of tests are useful when refactoring?

Coraline:
It’s good to have good test coverage to start with, if it’s possible. If you don’t have good test coverage at the start, it’s good to build up some unit tests and integration tests just to make sure you’re staying on the path. There are a couple kinds of tests that I’m particularly interested in when it comes to refactoring. The first is boundary testing, which is basically using test cases to test the extremes of input. The maximum values, the minimum values, things that are just inside or outside of boundaries, typical values, and error values as well.

I like to do generative testing for this. If I have a method that takes an argument, I will create an enumerable with lots of different kinds of arguments in it, and see what passes and what fails. Those failures are really important because when you’re refactoring, you can’t know for sure that somewhere in the code base something is waiting for that method to fail or raise an exception. Your refactoring should not change the signature of that method such that a given piece of input stops causing a failure. You want to be really careful with that. Generative testing can help a lot with that, so there’s that with boundary testing.

Also, I like attribute testing, which is an outside-in way of testing. You check that after your code runs the object that’s being tested possesses or does not possess certain qualities. This can be really useful for understanding when you changed how an object is serialized or the attributes of an object without getting into the implementation details.

The most important tests, though, for refactoring are tests that you throw away. We’re hesitant. We love deleting code, but we hate deleting tests, because it gives us this feeling of insecurity. The sort of test that you do during refactoring doesn’t lend itself well to maintaining code over time. You’re going to be a lot more granular in your tests. You’re going to be testing things that are outside of the purview of normal integration or unit tests, and it’s important that you feel comfortable throwing those away when you’re done with a refactoring effort.

Derrick:
Yeah. The importance of being able to throw away stuff really gives you that perspective on what you’re trying to do.

Coraline:
And it lets you work incrementally, too. You can start by challenging your assumption about how a piece of code works. Once you feel confident, you can set up some boundary tests to see how it responds to strange conditions. Once you feel confident with that, then you’re probably confident enough to do some refactoring and make sure that you’re not introducing regressions.

Data-driven Refactoring Metrics

Derrick:
An important aspect of your approach to refactoring is data and measuring the impact of refactoring efforts over time. What are some useful metrics to track?

Coraline:
I want to emphasize that over time is really, really important, because if you’re not collecting data on your starting point and checkpoints along the way, you don’t know if you’re actually making your code base better or worse. It is possible through refactoring to make your code base worse. Some of the things I like to look at at the start are test execution times. If your test suite takes 45 minutes to run in CI, you’re not doing TDD. It’s impossible, because the feedback loop for your test has to be as short as possible. Refactoring tests is actually a great way to get started in trying to adjust that test execution time.

Another one that I’ll probably talk about later is the feature-to-bug ratio. If you look at your sprint planning, figure out how much time you’re spending on new features versus how much time you’re spending on bugs. You can actually use some tools to track down what areas of your code base are generating the most bugs, and combine that with churn to see what’s changing the most. Those are interesting.

I like to look at code quality metrics. A lot of people use Code Climate for tracking code quality, which I don’t really like that much, because it assigns letter grades to code. If a class has an ‘F’, you might say, “Oh, it needs to be rewritten,” or if a class has an ‘A’, you might think, “Oh, it’s perfect. No changes are necessary.” Code Climate doesn’t really give you the change over time. It’ll give you notification if a given class changes it’s grade. That’s great, but you can’t track that over time. I like some other code quality tools. Looking at complexity, there are tools that do assignment branch conditional algorithms to see how complex a piece of code is. I also like to look at coupling, because coupling is often a symptom of a need for refactoring, especially in a legacy application.

Derrick:
What mistakes do you see people making with refactoring?

Coraline:
Basically trying to do too much at once. It’s really easy to look at a piece of code and immediately make a value judgment, saying, “This is bad code,” which is really unfair to the programmers who came before, and saying, “I’m just going to rewrite the whole thing.” We have this instinct to burn it all down. Trying to change too much at one time is really a recipe for disaster. You want to keep the surface area of your changes as small as possible and work as incrementally as possible. Those things take discipline, and I think it’s hard for a lot of people to achieve that without actively policing themselves.

“The most important tests, though, for refactoring are tests that you throw away”

Winning Management Over to Refactoring

Derrick:
Often just getting the time to actually spend on refactoring can be a challenge. What are some benefits of refactoring that can win management over?

Coraline:
That’s a big, important question. I think in a healthy development organization, the development team, the engineers themselves, are stakeholders. They have some input into your backlog. If there’s technical debt that needs to be addressed, that can be prioritized. Not all of us live in a world where we have that kind of influence over the backlog. Some of the ways you can convince management that refactoring is a good idea… I talked before about the bug-to-feature ratio. Stakeholders want new features. New features keep products healthy and appealing to end users and to investors. Anything that stands in the way of a new feature getting out is necessarily a business problem.

If you look at your feature-to-bug-fix ratio and see that it’s poor, one way you can sell it is to say, “through this refactoring, we’re going to improve this ratio and be able to do more feature work.” You can also look at how long it takes to implement a new feature and talk about how refactoring a piece of code, especially if it’s code that changes very often, can make it easier to add new features to a particular area of the code base faster and easier.

In the end, if none of that works, just cheat. Just lie and pad your estimates, so you automatically build in some time for reducing technical debt with all of your estimates, which unfortunately I’ve had to use more often than I would have liked to. It is a valuable tactic to keep in your toolbox.

Derrick:
Yeah, definitely. I still really like… You mentioned this earlier, but the feature-to-bug-fix ratio is really important.

Coraline:
It really is a great health check for how the team overall is doing, what the code looks like and the health of the team, as well. If people are doing a lot of bug fixes, you’re probably going to have some unhappy engineers, because they want to work on new and shiny things. That can have an impact on how happy your developers are, which is really critical to how much work they’re getting done and how good your product is.

The Developer Happiness Team

Derrick:
Definitely. Let’s talk about happiness. You previously led what was known as the Developer Happiness or Refactoring team at Instructure. Tell us a little bit about the role and mission of that team.

Coraline:
It was one of my favorite jobs, honestly. We were charged with increasing the happiness and productivity of the engineering team. Within our charter was identifying processes or parts of the code base or even people who were standing in the way of developers being as productive as they could possibly be. Being very data driven in my approach, the first thing I wanted to do was get a sense of just how gnarly the code base was.

We ended up writing a bunch of code analysis tools. Again, we were using Code Climate, but I wasn’t really satisfied with its tracking ability over time. So we wrote a few tools. I wrote one called Fukuzatsu, which is an ABC complexity measurement tool. There was already a tool out there that was very similar called Flog that was written by Ryan Davis, but it’s an opinionated tool. It punishes you for things like metaprogramming, and it also favors frameworks like active record and punishes you for using alternative ORMs, so just in the nature of the bias that was built in. I wanted something that… I don’t want opinions with my data. I’m an engineer. I’m a professional. I’m capable of forming my own opinions. I just wanted raw data to work with, and that’s what Fukuzatsu gave me.

Another tool that we ended up building as part of this process at the very beginning was something called Society, which basically makes a social graph of the relationships between your classes. You get this nice circular diagram with afferent and efferent coupling displayed in different colors, and you see the links between different classes. That can help you identify service boundaries, for example, because if you have one class that’s a trunk of a lot of inbound or outbound connections, you might say, “That’s a good place for a service.”

A lot of the work we did early on was building tools. We built a mega-tool that collected data from all these other tools and presented them in a dashboard format with change shown over time. You could drill into complexity. You could drill into coupling. You could drill into code quality or code smells, or various other metrics, and see how they were changing at the commit level. That being done, we identified which areas were causing a lot of bugs, which areas of the code are really complex or really changing a lot.

The next step was creating a team of refactoring ambassadors. Rather than taking on the refactoring work ourselves and handing it over to the team that owned the code, our goal was to send in someone who’s really good at refactoring to work with that team to refactor the problematic code, which I think was pretty valuable in terms of ownership and continued success, and also training and teaching and helping those teams level up.

I think a lot of problems come with code that’s just good enough. I think we’ve all seen pull request bombs where someone had a bug to fix or had a feature to implement, and they went down a path that maybe was not optimal. By the time you actually saw it to do a code review, it was too late to suggest an alternative approach, because so much work had been put into it. You knew that you would just crush the spirit of whoever sent the PR. We end up with this lowest-common-denominator code. People also tend to copy and paste the approach that they’ve seen taken elsewhere in a class or elsewhere in a code base. Demonstrating to them that there’s a better way and there’s a better pattern you can follow is really important to maintaining code quality. That was the overall mission of the team.

Derrick:
Is that kind of focussed team something you’d recommend others try? What kind of impact did it have on factors like code quality and the developer happiness?

Coraline:
I think people appreciated that we were paying attention to engineering’s needs. We’d send out surveys to gauge how satisfied people were with the code that they were writing, with CI, with the test suite, with the overall process. We tracked it over time. I think engineers want to be listened to outside of the scope of just, “What are you building right now?”, or “What are you fixing right now?” They feel empowered when their needs are being addressed and when people are asking them questions about how they’re feeling and the work that they’re doing.

In terms of it being a full-time team, I think that really depends on the size of your engineering organization. Instructure has about 100 engineers, so it made sense to have a dedicated team doing that for a while. I think you could have an individual who’s charged with doing that as their primary job, and that would probably help, or have a team that’s a virtual team where you’re rotating people through on a regular basis.

There are different ways to approach it. I think the important thing is just gauging the health of your development organization and gauging the happiness of your engineers. That is going to have a significant impact on the quality of your code in the end.

Derrick:
You talked about all those tools for code quality, and they sound really great. How did you measure developer happiness? Was it talking to people, or…

Coraline:
Talking to people. We had a survey that we created that asked a bunch of questions about, “What do you think are the impediments to getting your job done? How good do you feel about the feature work that you’ve been doing? Are we spending too much time fixing bugs?” We published the anonymized results of those surveys to our internal wiki so people could go back and reference them, and we could use that to track how well we were doing as a team, as well. Again, just listening to people makes them feel better about things and gives them some hope that maybe change is coming.

“I think engineers want to be listened to outside of the scope of just, ‘What are you building right now?’”

Recommended Resources

Derrick:
Can you recommend any other resources for those wanting to learn more about effective refactoring?

Coraline:
I would suggest really getting to know what your testing tools are as a first step, and looking at some alternative ways of testing. Generative testing, for example, gets a bad rap, but I think it’s really a helpful technique to use when you’re doing refactoring. Looking at what people in other languages are doing in terms of their philosophical approach to testing is really important, and making sure that you’re really up to speed on what those different tools are so that you can be more effective in your work.

In terms of tooling, I would recommend a tool for Ruby called Reek, which is a code smell identifier that can help you isolate what areas you want to focus on. You can create an encyclopedia of code smells for your code base and refer back to that, and organize your work such that, “Oh, we’re going to address all the code smells that are of this kind,” and do that across the board. Really look at the tools that are available for your language in terms of code quality.

There are a few books that I recommend. The first is ‘Working Effectively with Legacy Code’ by Michael Feathers. The examples are written in Java, but the lessons that it teaches are applicable to any language. That’s a really good place to start. I work in Ruby, so I would also recommend ‘Refactoring: Ruby Edition’ by Jay Fields and Shane Harvie, and another book called ‘Rails Anti-Patterns’ by Chad Pytel and Tammer Saleh.

Derrick:
Those are fantastic resources. Coraline, thank you so much for joining us today.

Coraline:
Great, it was a lot of fun. Thank you for inviting me.

 

Originally published on www.fogcreek.com on October 2015

What’s Your Support Tool?

Successful project management comes with certain rules, terms and tools which is not easy to achieve. For that reason, my acquaintances in the tech industry expect valuable functionality and productivity in these tools and they want to rely on their resources in order to deliver qualified work.  

While working at an IT startup, I’ve been in search of a smart solution with unique features to help me improve efficiency and I’ve started my software research based on this.

First, I found this article about Evidence-Based Scheduling on Wikipedia and thought that somebody finally started understanding what a developer needs in a project management software. Then it made me think; what more is out there?

A successful project manager is one who can track and visualize the entire project from start to finish, who could envision milestones and estimate delays. To keep pace with business and IT, project managers need support to expand their visions and make their management practices more adaptable. Here are the tips to utilize that support:

  1. Be Agile, Develop Agile: Stop thinking traditionally and acting rigid, instead focus on being more flexible and moving quicker. Either have a ton of whiteboards or find an online space but get as visual as possible in order to make quick decisions and build an accurate backlog.
  2. Do Not Manage People, Manage Tasks: As weird as it may sound, you will see the benefits once you focus on task management instead of micromanagement. Create cases to contain the necessary information to understand each task, so you can stay productive, with fewer meetings, and monitor your team’s activities clearly.
  3. Update Your Project Management Practice: Have a powerful search engine, allowing you to instantly search complete contents of cases, wiki articles, and customer correspondence. Your issue tracking tool should be your right hand.
  4. Learn From Your Past: Make accurate estimations based on your past project experiences. Make sure to log all your previous project activities, deadlines, delays, assignments and timelines to look back and compare your set goals with the actual achievements.
  5. Time Is The King: You will want to know how much work you’ve left, how much time you’ve spent on each case, ensure a balanced workload, predict project completion dates, improve estimates and deliver on time.
  6. Communicate All Deliverables and Activities: Share technical specs with your entire team, design docs and enable them in your shared library, create knowledge base articles, public documentation for customers, complete specs and user documentation.
  7. Create Step-By-Step Milestones: Divide your project into manageable tasks and assign milestones for each task you had created in order to accomplish your project goals. The milestones will help you with qualifying events and crucial deadlines.
  8. Clear Communication: Prioritize the email sequence throughout the assignments. Set automated responses where necessary and appropriate. Save time with templated, pre-created responses.
  9. TBQ (Time, Budget, Quality) Rule: Efficient time tracking, resourcefulness and smart scheduling are the key tools to fulfil the TBQ Rule. You may meet the deadline and accomplish the goals. However, your project will be marked successful only if you are able to manage your priorities effectively, use your sources efficiently and know the impact of unforeseen events.

 

Startup Advice From Naomi Freeman

We had the pleasure to interview the coder, developer, entrepreneur and trainer Naomi Freeman last week. She shared developer tips, entrepreneurial secret sauce, her success formula and more. Here are the keynotes from our fun, honest and learning experience interview:

Startup Secret Sauce

We had to ask Naomi, who is a serial entrepreneur: what’s the secret sauce to a startup?

“You can find tons of articles talking about startup secret sauces but I think the simplest thing is to make money. That seems obvious, but when you’re in the technology space at least (and sometimes in nonprofits, too), you can kind of lose track. It’s very simple: if you’re not earning money, you don’t have a business,” she said.

If it’s such a simple secret, though, how do people get off-track?

Naomi built an AI prototype and co-founded a company around it. With that in mind, she explained:

“If you build something – and, for me, I built this prototype myself, so I was really deep in it – and the building is great but as soon as you do something cool in the technology space, suddenly you’ve got cameras on you, you’ve got venture capitalists, you’ve got accelerators coming after you. It can be really exciting but if you look on your calendar and do an exercise where you write down every single thing you do for every single hour of a week for one week or two weeks or three weeks, then go back with gold star stickers or little gold money stickers and see where you were actually doing revenue-generating activities (not trying to get venture capital).

We’re talking about meetings for partnerships, we are looking for actually talking to clients who want to pay for things and if you can’t find them anywhere on the calendar where you can put a money sticker without really stretching it, you have a problem.”

It can be exciting to be part of the Silicon Valley culture, but venture capital success doesn’t necessarily mean business success. Quite often, Naomi argues, most businesses aren’t even a good fit for the venture capital model. That doesn’t make the business a failure. It just means it’s not the right kind of business for venture capital.

Pieces Of Advice For “Entrepreneur-To-Be’s” and Project Management

What would you say to prospective entrepreneurs if you could only say one thing?

“I think the greatest advice to prospective entrepreneurs is ‘You got this! No one is gonna take you seriously, but you totally got this!’” she said.

When asked what the best advice for those wanting to dive into entrepreneurship is, Naomi stressed that there’s no single path.

“I guess, more seriously, you hear all kinds of advice about how to do a startup, how to be a founder and at the end of the day it really is a little bit unique for every single person. Some people need that support of multiple co-founders and big boards right out of the gate, some people are really most comfortable once they have a big financial partner or they’re more comfortable when they have their own autonomy.”

Given that there can be so many different ways a start-up can be structured, how do you know if you have a start-up or not?

“At the beginning with that first spark, when you move from ‘I have an idea I want to share with everyone’ to any kind of action, either you have to be all in or you have to know that it’s a great business. These are both start-ups. Whether you’re in R & D for 2 years on venture capital funding or you’re earning money but it’s not your purpose in life, you’ve still just started something. That’s a start-up.”

The best way to beat up competition with a low startup budget

“What makes a startup an unbeatable entity is the community. Again, that’s my perspective, but if it’s just me and you [two co-founders who] want to team up against the world, yeah, the wind can blow us around a lot. But if we build a community of people who come to us, who know us, root for us, it’s a lot harder to get rid of the company. It becomes a much larger, more intangible, less targetable entity.”

How do we make an unstoppable force of the community to support our business?

“There are concrete ways to build a community and it will depend on your business.

Let’s say you’re one of those subscription boxes that goes out every month – you’ve got makeup or books or food in the box. It’s really easy to put on the inside of the box ‘hey, Instagram it, tweet us, show us what you got, tell us how you’re feeling’. If it’s a book, maybe let’s talk about a book club kind of question that you post on Instagram, or blog or tweet about, where everyone can connect. In other cases, say, if you were selling socks, it could be that when you send it out – first, you make sure your boxing is amazing, the unboxing experience is like nothing you’ve ever felt before. It’s like joy comes out of that box, not just socks. Second, when you unwrap the box, there is a thank you card saying thanks so much for being part of this bigger thing.

There are different ways to create community and engage but the key is that people need a way to feel like they’re part of your team and they’re on the journey too. The funding might go but your users and people won’t.

Why are people on Facebook? Cause everyone else is on Facebook. It’s a network effect and people want to be a part of it.”

She went on to explain that you have to create that kind of community and feeling for every company. A company is not just the product(s) it’s selling. It’s also the brand identity that they sell and the community they build up around that not only shares with the company but also shares with everyone else in the community and anyone watching from outside the community.

The most common challenges developers face

What do you think the most common challenge is that developers face?

Naomi explains that the biggest challenge developers face is actually in how they connect – or disconnect – from the people around them.

“It comes back to some other things I’ve been talking about: people get inflexible and isolated. When you think you know better, even though everything around you is changing, and you cut yourself off from your team or your peers because you’re pretty sure you know better, you end up in a really dark place.

There is this myth in Silicon Valley of the individual coder – a hacker in the basement that’s doing all this crazy wire work (or whatever they’re doing) but the truth is, when grown-ups go to work, they interact with lots of other people. That’s just how modern life is.

Unless you own your own business, you don’t get the final say on ‘well, this is the future!’ Unless you own the business it’s actually not your decision what the future looks like, because what you’re really saying is that you are the best person to know what the future of the company looks like, and that’s just not true. I mean, you can take ownership for your decisions at your table but that’s within the framework of whoever owning it saying it’s okay, right?

I don’t want to discourage people but I feel like when people get a little too comfortable sitting where they are, they can end up in that place.”

We hope you enjoyed this interview and got the chance to learn a lot from Naomi’s experience, for us, FogBugz, it was very enlightening and we’re grateful to be able to share this excellent advice!

Collecting Feedback From Stakeholders Can Help You Build Software That Matters

If you want to build great products that your end users will love, collecting feedback early and often is a key step in this process. You also want to ensure that you are not just collecting feedback from the end-users but also from stakeholders within your organization. No matter if it is Charly from Marketing or Cindy from Finance, everyone’s feedback plays a vital role in building the best version of your product or software.

An unwavering and fierce commitment to not just gathering the feedback but collecting, organizing, and sharing the feedback plays a vital role in pushing your product and business forward. Feedback collection in software projects is more than bug reporting. You want to collect experiences and feelings that the users have with your software. The people side of end-user feedback helps you to shape the customer experience of your digital product. Based on a Walker study, 86% of buyers are willing to pay more for a great customer experience.

Why Feedback Matters

Frequent feedback drives and informs your decision making, saves valuable time in the long run, and influences your product/software roadmap.

Feedback is also necessary for measuring satisfaction among your current customers. These are some of your most valuable stakeholders and the kinds of things you are hearing back from your current customers should definitely not be ignored. Use the feedback to create valuable action items to continue to improve your offerings.

Haymo Meran, head of product

Learning and managing how customers view your product, support, and the company overall continues to prove invaluable. By using early and frequent user testing you can uncover things customers may not know they’re thinking about or problems they may not know they’re struggling with. This will provide you with a clear path to make the product and experience better.

If you layer user feedback through every stage of software development, not just at the beginning or the end, you are able to move fast and deliver quality. You can capture feedback manually or with tools  (for internal & external feedback). With integrations available between feedback collection tools/bug tracking/user feedback applications (like Usersnap) and project management software (like FogBugz), you can cover all your bases in the need for feedback from everyone involved.

Screenshot: Usersnap + FogBugz integrated

“How To Do It” Manually

There are many manual ways to capture feedback from users in real time that can sometimes prove to still be effective. Manual feedback collection can be valuable in connecting with the people side of your software or product, especially internally within your organization. During this Digital Age, with technology keeping us connected more than ever, reaching out through email or live chat can be quick and easy. Here are some ways you can quickly capture feedback from the people side:

  • Creating a feedback survey
: Using applications like Survey Monkey, you can quickly and easily create a comprehensive survey to determine things like how the user feels about your software overall? The ease of use? etc. Stakeholders easily reach this survey through a link or from within an email.
  • Direct email and customer contact forms
: Email is one of the most valuable ways to gather candid customer feedback. Sometimes you won’t get a specific answer to your question until you ask. Many people still want to feel valued and like their opinion matters. So you can capitalize on this by simply sending an email and asking what they think.
  • Direct exploratory user interviews: 
It is very true that understanding your stakeholders and users is often as easy as talking to them directly. This can be accomplished through a face-to-face interview or through online video chat applications like Zoom.
  • Through social media
: Social media is a very powerful (and becoming more and more powerful) tool to reach your stakeholders and prospective customer base. There’s always direct comments to your probing social media post or mentions on social networks. But many social networks now have effective polling tools built in. All you have to do is simply ask a question that you want users to respond to.

The downside to manually reaching out to people to collect feedback is not on the front side, but on the backside when you receive responses. It can quickly become very difficult to differentiate the feedback and organize it so that you can learn from it and create action items. Next thing you know you’re getting isses reported, bug reports, and customer feedback from different channels all over the place. Your alerts start going crazy and you start getting pinged on Slack, email, or even in person from teammates about a button that doesn’t look like it is sized right or a request from a user for additional functionality they suggest for in the future. When feedback is reported through different channels, it quickly becomes hard for product managers to get a single backlog of all the user feedback that needs their attention—let alone organize and prioritize the most critical items for necessary immediate action.

This is why it is effective, time-saving and cost-effective to utilize powerful comprehensive tools and technology that can do this for you and allow you and your team to deliver great products faster.

“How To Do It” Effectively

Manual processes are often a lot of work. That is why we suggest a more automated way. If you utilize an automated feedback software, you can capture feedback effectively where it happens and where your users are. This software should be working inside your website or web-based application directly within the browser. After capturing this feedback you need, a software for that can manage all of the responses and move them to the appropriate development teams.

If you use a visual user feedback application in conjunction with a powerful project management software, you will quickly learn how much easier the flow of feedback into your product will become.

There is actually a powerful combination of tools available that can make your feedback collection completely streamlined. You can easily utilize the software program Usersnap for feedback capturing and FogBugz, which is seamlessly integrated, for managing thousands of feedback items.

FogBugz is a comprehensive project management software that helps you spend less time on managing and organizing and more time on creating great digital products. Through a project management system like this, you can easily align your team under a common purpose and set of goals. This allows you to plan, track, and release great software and products. FogBugz provides all you need to make great software, including project management, issue tracking, and support, fused with just enough process to help you deliver. Plus, there’s robust integration with other best of breed tools like Usersnap, Slack, GitHub, and Google Docs.

Screenshot: FogBugz

With the seamless integration of FogBugz and Usersnap, you can save valuable time and resources, and also improve accuracy in bug reporting and feedback versus manual methods.  Used by over 20,000 software development teams, FogBugz is a system that makes it easy to monitor your projects. It helps your team to focus on the tasks that need to be done. You can capture features, tasks, and customer requests in a central location.

Now that you’ve got the project management side covered you have to take a look at your testing and feedback tool side. Bug tracking, website testing, and issue tracking with Usersnap have never been easier. Utilizing the built-in point and click issue reporting, you get visual feedback and additional information faster into your FogBugz project. Now, no you don’t have to ever worry about endless bug reporting for your users again.

Once you have successfully connected Usersnap with FogBugz, you will receive annotated screenshots to your FogBugz project, along with records of advanced client-side JavaScript errors as they occur, every time a bug report or feedback is created with Usersnap. This helps to bring designers, developers, and project managers together on the same page better than many other alternatives. It is very true that a screenshot often paints a thousand words and helps you deliver great products faster.

Screenshot: Usersnap feedback widget in a website

Using a bug tracking and visual feedback application like Usersnap allows your customers or stakeholders to provide a visual description of what might be a bug in form of annotated screenshots. You also get important information such as what browser was used, the used operating system, and the exact location or URL where the bug has occurred. Your testers have the option to use a drawing pen, a highlighting tool, and sticky notes to illustrate and annotate the bug report. With a screen capturing tool enabled you’ll get so much more out of the bug reports in your project management system.

“Usersnap is a great tool for real-time user experience reporting. Our development team relies on Usersnap to effectively capture bugs and user issues as they relate to the user experience. Kudos to Usersnap for easy user adoption.” Tim Smith, HLT

You can solve your project management tickets in FogBugz faster with browser screenshots from your feedback software like Usersnap.

Get detailed information on the integration of Usersnap and FogBugz.

Screenshot: Dashboard of Usersnap

Wrapping It Up

Discovering issues and bugs during the development stage of your product or software saves your precious resources, time, and money compared to if they are just detected during testing or worse during the application launch phase. You want to utilize effective visual testing and feedback through all phases of development.

Utilizing an integration of a project management software and a user testing platform can help you keep your feedback organized and prioritized so that you can address the most pressing issues and create action items to move your team forward on.

Usersnap helps Making Feedback Matter and FogBugz helps Building Software that Matters.
Perfect combination or what? ☺

Start your free 15-days trial of Usersnap seamlessly integrated with FogBugz along with your FogBugz subscription if you haven’t already. No credit card. No strings attached.

Klaus-M. Schremser
Head of Growth, Usersnap


Older posts