How (Not) To Collaborate

Collaboration is one of the most essential human skills, not just in work but in life generally, and yet it’s poorly taught (if at all) and a lot of people are bad at it. Programmers are especially bad at it, for a whole variety of reasons, and this last week has been like a crash course in just how bad. Collaboration means exchanging ideas. Here’s how I have seen people fail to participate in such exchanges recently.

  • Passive ignoring. No response at all.
  • Active ignoring. Nod, smile, put it on a list to die. This is what a lot of people do when they’ve been told they need to work on their collaboration skills, and want to create an appearance of collaboration without actually working at it.
  • Rejection. All variants of “no” and “what a terrible idea” and “my idea’s better” fall into this category.
  • “It’s my idea now.” The obvious version is just presenting the idea unchanged, as one’s own. The sneakier alternative is to tweak it a little, or re-implement it, so it’s not obvious it’s the same, but still present derivative work without credit to the original.
  • “It’s your problem now.” This is probably the most insidious of all. It presents an appearance of accession, but in fact no exchange of ideas has occurred. Just as importantly, the person doing this has presumed unilateral authority to decide whose problem it is, creating an unequal relationship.

The key to real collaboration is not only to accept a single idea itself, but to facilitate further exchange. Here are some ways to make that work.

  • Accept the context. Respect the priority that the other person gives to the idea along with the idea itself. , Assume some responsibility for facilitating it. Don’t force people to remind, re-submit or nag before you’ll really consider what they’re suggesting. Both active and passive ignoring are wrong because they violate this principle.
  • Don’t attach strings. Don’t make people jump through unnecessary hoops, or demand that they assume responsibility for more than the subject of their idea, just to have their idea considered. Obviously, “your problem now” and its cousin “you touch it you own it” violate this rule. I’ve left more jobs because of this tendency, which leaves people shackled to responsibilities they never asked for, than for any other reason. I don’t think I’m the only one.
  • Be a teacher, not a judge. Every opportunity for rejection is also an opportunity for teaching. If there’s something truly wrong with an idea, you should be able to explain the problem in such a way that everyone benefits. You owe it to your team or your community or even your friends and family to develop this skill.
  • Give credit. It will come back to you. People rarely give freely to notorious thieves and hoarders.

Note that I’m not making any appeals to morality here. I’m not saying it’s right to make collaboration easier. I’m saying it’s practical. When you make collaboration with you easy and pleasant, people want to do it more. That frees you to work on the problems that most interest you, and share credit for a successful project instead of getting no credit at all for a failed or stagnant one. When people try to do you a favor, try to accept graciously.

Be a Better Raindrop

no single raindrop believes it is to blame for the flood

The computing industry is already awash in condescension and negativity, and it’s getting worse. Yes, I know it’s not a new phenomenon, but I’ve been around long enough to be sure of the trend. I’ve been blogging for over a decade, I was on Usenet even longer than that before, and I was on other forums even before that. I know all about operating-system wars, language wars, editor wars, license wars, and their ilk. I’ve fought many of those wars myself. Still, things seem to be getting worse. Practically no technical news nowadays comes unaccompanied by a chorus of hatred from those who prefer alternatives. Half the time I find out about something that’s really pretty cool only because I see the bitching about it. How sad is that?

The thing is, it really doesn’t matter why people act this way. Yes, some people are just basically spiteful or insecure. Others might think they’re acting from more noble motives, such as bursting a hype bubble or squashing an idea they believe is truly dangerous. Half of the articles on this site are based in such motivations, so I’m by no means claiming innocence. The problem is that even the best-motivated snark still contributes to the generally unpleasant atmosphere. Contrary to popular belief, we techies are social animals. We have our own equivalent of the Overton Window. Every Linus eruption or similar event from a perceived leader shifts that window toward a higher spleen-to-brain ratio. Others emulate that example, and the phenomenon reinforces itself. Those of us who are older, who are leaders, who find ourselves quoted often, owe it to the community not to keep shifting that window in the wrong direction. That’s not being “honest” or “blunt” or “clear” either, if your honesty/bluntness/clarity is only apparent when your comments are negative. Real life is not one-sided. If your commentary is, then you’re not being any of those things. You’re just being part of the problem.

Linus not helping

No one of us caused this and no one of us can fix it. However, we can each try to do better. That’s my New Year’s resolution: to start taking the high road and giving people the benefit of the doubt just a bit more often. Sure, some people might get besotted with a particular idea or technology that I think is inferior, but that doesn’t make them stupid or bad. Some people might get carried away with their praise for a company or its products/people, but that doesn’t make them fanbois or shills. Some people are all of those things, and I’m sure I’ll still let slip the dogs of war from time to time when the occasion warrants it, but I’ll at least try to adopt a doctrine of no first strikes and proportional response instead of the ever escalating verbal violence that is now commonplace. Would anyone else like to give it a try?

Today’s Memes

Some people will know what I’m talking about. Some won’t.

crazy-config meme

new-release meme

Open Source: Doing It Wrong

Hi, here are fifteen patches to make your code work on my platform. I haven’t tested to see if it still works on any other platform. Heck, it might not even build[1]. I know you have a well defined patch submission process, but I didn’t use it because it’s not what I’m used to. Also, I couldn’t be bothered rebasing to the current code, so the patches might not apply cleanly[2] and they all depend on each other. I’m sure you can find someone to shepherd these through your review process, because their time is surely worth less than my own. If you don’t accept these, I’ll tell all my friends how your project isn’t really open to outside contributors and I was forced to create my own fork. Have a nice day[3].

[1] No, it didn’t.
[2] Ditto.
[3] Die in a fire.

GPL Doesn’t Kill People

It’s kind of sad that anyone even needs to say such a thing, but apparently Matt Gemmell needs a reminder. In the middle of many good points about the Sparrow acquisition (good even though I found Rian van der Merwe‘s take even more insightful), Matt drops this huge turd.

It’d be a shitty, reduced, pale imitation of what Sparrow actually was, because the developers would have had to take so much time off to attend the funerals of their families who had died from starvation.

WTF, Matt? That’s incredibly offensive to those who’ve actually had to attend the funerals of their families, or have seen real starvation up close. Even when one strips away the hyperbole, though, it’s still quite wrong. I work on GPL software, and my family hasn’t starved. We’ve done quite well, in fact, and we’re only one among thousands of Red Hat families who could say the same. That’s because there’s a real open-source business model that Matt doesn’t seem to understand. Sure, you give up the immediate revenue from the software purchase cost, but it turns out that recurring-revenue models outperform one-time-revenue models and those are still possible with open source. People will still pay for the earliest and easiest updates. They’ll still pay for guaranteed support by dedicated support professionals instead of “whenever the developer feels like it” support. They’ll still pay for training and certification. They’ll pay more for all of those things as a package than separately, which may be a quirk of human psychology but the effect is still real. The subscription model works, and I’m part of the empirical evidence for that.

That’s all what makes open source equal to closed source, but it turns out that there are other things make it better. For one thing, even though “you have the source so you can fix it yourself” is utterly useless to 99.9% of users who lack the skills to make meaningful change, you’d be surprised how much of a difference that 0.1% can make. Even if only 0.1% of your users ever contribute anything, with thousands of users that can significantly augment your in-house development team. People who just want/need one specific feature to support their separate business, and don’t mind sharing that feature with the rest of the world, might add it themselves. Alternatively, those who lack the skills/resources do so it themselves can sponsor such development either by the original developers or by various consultancies. Take a look at gcc, for example, which has benefited from this phenomenon many times allowing hundreds of developers to make a good living despite the existence of many closed-source competitors over the years. The net result is that open source can often enable software to evolve more quickly than the same development team could do with closed source.

There’s also an ecosystem element to this. Besides accelerating development of a particular package, open source can accelerate development of all alternatives in a technical area. Open source gives newcomers a way to develop valuable domain-specific skills. Similar open source projects can share libraries and frameworks, reducing duplication of effort. Also, the mere existence of an open source competitor can increase knowledge about what’s possible, what users really want, what problems still need to be solved, etc. That’s valuable knowledge, which might otherwise take a lot of resources – or trial and error risking customer defection – to gain. Increasing the total number of users within a category, even if they’re not your users, helps the whole category – including even the closed source parts of it – make technical progress. For example, look at NoSQL or Hadoop. Much of what they do is not dissimilar to products that existed in more closed form before, but once there were a significant number of open source offerings the number of users (and developers BTW) absolutely exploded. The result has been a phenomenal increase in the pace of development across the board, for all participants.

Open source both creates a bigger pie and supports monetization of that pie. Nobody starves. The only people who don’t benefit are those who remain blind to how the open source business model actually works, who think they can use FUD to compete against it. Well, too bad for them.

Coding Metaphor: The Dangerous Room

I came up with this little parable about coding in complex systems. Warning: it’s a bit graphic.

Imagine you have a remote view of an ordinary room, with doors at each end. You see a man enter at one end. He crosses to the other end, pausing a couple of times and once stooping to examine something on the floor, then exits at the other end. There seems to be nothing remarkable about this. Then you watch a second man try to cross the room. When he gets half-way across, panels in the walls slide down and the man is skewered with arrows from several hidden crossbows. The screen flickers. A third man tries to cross, and doesn’t even get a quarter of the way across before a green gas seeps from vents near the ceiling and he collapses. The screen flickers again. After you watch a score more of failed attempts to cross the room, the smoke from the latest explosion reveals something: the room is criss-crossed with beams of light, some of which turn on and off, and it’s when people cross these beams that Bad Things happen. You think back to the first man, and realize that he might crossed in the only possible safe way. You briefly consider that he was lucky, but it’s just too implausible. It’s much more likely that he knew exactly what he was doing, that his pauses and stooping were carefully calculated to avoid the various traps. Only then do you realize how skillful his performance was.

Yeah, I know, it’s like those “ninja” metaphors that I usually consider so childish. I was going to try something less colorful, but Amy happened to overhear this little story as I was trying it out on Cindy, and she keeps asking me to tell it again, so maybe being childish isn’t so bad. Anyway, the point is that working on a very complex system (such as I do on GlusterFS) can be a bit like crossing that room. The code contains all sorts of hidden traps for the unwary. I’ve taken my share of arrows in the knee, that’s for sure (and now you know what inspired the metaphor). Usually you have to go through many iterations of being that second or third or tenth person before you have a day where you feel like that first one. You know all of the non-obvious requirements and constraints (traps) between you and what you’re trying to accomplish. Maybe you even relax (disarm) a couple, but mostly you just do the delicate dance around them and get to the point where your new feature works (get out alive). Then somebody watching says, “Pffft, you just walked across a room. What’s hard about that?” That’s why people who have learned – the hard way – how to bend a piece of code in ways it wasn’t originally intended to bend sometimes seem intolerant of dabblers’ or onlookers’ commentary. That’s one of the reasons I stuck with this metaphor: the complexity is hidden. I thought of using a different metaphor of a complex mechanism with many levers and such, but anyone seeing such a mechanism would realize it’s complex. In this case, you could watch the first man cross the room a hundred times and never realize he was engaged in a complex task.

If there’s a moral here, it’s twofold. First, don’t assume something’s easy just because you see someone do it without mishap or obvious effort. They might be applying a great deal of hard-won knowledge to make things go so smoothly. Second, when you’re attempting to do something in a complex environment, expect that you’ll get killed a few times. Respect the dangers, but don’t be afraid of them. You can always reload from your last save. Each time you find a trap, you learn. After enough tries, you might find a way to avoid them all, and the result might even be more satisfying than if things had been easy to begin with.

Why Buy RHEL?

Yet again, I’m going to post about something related to my employer. Yet again, I’m going to reiterate that this is not an official Red Hat position. In fact, I more than half expect I’ll get in trouble for saying it, but it just had to be said. You see, there’s a discussion on Slashdot about How Can I Justify Using Red Hat When CentOS Exists? The poster wants the functionality of Red Hat Enterprise Linux, but the CIO doesn’t want to pay for it and demands that they use CentOS instead. A lot of people have tried to explain the various aspects of what a RHEL subscription gets you. I’m not going to expand or correct those comments, because that will definitely get me in trouble and partly because I just don’t care. Here’s the reason that apparently carries no weight at all with CIOs and never even occurs to Slashdotters.

Because it’s the fucking right thing to do, you assholes.

Yeah, I used profanity on what has almost always been a family-friendly blog. I did that because it’s so utterly infuriating that such an obvious and important principle has totally escaped notice elsewhere. If you value something, you pay for it. Even the worst free-market zealots claim to believe that. They often use the same rationale to justify eliminating regulations (especially environmental ones) or replacing public aid with private charity. Red Hat folks do more work than anyone to improve the Linux kernel, GNOME, and dozens of other projects. They write the code, do the testing, fix the bugs, write the documentation, and provide all kinds of logistical support. The beneficiaries include not just obvious derivatives like CentOS and Scientific but even commercial competitors from Oracle and Amazon’s obvious clones to completely separate distributions like Ubuntu which also package that code and fixes. This work isn’t done by volunteers. It costs a lot of money. The fact that we allow the code to be distributed for free should have nothing to do with the principle that you pay for what you value. When you violate that principle you ensure that there will be less of what you value. The result will be a net loss for everyone, as less innovation occurs and more energy is wasted making sure everyone’s “intellectual property” remains under lock and key. Even the thieves lose.

I’d really like to hear from someone who can offer a better moral justification than “we can so we should” for using CentOS on thousands of machines without paying for even one RHEL subscription, because nothing I’ve heard so far is even close. “Duty to maximize profits” arguments will be deleted, because I’ve already turned that one into swiss cheese enough times in my life. Does anybody seriously believe that freeloading should be on the “good” side of our collective moral map?

Don’t Be a Jerk

Charles Hooper wrote an interesting article about Letting Tech People be Socially Inept, in response to a recent incident at ThisWebHost where a technical director got mad at a customer and deleted data. There’s so much wrong here that it’s hard to know where to begin. “Jules” at This* was totally in the wrong. Charles is also wrong when he says that every position is customer-facing. Some people can do really great work only interacting with one person – usually their boss – and referring to that one person as a “customer” seems rather facile to me. Most of all, though, the puntwits on Hacker News are wrong too.

Probably the most common theme in the HN responses is that high technical skill and eschewing social niceties are closely and necessarily related because they both involve pruning away extraneous detail to get to the heart of something complex. For example, the very first comment there refers to “seemingly-meaningless boilerplate and social grease that we call people skills” and sets the tone for many that follow. The problem I have with this is two-fold. First, a lot of the bad behavior I see from my colleagues has nothing to do with social niceties. Go look at How To Ruin a Project and you’ll see that many of the items listed there don’t have anything to do with social skills. You don’t need a fine understanding of social cues to realize it’s wrong to miss the point, focus on the trivial, or wage “guerilla warfare” against a decision you don’t like. Those things might well have social effects, but they’re wrong even for purely practical reasons as well.

My other objection to the “boilerplate and grease” meme is that social cues actually do serve a practical purpose. They help to identify how strongly someone holds a belief, and how much importance they attach to the subject. Without that information, it’s easy to waste enormous amounts of time fighting wars that didn’t really need to be fought, and sometimes that leaves little time or energy – or poisons the atmosphere – for the debates that really do need to occur. One of the real problems I see with my fellow techies is a general lack of perspective, proportion, or priority. People who fail to give or read cues regarding these three important factors are demonstrating a deficiency that can affect even the most purely technical decision making. Being socially inept is not just cosmetic; it has a real and tangible effect on overall competence.

That brings me to the second most common theme in the HN responses: Asperger’s Syndrome. I’ve known quite a few real Aspies. I’ve known even more people who self-diagnose or self-identify that way as an excuse for being lazy about social interaction, so I won’t claim that I’m that way myself, but I will say I’m close enough (as is visibly the case for most of the other males in my family) to understand the challenges they face. I understand the “gravity” that always pulls one’s thoughts inward, and I know the pain of having to pull one’s attention away to deal with the “noise” that other people can generate. I will gladly do everything I can to accommodate people for whom these burdens truly are greater. I’ll teach them coping strategies I’ve learned from others, act as interpreter, run interference for them, whatever. However, there’s a difference here. It’s one thing to have a hard time understanding social cues. It’s another thing to understand those cues perfectly well and use that knowledge to troll more effectively. It’s really not that hard to tell the difference between an Aspie and an asshole; those who throw spitballs from behind a shield meant for others are not only jerks but cowards as well.

My conclusion is that Charles was wrong about everyone being customer facing, but right about the more fundamental reality that we techies in general need to stop being such jerks. We need to stop enabling the jerks by applauding when they act in deliberately offensive ways on HN, on Twitter, in conference presentations, etc. We need to stop pretending that the combative style prevalent on HN or LKML is the best way to facilitate progress; there’s no empirical evidence that “culling the herd” or “honing one’s weapons” or other such bloody metaphors really apply. We need to stop encouraging young techies to expend their energy emulating those styles instead of developing real people skills. Social skills really do serve a useful purpose, and anyone can improve them. That doesn’t make you less technical; it makes you more adult.

Running an Open Source Project

I think a lot of medium-to-senior programmers think it would be cool to run their open-source project, particularly if they have chafed under the leadership of someone else on another project. I’m not going to say it’s not fun, but after having done this for a while I think a word of warning is in order. You’re going to spend a lot of your time, for long stretches practically all of it, doing things besides the design/code/test cycle that individual contributors get to focus on. Here’s an assuredly partial list.

  • Be your own IT staff. Set up a source code repository, mailing list, bug tracker, website, etc. Sure, there are distros and forges that will be glad to help with some of this, and it’s definitely better than having to set up every bit of software and keep up with every security issue on your own leased machines yourself, but even then you get to deal with someone else’s infrastructure team and release schedule.
  • Be your own release engineer. The second biggest time-suck in your life is going to be managing branches and shepherding patches. As much as you might hate rigid coding standards and checkin policies, you’re almost certainly going to be the one defining and enforcing those for any project with more than (in my experience) two developers because otherwise things very quickly get out of control. On top of that, you get to deal with packaging as well and packaging issues can often take more time to resolve than almost any technical issue.
  • Be your own HR department. Whether you’re actually hiring or just attracting developers for your project, you’re going to have to spend some time recruiting others’ participation. It’s actually harder for pure open source, because you can neither offer money nor do a proper interview. Some people who work in easy/popular specialties act as though interviews are passe anyway, but that’s total BS. There are still fields where most of the advanced work is still being done behind closed doors. If you relied on GitHub profiles to hire people for work on distributed replication, SSD tiering, or especially de-duplication, you’d practically guarantee that you’re getting the wannabes instead of the true experts (not that the “GitHub or git out” crowd is qualified to tell the difference). You’re going to end up interviewing and evaluating people either before they go through the door or after. Since it’s really hard to get rid of an incompetent or toxic person after, you owe it to yourself and the other members of your team to do the filtering before.
  • Be your own marketing department. If you work at an actual company, whether startup or established, you might have full-time marketing folks to attract business interest, but they’ll be all but totally useless (and disinterested) when it comes to attracting technical interest so this is going to be the biggest expenditure of your time. Blog, tweet, attend conferences, respond to inquiries in email and IRC. Lather, rinse, repeat. If you’re lucky, you’ll get to spend time presenting to customers/partners as well, which means even more time away from the code but is obviously worth it. “Evangelism” is necessary partly as part of your recruiting strategy – see above – but also so that when you do talk to people about deploying your code you don’t find yourself taking a torpedo in the side from some techie who’s either unfamiliar with your project or already inclined to use something else.
  • Write your own documentation. Developers hate writing documentation. They even hate reviewing documentation. However, if you’re running your own project you probably won’t have any trained and dedicated doc writers until very late in the game if ever, so you get to provide not only technical documentation but user documentation as well. No, a wiki doesn’t cut it, and neither does a FAQ on your website. If you’re really serious about letting your users figure things out for themselves instead of bugging you on mailing lists or IRC (which is even more time away from coding) then you’ll need to write not just technical documentation but end-user documentation as well. Writing man pages in nroff might seem like chipping flakes off a piece of flint, but you’ll still have to do it.
  • Deal with legal issues. If you’re lucky you can avoid patents, but – as I’ve found out – you can’t avoid trademarks. You might also deal with contributor agreements and such where your project relates to others, even if you eschew them on your own.

So now you’re spending 30% of your time on recruiting and evangelism, 25% of your time playing release engineer, 20% of your time doing all these other things. What do you do with the other 25% of your time that you actually get to spend on code? Probably more than half of that time will be spent on “peripheral” pieces of the code – selecting libraries and debugging their problems, writing config/argument parsers, running static code analysis (including memory-leak analysis) tools, or generally filling in wherever there are gaps. Maybe you’ll get to spend 10% of your time doing the things that you started the project to do. Maybe not.

I don’t mean to seem like a total downer. Even spending 10% of your time on the parts you really enjoy can be worth it if that allows you to prove a point or make the world a better place. It’s better than working on someone else’s dream (or merely lining their pockets) during the day, and getting to spend only tiny scraps of your “spare” time pursuing your own dream. I’m just trying to sound a note of caution here. Be aware that when you turn your tinkering into an actual project you lose a lot of control over both its direction and your own involvement. Personally I don’t subscribe to the open-source mantra that you should start inviting others to participate as soon as you have an idea. That’s great for the kibitzers, but it’s not so great for the players who might actually be better off keeping an idea to themselves for a while before giving up the chance to work on it the way they want to.

(Yes, I’m playing devil’s advocate a bit here. There’s enough “big happy family” rah-rah out there already. Average that with the deliberately negative view I present here, and you might end up somewhere near reality.)

How To Ruin a Project

This is a bit of a riff on Jerry Weinberg’s ten commandments of egoless programming (via the also-excellent Jeff Atwood). I’ve found that many engineers, perhaps even a majority, respond more to aversion than to encouragement, so a “how not to” that can be inverted in one’s head sometimes works better than a “how to” taken straight. So here are the ways to turn a promising and fun project into a soul-sucking wreck. Take it from an expert.

  • Miss the point. Never try to figure out what the project’s really about, or what it will be used for. Add features that have nothing to do with any valid use, removing or breaking other essential features in the process. Develop and test on a totally inappropriate platform. Confuse scalability with performance, or test the wrong kind of performance and then complain about the results.
  • Claim authority you haven’t earned. Assume that your reputation or barely-relevant experience entitles you to sit at the head of the table before you’ve made any significant contribution. Push aside those who started the project, who have contributed/invested more, or are more affected by its outcome.
  • Focus on the trivial. Spend all of your time – and everyone else’s – on issues like coding style, source-control processes, and mailing-list etiquette. Carefully avoid any task that involves a more than superficial knowledge of the code. Make others do the heavy lifting, then take half credit because you added some final polish.
  • Be self-important. Make sure everyone knows this is the least important of your many projects. Insist that every work flow and library choice conform with your habits on those other projects so that your life will be easier, even (especially) if it’s to the detriment of those doing more work.
  • Be dismissive. Clearly, your specialty is the one requiring the greatest technical prowess. If you’re a kernel/C programmer, look down your nose at web/Ruby punks. If you’re a web/Ruby programmer, look down your nose at enterprise/Java drones. If you’re an enterprise/Java programmer, look down your nose at kernel/C neanderthals. If you’re the world’s greatest maintenance programmer, specializing in minor tweaks to twenty-year-old programs representing many person-years of prior work , criticize the “immaturity” of new code that does new things. Above all, treat the specialty most crucial to your project as the exclusive domain of novices and children, with you as the “adult supervision” to bring it up to snuff in the areas that experts really care about.
  • Argue from authority, not facts. If anybody provides empirical evidence to support their choice of a technique, algorithm, or style choice, ignore or reject it. Never provide any such evidence to support your own choices. Make sure everyone knows that your own personal experience trumps any such evidence, even if that experience is less (or less relevant) than others’.
  • Lecture. Use every interaction as an opportunity to “educate” others about the reasons (rationalizations) for your personal preferences. Bonus points if you deliver a lecture on a subject that the recipient actually knows better than you, without ever pausing to determine whether that’s the case.
  • Be persistent. If any decision ever goes against you, resist it forever. Treat every bug from then on, no matter how unrelated or trivial, as an excuse to beat the dead horse some more. If you’re at a company, use company time to pursue your approach instead of the approved one, and drag colleagues with you. If you’re working on open source, threaten to leave/fork.
  • Be a hypocrite. Take some valid principle – portability, scalability, loose coupling – and use it to demand invasive change from others, then make your own changes that violate the same principle. Demand code reviews for every checkin, aggressively review others’ patches, then check in your own changes unilaterally. Bonus points if your unilateral changes were clearly never tested and cause grievous breakage.
  • Be the martyr. After all doing all of these other things, your colleagues might not be keen to work with you again. Make sure everyone knows you were just trying to help, that you tried ever so hard to make them better engineers, and that the lack of gratitude reflects on them instead of you.

Many thanks to the people I’ve worked with who have inspired this. Without you, the list would be much less comprehensive. I hope its inverse will help others participate in projects that are more successful and fulfilling for all involved as a result.