The Worst Code

Every developer has been there — late at night, with a deadline looming, we pile hack on top of hack to finish, without regard for tests and edge cases. Many of us think that these situations lead to the worst code we could possibly write. But avoiding writing the worst code ultimately comes down to one thing — the human factor. Michele Titolo defines what a team is, before introducing the concept of “organizational smells”: people‑related bugs in teams that cause projects to delay, deliver late, or just crash and burn.

---

The Worst Code (0:00)

I’m here to talk about the worst code. I’ve built a lot of apps, and I’ve learned a lot about how to create software. But this talk is about how not to create software, because as much as we love patterns, sometimes you need a little reminding that some ways are really not the best ways to do something. There are some underlying tools that you could use to identify situations that will lead to writing really bad code. Hopefully, the next time you see something like this happening, you’ll understand before you get to the last minute crunch to fixing everything that is broken.

After all that, you’re probably all thinking that this is going to be a talk about soft skills. Don’t call them that. These are really fundamental skills that you need to work on a team cohesively, and they are kind of a requirement for being a developer these days. There are very few people in our industry who have the luxury of never, ever talking to anyone else about the software they’re working on. Most of us work on teams. Software is ultimately about people.

People and Teams (2:18)

First, I’m going to go through some terms that I have taken from some academic papers so that we can all have a foundation to go through the rest of the talk together. The first paper, out of Cornell University, is called “Work Group and Teams in Organization”. We all work on teams; people don’t work on things alone. Let’s define a team:

“A team is a group composed of two or more individuals who have a shared or common goal, who perform tasks towards that goal, where the tasks are interdependent and work within the same boundaries.”

Multiple people, goals, interdependent tasks, and boundaries are the fundamentals of what actually defines a team. If you’re trying to figure out if someone is on your team or not, you can go through those four points and see if this person has the same kind of boundaries that you do. For example, if they have root access to the production server, they might not be on your team.

Team Effectiveness (4:41)

What is team effectiveness? We have all these people working together, so we need to figure out how we can tell if they’re working well together. There are three aspects: coordination, collaboration, and communication. All of these are, again, really hand-wavy words that we throw around all the time, but don’t quite always know what they mean.

Coordination is the activities required to manage interdependencies with the team work flow. In a coordinated team, people are working together. Cooperation is the willful contribution of personal efforts to the completion of interdependent jobs. So, people will actually do the things they say they’re going to do. Finally, communication is a means for enabling coordination and cooperation.

What enables coordination & cooperation to work is communication. Now, as most of you probably know, communication is kind of difficult. In fact, it’s so difficult that we have lots memes about it. But it’s not the only thing that can go wrong. It tends to be the thing that goes wrong more frequently, but that’s just because the other two depend on it happening.

Effective Communication (6:16)

Failures in communication often result from failures in cooperation or coordination. The second academic paper of the day comes out of the MIT Human Dynamics Laboratory. Published in the Harvard Business Review, it’s called the “New Science of Building Great Teams”. MIT has created devices that people wear around, which collect metrics on how they communicate with other people. I’m about to show you a whole bunch of data science that’s all about effective communication. How do people talk to each other? How often do they interact? Is one person jumping up and down trying to get someone’s attention and just not?

Team Communication (7:00)

So, here are two graphs that come out of that paper. They represent the different frequency and amount of communication between people on each team. The high performing team has a higher frequency and more communication in the team. What this ends up being is a balance, because you can’t have one person talking too much, and you can’t have one person not talking. Everyone needs to be engaged, and everyone needs to be communicating. It becomes a balance between everyone on the team doing their part to make it efficient and work.

Organizational Smells (8:25)

Why should you care that I just spent five minutes talking to you about teams and communication? The answer is because we all know about these things called code smells. They are things that look okay on the outside, but once you dig a little bit deeper, take a little bit of a closer look, you realize that it isn’t okay.

I’m going to introduce you to a term that I don’t know if anyone else uses, but I’m going to use it, called organizational smells. There are things that you probably see everyday, that you don’t necessarily know are bad and you don’t necessarily see the later ramifications. But, they are probably things you want to take a closer look at.

Team Within a Team (8:43)

The first one is called Team-Within-a-Team. This is when you have a team, and a little sub-team forms. This usually happens when there is either some official or unofficial hierarchy involved, where people who just happen to have more domain knowledge and therefore, are the ones doing most of the communication. Or, these are the people who interact more with other parts of the company on a daily basis, and thus seem important.

In the end, this causes everyone who isn’t on that little micro-team to be not part of the team. Because they’re not being asked their opinion or for their domain knowledge, they’re not being included in discussions. So this really, really makes the team and a project lose perspective really fast — you can’t work together if you don’t all know what’s going on. In terms of the code smells, this leads to things like making really poor architecture decisions. For example, someone says, “Oh, I didn’t know that we need to have a deep link into this part of the application. Oops.” Then, other things can happen like someone writes a component but doesn’t have tests, or one change in one part of the app breaks the rest of the app, and all those kinds of things.

Central Command (10:08)

The next is what I’m calling Central Command. This is a slightly more exaggerated version of Team-Within-a-Team, where you have one person at the center of a spoke wheel doing all of the communication. This isn’t necessarily a bad thing, because sometimes people just really, really want to be helpful. They want to make sure that everyone is involved, be a good team player, and are super, incredibly enthusiastic. But that can be bad; we’re all developers, and we all know that single points of failures are bad and should be avoided.

If that person gets sick, goes on parental leave, or quits the company, you have essentially lost the one glue piece holding this team together. In terms of the code smells that happen, it’s like being on a one way street where people are trying to go the wrong way because they don’t know. There’s one person controlling all of the information flow, and therefore, that’s the only person that has any idea what’s going on. So it’s way, way worse.

Isolation (11:22)

Next is Isolation. This happens when people on the team don’t communicate, don’t coordinate, and just don’t talk to each other. You’ll find that this happens a lot in software teams because we’re all working on different components. If you’re working at a company where someone owns the network code, someone owns the data code, and someone owns the view code, not communicating effectively will result in not being able to build a cohesive application. This makes it really, really hard to ship.

This also tends to happen when people only communicate negatively towards each other. If you’re only ever talking to each other to say that someone broke your code, people don’t like that. The foundation of human interaction is trust and respect. If someone is coming to you only when things break, you’re not going to want to interact and work with that person.

This is the worst in terms of the code smells, because everything is literally a mess. No one is talking to each other, so you end up having two different ways for making web requests. There’s no documentation or, at least, there’s not consistent documentation. So, you have to try and talk to someone who doesn’t want to talk to you in order to get stuff done.

This is something that happens between teams a lot of the time. I don’t know how many people have released a brand new feature to their app, but not talked to customer support or customer service to let them know it’s coming. Then all of a sudden, a brand new, amazing feature is promoted on the website, and customer support has absolutely no idea what it is. In general, this is just not a good thing.

Unreachable Goal (13:13)

Then we have what I call the Unreachable Goal. If you have a goal, you obviously want to be able to get to it. As a team, you’re all working to the same goal. Sometimes it’s just really far away, and you can’t ever seem to get to it. Sometimes it just disappears, and you really don’t know what you’re supposed to be building.

What ends up happening is that the team falls apart. No one is talking to each other, no one knows what’s going on, the app is not consistent, there are crashes, and things are just really bad. This causes things like spaghetti code and things not getting finished, which happens a lot when you don’t know what you’re doing. It’s hard to build something if you don’t know where you’re going.

My uncle worked at a client services company that had an enterprise software product, and two or three times a week, his boss would tell him to stop what he was doing and to work on something else. This would happen very frequently, because people who worked there were very good at fighting fires. If you’re constantly changing what you’re working on every day, you have to learn to adapt. The bad part was that literally nothing got done, because they were never able to finish what they had been working on originally. It becomes a problem when you are just working on the next and hopefully deploying & shipping.

Black Sheep (15:14)

Then we have the Black Sheep. This is when you have a team and you think everything is fantastic, but it turns out that someone is not really who you think they are. Sometimes they’re not actually trying to help you on your team. People have their own agendas: maybe someone wants to move up into management, or maybe someone has this idea that they really want to build, but doesn’t quite work with what the company and product team is doing, but they’re going to do it anyway. This person has ulterior motives. This is the hardest thing to see, because you can’t tell until that person outwardly says “I’m not working on that”, or perhaps stops talking to you. They are a wolf in sheep’s clothing, and you don’t know what’s going on.

This can actually cause a lot more chaos. When people do this, they often say they’re going to do things and then just don’t do them. Essentially, this is a fundamental breaking point and a big, big, stop. You should stop working if something like this happens because it’s huge, and it makes you lose fundamental trust and respect for that person. If you can’t trust a member of your team to do something, that’s a problem. You’re not going be able to work together, and you’re not going to be able to move forward together.

Unfortunately, that usually ends up spreading. One person starts not trusting, and then the other people start not trusting, and then it just goes around in a merry-go-round circle until your team isn’t talking to each other. Everyone is unhappy, the product fails, and everybody leaves.

Patterns (17:21)

So, I just talked a lot about anti-patterns, which are really fantastic things that people in the software industry love having examples of. That was a lot of negativity, so I’ll end on a high note. There is a lot of research that you can get lost in really easily if you really want to learn more about how teams work effectively.

The last paper I want to talk about is called the “Processes and Attributes of Highly Effective Teams”. This amazing, wonderful paper goes through all of the significant research done on this topic since 1989 and puts a bulleted list together of all the attributes and processes of really effective teams. This is a really short paper, so it’s great if you’re looking for a really easy mental check on how your team is working.

You could essentially use it as a bulleted list to figure out whether or not you’re in a situation that is really, really good. It also has amazing little tips and tricks. Because it’s an academic paper, it has a very long list of citations, so you can go in and read more from any of those.

Today, I hope you all learned some things about people, and hopefully you all work on really great teams in the future. Thanks.

Q&A (19:16)

Q: I’ve been in teams where we had a black sheep, and nobody could work with him. How could we integrate this person to make him part of the same process?

Michele: This is going back to coordination, cooperation, and communication. If that person isn’t willing to work with you, they shouldn’t be on your team. It’s usually a hard decision that companies have to make, sometimes, to make sure that the team dynamics are correct. You need to make sure that person is on board with what everyone else is doing. One piece of advice that I was given recently is, if you’re in a dissenting conversation where you just can’t agree, you have to have enough trust for the other people on your team. At the end of the day, we’re all working together, but that person might not be.

But, you also need to acknowledge other people. One of the things that we tend to do as human beings, especially when you’re in a heated argument, is tell people they’re totally wrong. What people really want to hear is, “I’m listening to you, but I think this is a better thing.” Eventually someone has to make a call, and that’s when the whole hierarchy structure comes into play if you can’t fix it yourself. You want to figure out if that person is really doing good work for the team, because if they’re working on their own thing, they’re not doing their job.

Q: When do you bring in the HR department?

Michele: Honestly, it really depends on your situation and your team. I know a that lot of HR companies, and especially at small startups, are usually overworked. It ends up being a lot of a talk from a manager. A good time to do that is when a deadline has hit, or when something concrete has happened, because people like concrete reasons.

Q: In my experience, one of the issues that drive difficulties is a lack of clarity about goals. Can you can speak more about what goals actually are, and how you set them?

Michele: The last paper I mentioned has at least an entire page of bullets dedicated to goals. Goal-making is something that I personally believe the entire team should be a part of. When we are building a product, we not only need to understand how it works, but why it needs to work in a particular way.

Deep linking is one of my favorite examples: if you’re ready to ship a product, but someone suddenly wants to send push notifications to get somehwere in an app, you could be facing a huge overhaul for application architecture. Everyone needs to work together. Versioning is really important. As decisions get made and things are changed, it’s good to have a history. Specs are not only useful for you while you’re developing, but if in three months, you’re trying to figure out why this thing works the way it did, you actually have things written down. As much as we love Slack or meetings by the white board, the first step to having a really clear goal is writing something down. Then, talk with everyone, and make sure everyone is involved and on-board.

Q: On the successful teams that you’ve worked on, has there been a point where you just had to decide on something being your central channel of communication?

Michele: That’s a problem that anyone deals with when they have distributed teams. In my last consulting job, we obviously had clients that were not on site, and offices in San Francisco and New York. Products were frequently worked on between the two offices. We found that what worked best was defining where things would go. If you were out sick or working from home, you could say that in Slack. If it was more formal, like being out of the office for a week, you send an email. For really important things, useful to both software and non-software projects, we needed a central repository for knowledge.

This is something that we also did in Women Who Code, a global non-profit that has over 30,000 members worldwide and over 150 city directors. Because so many people need our resources and guidance, we actually have a GitHub repository that all of our directors have access to, in which we keep all of our internal resources documented. Any time someone wants to make a change, they can just make a pull request, or we add things and announce that. You can also set times on your calendar when you’ll be home for something. For your distributed team, always update your calendar with when you’re available and when you’re not. If you’re not online, that’s the first place someone will look.

Q: You said that a lack in communication was a result of the coordination and collaboration not working. In my experience, it always seemed the other way around, that the other two wouldn’t work because there was a gap in communication. Am I looking for the problem in the wrong spot, or does it work both ways?

Michele: It really ends up being both. The definition of communication that I used depends on the other two. Without the other two, there’s simply no communication. It becomes dictating, or not talking. So, it does go both ways. It is foundational in the sense that communication can’t exist without those other two happening, but those other two also need communication in order to work properly. Everything is all related; I could have put it as a triangle where they all connect to work effectively.

Q: You talked about how good communication comes from everyone feeling like they’re part of the team. In the end, some people do need to be in charge, so how do you balance that with having a hierarchy?

Michele: That relates to the definition of a team, where people have different boundaries. A manager in many organizations has a different set of boundaries in which they operate in a company. Therefore, yourmanager in most situations is not on your team. There’s a team of managers, usually, that all work within the same boundaries. They’re doing different tasks, but that’s where the hierarchy comes into play. It’s all about those four things that make up a team, and if someone doesn’t meet one of those criteria, they aren’t on your team. If someone can come in and just change the goals for your entire team, whenever they want, that person is not actually part of the team.