Code Swapping

I was thinking about in the future how I might run a company with programmers being hired and leaving all the time. Probably because I've been watching Silicon Valley a lot recently.

So I though one method that might be good is that every programmer should only work on a piece of code for one week then swap and work on something else. While another programmer continues their work.

This way they would have to make readable modular code that can be used by anyone.

Instead if they worked on the same piece of code for years they might be the only ones who understand it.

Is there a name for this methodology? Can it work? And do you use something similar in your company? Or when someone leaves your company is it a nightmare because nobody understands their code?

Basically what is the best way to manage programmers?

 

There's been attempts with having programmers in pairs, but that actually turns out to be counter productive. Quite simply, your concern is not an issue if the code adheres to company house style - all code is the same format, the same rules and has the same documentation and commenting style.

That with peer review is more than sufficient to design out who is doing the code, for the majority of tasks. Some systems harder but these are problems for Unity scale companies on engines. For game developers, it's sufficient to just keep a consistent house style - this can also smooth out the difference in programmer skill for a lot of things.

But only if you enforce it. No exceptions.

 

In my industry we tend to do three or four reviews on code before it goes live. That's mainly because a bug can kill somebody.

Switching programmers mid project is a bad idea, and should be avoided if possible.

 

But I think reviewing code is all well and good. But that relies on you having to define certain practices. If you code swapped regularly wouldn't that force people organically to create better code through social pressure?

Doing 3 or 4 code reviews seems to be less efficient than writing it well the first time because you know that if you don't another colleague will call you out on it.

The bad side I can see is that job satisfaction might go down because people would feel less ownership of a project because (by design) they would easily be replaceable. Also, some very complicated algorithms might not be easily modularisable.

 

Have you seen the code people post to these forums?

 

I thought standards and peer review existed to solve the fact that never happens.

 

Not really. In reality it would simply force major refactoring every time someone picked up a new incomplete piece of code. Before code is finished, its easy to justify rewriting it to meet your own style.

 

My favourite thing about doing pair programming is not doing pair programming.

 

Maybe aspire to have a company where the programmers aren't leaving all the time? I mean, it's just really sad if your daydreams start out with "Yeah, someday I'm gonna run a terrible company that has a massive and horrifically expensive turnover problem!" If you're gonna daydream, at least raise the bar a bit and think about starting a company that will be awesome and cool and everybody loves working there, before reality comes crashing down.

--Eric

 

First, I think that relying on "social pressure" to get people to do their job properly is a symptomatic treatment at best. Are you genuinely concerned that your people won't care about the quality of their work without the threat of their co-workers' ire? If so I think you've got an attitude or culture issue within your team, and I'd look at solving that rather than forcing the issue by directly clashing people against one another.

That aside, I'm not seeing how that social pressure is any different to code reviews? Either way, someone else is going to be given your code and get encouraged to suggest improvements. In reality, if your programmers are decent and professional they'll quickly adapt to the team's guidelines, easily accept each others' styles within that, and focus on how to make stuff meet requirements in a maintainable method. If they can't do that then they're letting their ego get in the way of their job, which is no good for anyone.

I'm pretty sure that the way to avoid that is by getting the right people in your team in the first place. You want people who respect one another's work by default, rather than believing that they know the One True Way and that all others are inferior.

 

Perhaps this is the heart of the issue? One should not build business plans based on the overly dramatized for entertainment version of the business shown on TV.

When I was at uni I tutored a high school student that wanted to be a theoretical physicist because she could just sit and think and stare at a whiteboard all day.

 

It might also be worth pointing out that if you've got pieces of code that take significantly longer than a week to create then playing musical chairs with them is probably going to cut holes in your team's productivity.

Writing code is easy and fast. Deciding what to write is where things often get difficult and slow. You might have to learn about a new domain, pick up a new API, solve a previously unsolved problem, or lots of other things where the challenge does not come from the actual code.

And then, to make the code part better - the easiest, least valuable part - you're suggesting stopping someone who's part way through that stuff and making someone else start somewhat from the beginning?

One of the neat things about peer reviews is that not only is the code being reveiwed, but also the underlying solution can be interrogated. This could happen at code review time, but I would suggest having people review plans before they're implemented. This means that even if someone has spent some time learning about, experimenting and prototyping with a system, they're going to share enough of that knowledge to get a second opinion before they embark on coding it up. Now you've got at least two people with some level of familiarity, and you're likely to have a more robust approach because it had to be defended before it was implemented.

To be clear, the important part there isn't to not waste time writing code. Again, that bit's fairly easy. What's a pain is if someone goes and writes some poorly thought out stuff, and then someone builds on top of it, and then later on it needs improving but now there's a whole bunch of stuff that's dependent on it...

 

The show is actually fairly (and painfully) accurate. But it is important to note that the companies that are central to show are constantly doing everything wrong. That is the funny, watching incompetent businesses and people being incompetent. You are correct, there is no good knowledge to be gleaned there. A show based on company making good choices and doing thing right only to succeed... wouldn't be entertaining.

-------

Code reviews are good. Not doing them is dumb. Randomly defocusing engineers and moving them away from what they are good at or interested in, is a good way to not have good staff. The best way to utilize brilliant engineers is to not get in their way too much.

 

That is basically what they do! Especially if they are in the Institute of Advanced Study. Well that, and read a few papers.

However good your company is, programmers can leave for whatever reason. Maybe personal issues. Maybe having a baby. Whatever. So surely you should run your company in a way in which everyone is replaceable.

I've heard stories about programmers leaving companies half way through a project and then then manager trying to sue the programmer because no-one else could understand the code they wrote!

TBH. I doubt I'd ever want to be a manager of programmers. Since how would I know they hadn't accidentally put a decimal point in the wrong place and the entire software would fail on a certain date in the future?

Also, I've been watching this on YouTube where you can watch a CEO managing his programmers. Seems kind of frustrating.

 

How about you get a programmer before learning what to do when you lose them? I mean, you must have pretty major dreams going on here.

My concerns tend to be more about "how can I afford networking costs?"

 

Well, I like to dream.

Shouldn't the user pay for the networking costs in some way? Or the players can host the games on their own machines. Or... build your own server out of raspberry pis?

What networking costs do you have? Are you building the next Netflix?

 

So are you not going to have specialists? Are you really going to tell a dedicated graphics programmer to work on AI, and vice versa?

 

Don't know how to answer this.

 

You love making plans in advance don't you. It isn't enough to just lose your programmers. You had to have a plan to lose your audience too.

 

Just wondering what you need networking for? Are you making an online game?

 

Huh? What do you mean? You should build networking costs into your sales shouldn't you? Otherwise you're working at a loss. Unless your plan is to sell your company to Google at a later date. (e.g. YouTube). With cloud services you only need to pay for the networking you need.

Or did he mean networking as in going to parties and networking with people. As in drinks money? I thought he meant like networking code as in hosting a MMORG.

 

Don't know how to answer this either :/ why else would I need networking.

 

Yes. Your wording just left the impression you meant in addition to the sales.

 

To exfiltrate a person's contacts and data?

 

Gitflow is a really nice pattern to follow. You then have code reviews on all pull requests going to master branch

 

Sure. But with a good company, you get five to ten years between moves. Some employees will stay forty years. Natural turnover is pretty low. You are talking on the scale of weeks. If you are consistently loosing people after months or weeks, something is wrong with the company.

 

Nah, I don't mean someone will stay for a week and then leave. I mean they might stay for five years, give one weeks notice and then leave. Or maybe they walked under a bus. Or their visa expired and they were deported. Or they were thrown in jail for pirating DVDs. Lots of reasons.

I am ideologically opposed to notice periods longer than a week - if that. If people want to leave a job they should be able to leave - no questions asked.

 

You're opposed to giving yourself time to find a replacement? Keep in mind it's not just the employer that suffers. It's the employees who have to take up the slack until you can find a replacement. Quite frankly this thread has left me with the impression you're not a good employer to work for.

 

Typically notice periods are reciprocal. Both the employer and the employee need to give notice if the employment is to be terminated. So a one week notice period often also means the company can let an employee go with one weeks notice. In practice longer notice periods benefit both the employee and the employer.

And I'm telling you, this simply doesn't happen. Not on the scale you are talking about (unless the company is a horrible place to work for). I've been managing people for almost ten years now. In a team of a dozen people, you will get less then one leaving a year naturally. If your working environment is good, you are likely to loose more to internal restructuring then you will to attrition. Most people don't want to change jobs. Its expensive and disruptive.

You shouldn't implement horrible working conditions (your changing projects every week idea) just to deal with a once a year or less event.

 

You do realise that the contract stipulates baseline agreements, right? You can tell people that they need to give you 4 weeks but then actually let them go with less than that if it seems like the right thing to do at the time. The 4 weeks standard time in most contracts is a risk mitigation strategy for both sides - it makes sure that in long term planning you both know that if things go pear shaped there will be 4 weeks lead time to deal with it.

If one of your employees comes in one day and says "I've got this great opportunity, but it starts in 1 week or I miss out!" there's nothing forcing you to force them to stick around for the other three weeks. It's well within your joint power to mutually agree to a 1 week notice period and do that instead.

So you're thinking about permanently reducing everyone's productivity in preparation for rare cases that will impact a few peoples' productivity? The cost-benefit is way out of whack, there.

Also, consider that frustrating work practices and inefficient procedures are likely to increase workplace stress and decrease employee satisfaction. That means that they're more likely to look for other work, take sick days, lose motivation... So I think your concept here is likely to magnify the problem it's meant to help solve, as well as creating a bunch of new ones.

Honestly, there are existing strategies people use to help with this kind of thing. Yes, it's still painful when a valued team member leaves, but it shouldn't be the end of the world for the rest of the team if you're established and managing your team / business / project reasonably well in the first place.

 

In my experience, the notice time varies, typically a month for senior staff. It’s not a fixed contractual time, it is usually enough time to wrap up and hand off. A professional won’t leave an team in crappy spot (reputation carries with you, doing that can hurt you down the road). And the new employer understands that, and is fine with it as they know they can expect the same in the future. The places I have worked, it’s kind of expected that filling a position can take a few months, for searching, interviewing and transitioning from prior commitments.

 

Good job I'm not an employer then!

I was just thinking about if I was Richard Hendricks, running Pied Piper, how would I manage Gilfoyle and Dinesh so that if one of them left, it wouldn't cripple the company. Especially since Erlich has gone to Thailand. Who is actually reviewing Gilfoyle and Dinesh's code? I mean it's a bit different since they are partners not employees so less likely to leave.

 

Maybe this is more of an artistic problem, not sure how it works in the programming world,
but project ownership is a thing.
Preferably, you would like to give an employee enough leeway and time to feel ownership of the work produced, but within the structures or guidelines by the company.
Picking up a half done work and leave it half done, before it's realized, is only going to produce mediocre results.
While on the other hand if you feel a strong responsibility and ownership it might be something you devote extra hours on and problem solve while not working.

 

Trying to coordinate a team of unpaid people online, which is what I am faced with, will invariably result in these things. My strategy is to make the direction so clear, the next person, or even myself, can pick up and continue. Standards will make sure that each piece clicks with each other piece. Planning is useful here.

Realistically, you need to be such a fantastic boss that there are folks lining up around the block to work for you (not to mention understudies waiting in the wings for an opportunity to jump up to a senior position). If you have built something so flimsy that the loss of one employee cripples you, you deserve it.

No true scotsman... er, professional would ever do that. And yet it happens on occasion. In the corporate world it may not be common but in collaborations, people vanish all the time.

^^^^^^^^

 

Paying your workers is also useful.

 

When I finish my time machine, I'm going back to the past to manipulate events to ensure that I grow up solid middle class with a great education.

Until then I am faced with reality.

 

Or you could work on solo projects instead of not paying people.

 

Have you experienced a great deal of financial success this way?

 

Enough to actually pay people, yes.

 

A lot of times you'll also hire someone specifically for their specialty. There are a number of engineers in my company and nobody is allowed to touch the networking code other than me unless I first review it. Likewise, I'm not allowed to touch the webUI unless someone reviews my code. I'd never let someone touch anything I've written in assembly because very few people know how to write good assembly.

I think the best way to make sure code is modularized is to have one person write the code and another person write the unit tests for it. This produces airtight code. There's nothing harder to debug than an algorithm that you know works perfectly that's suddenly fed a NaN as a parameter and went haywire.

 

What games?

 

You don't seem to have experienced a great deal of success your way? Or am I missing something.

 

Probably quite a few things.

 

For what it's worth, I've had some success with the unpaid team route. The distinctions are:

• They weren't working for me, they were working with me.
• Everyone had clear non-financial goals they wanted to achieve that we could make sure to hit along the way.
• Everyone wanted to make games as an activity in and of itself, separately from any extrinsic rewards.

So people weren't getting money, but they were getting something, and enjoying what they were doing for its own sake. It wasn't "unpaid labour", it was a cool thing they enjoyed doing that they could do with other cool people, and achieve some personal goals along the way.

 

The other thing I've seen work with unpaid labor is groups that have some interest in each other outside of the game. Its easy to collaborate with friends or family. Its much harder to collaborate with random people on the internet.

Collaboration between established professionals also seems to work. In this case it tends to become a business arrangement. Crossy Road originally arose out of a collaboration between two experienced devs, and that went a long way.

But I've yet to hear of a single successful collaboration built as an early career project game by strangers on the internet. (I would be curious to be proven wrong on this).

 

After all the whole idea of being an indie is to eschew rigid working protocols and have fun while securing financial freedom. It should be fun. It shouldn't be a chore. If it is a chore, then it's just another job. In that case, I would recommend trade school. Or get into big contract construction. My point is, if it's all about the money, games are not where it is at.

 

Why not do it yourself and prove everyone wrong? I don't believe in impossible. Improbable I can accept, but only begrudgingly. If the lead developer of a major flagship title were to lose his mind and retire early, and take to the internet, do you think he could organize a dozen random internet people into building a moderately successful indie game?

Of course!

So if someone can do it, the real question is what am I doing wrong, or what am I failing to do? Am I even trying? Am I merely delusional and my efforts so far have been halfhearted and mediocre? Am I ignoring constructive criticism?

If it can be done by somebody, then there's a way. And if its possible I want to do it.

 

You sure are making a bunch of excuses to avoid paying people who need to do things like eat and pay rent too.

 

I tried a couple of online collaborations with strangers for games and failed. That was enough for me to move onto different ways to do the job. Now I only work with strangers if money changes hands.

I still do some collaborations around reviews my YouTube channels. But this falls more into @angrypenguin's category of clear non financial goals. I want good content for my community. I want the game developer to share my content with his community. He wants good content for his community. He wants me to share his game with my community. Everyone wins.

Collaborations where "We might make some money at some distant point in the future" tend to loose out to "Someone is going to pay me now".

 

You should.

I think this is overreaching.

And it just doesn't make practical sense when a basic understanding of economics is applied. If you could secure financial freedom while having fun then everyone would do it. That increases supply without increasing demand, in turn reducing the value of generated products or services to the point where it's no longer easy ("fun") to secure financial freedom through that avenue.

You contradict yourself. Not in a strict sense, it makes sense to want "financial freedom" without wanting to get rich. But in terms of core values, on one hand you list "securing financial freedom" as one third of "the whole idea" of indie teams, while on the other hand you're saying it's not about money.

So which is it?