2

I work at a game company that has a Core Library with a bunch of ultities, extensions and systems that we typically import large chunks of into projects.

Recently we have been trying to improve our process of improving our library. Essentially we gave devs freedom to write tickets themselves that they thought were important to add to the core library. To tackle ticket prioritisation, we designed an ROI solution which basically has developers vote their impact(1-10 and effort(1-10) on tickets, and then we would sort tickets by ROI = impact/effort. Tickets were then sorted by ROI (high to low) and picked from the top. Essentially what happened was high impact tasks typically had high effort requirement, and super simple tasks with low impact had incredibly low effort (just 1 because majority of them were already done and just needed to be copied and pasted).

I personally didn't have much of a problem with this. It seemed natural. Tasks that took a second to do would probably be done first and then we would get to the bigger stuff. But devs are unhappy that extension methods that would be used once in a blue moon are making their way into the core first before a new important Save System that should be in all new projects.

Anyway, for now we are now just prioritising tickets based on impact and using time estimates on tickets to fill the sprints. People can also champion tickets they feel are important if they want and ignore metrics.

Does anyone know of any other solutions for solving this kind of problem? I'm kinda lost personally and I'm responsible for this task.

Cheers!

Sebastian King
  • 709
  • 5
  • 7
  • `ROI = impact/(10-effort)`? So if impact=10 and effort=1, ROI is 10/9 == 1.11, but if effort=9 ROI is 10/1 = 10? – Caleb Jun 22 '21 at 01:06

2 Answers2

2

Run it like an open source project, where people are encouraged to contribute code by a) writing it, and b) submitting pull requests to get it reviewed and possibly merged into the library. Come up with some guidelines for what's expected of submissions, like:

  • All pull requests should include appropriate unit tests.

  • Code should be adequately documented with doxygen-formatted comments.

  • The more general and useful your submission, the more likely that we'll accept it.

  • Changes in behavior will break other projects, so backward compatibility is extremely important.

...and so on. Figure out what you want your library to be and write guidelines to encourage that.

The goals should be to get everybody cooperating and contributing the things that they'd like to see in the library rather than waiting for you to add their favorite feature. Work to make it easy to contribute, but also to make the various parts of the library easy to discover and use.

Caleb
  • 38,959
  • 8
  • 94
  • 152
  • I really like this idea. How would you incentivise people to get their work done? One worry I have is people starting stuff but not completing it. The sprint sort of alleviates this as ppl have a due date for their work – Sebastian King Jun 22 '21 at 02:21
  • I'd expect the code library to be a byproduct of the work people are already doing. Imagine you're working on a game and you need a class to keep track of high scores... are you going to submit a request to add that to the Core Library so that eventually you can use it, or are you going to write the thing you need so that you can get on with the rest of the game, and then later think "my high score class is really good and generally useful, maybe I"ll share it"? Or, someone on another team might say "Hey, I liked your high score class... mind if I generalize it and add to Core Lib?" – Caleb Jun 22 '21 at 04:05
  • 1
    IOW, in most cases a piece of functionality should already exist before anyone thinks to put it in the library, so the work required to submit it is pretty minimal. Most successful open source products exist because the people who create them have a need themselves, so they write some code to meet that need, and then they decide to share that work and let others contribute improvements. – Caleb Jun 22 '21 at 04:13
  • 1
    "I'd expect the code library to be a byproduct of the work people are already doing". This is often how I thought about it as well. Totally agree. I suppose pushing members to commit to getting this work in a core state would be the next challenge – Sebastian King Jun 22 '21 at 05:09
1

TBH your solution sounds pretty good. I guess where it falls down is that its hard to rate the two things impacts and effort on the same scale.

If its a 1 day task to implement, your "extension method" for example, then I'm thinking "well you cant get lower effort than that surely? 1!" and maybe a weeks work is say a 3 and anything longer is a bit of an unknown, maybe a "That needs more than one team and I'm not sure how it would work" is automatically a 10

On Impact its even harder to judge, a "new save system" well the current system presumably works right? its not going to make the company a million bucks and it probably wouldn't change my day to day job (or pay) if it did. say 5

"shared helper lib that will save me typing"? "automated build system so I can deploy with one click" Impact 10!

"refactor code I wrote ages ago which works just fine you just have to know what you are doing god dam it!" Impact 1

An improvement might be to get the business analysts to rate the impact in dollars and the developers to rate the effort in days to program. But that will undermine the simplicity of the current system which is definitely an advantage

Ewan
  • 70,664
  • 5
  • 76
  • 161
  • What you've suggested is kind of where were going with our next sprint. Instead of devs measuring impact and effort, they're measuring impact and the time estimate for tickets THEY submitted. You are right in regards to impact being hard to judge - devs often disagree on impact votes (but I think it's quite accurate). I suppose because we have an improved version of a system in one project, some devs feel new projects should use this new improved version, even if the new features aren't even used for it. I myself don't even have a full grasp on how much better this new save system is... – Sebastian King Jun 24 '21 at 03:17
  • probably worth me noting that we work on many projects per year as well (upwards from 10 I think) – Sebastian King Jun 24 '21 at 03:19