Growing Culture

A pre-post edit: I am finishing writing this and editing with the events of Nov 3rd in mind, which were certainly a hugely negative approach to motivating our team that my interest is a bit shaken, or maybe I just have to be more cynical, or less?

The Center for Open Science is growing, and its culture is changing. It sometimes seems like a confusing jumble of all sorts of not quite conflicting interests, but order has been coming to our controlled chaos. In some ways it is awesome, in others it might just deaden things.

I write this as one of our developers is leaving us. He was the first developer hired by the center and laid quite a bit of the groundwork that we use day-to-day. He has his reasons for moving on, but it is still sad to see him go. His enthusiasm really solidified my interest in working for COS, it was serious development, as well as being a serious cause.

I started in February when we had about 30-ish full time staff and many fewer projects going on. There was quite a bit of nebulous thinking with some really nice features that were making the OSF much more of a usable product. There was quite a range of ways to do things, different ideas and lots of freedom to learn and do.

At the beginning of the summer we brought in 35+ interns, doubling our staff numbers and blowing away any possible workflow. Some interns were working on small projects and others were working on large “R&D” projects that may never get integrated into the OSF. Essentially chaos ensued that we are still trying to dig out from under.

We hired a Product Manager and she brought more Agile methods as well as Jira and other ideas. This is certainly still a work in progress but a better definition of how a feature or a fix gets defined, worked on, and merged is a huge improvement over the previous workflow.

Unfortunately with the recent experience and some burnout starting to rear its ugly head, especially with a negative motivation speech to seal the deal and thinly veiled diatribes against the method we certainly need a moment to collect ourselves and our thoughts.

There are two huge projects that are essentially due this month. The problem is with the approach to these projects that it was not managed in such a way that makes much sense.

• One project was given to an intern. Not that interns can’t do a good job, however, he can’t put in the time when it gets to the point where we need daily turnaround on code review response rather than weekly.
• This project is now up to 12k lines. By far the biggest chunk of code that has been “through” code review. Why wasn’t it put through in a more piecemeal manner as it was being written? Because it was an R&D project, and though it had people signing off on the proposal, no one was assigned to help the intern bring it up to speed until two weeks ago.
• Now they are trying to solve the crunch time by putting more devs on it. It may work, but really the fight was lost when it wasn’t converted from an R&D project earlier in the game with more code review done on top of that.
• Also the full time dev assigned is one of the three code reviewers, meaning that he hasn’t really been able to do code review for other smaller PRs coming through the system.

So I could go on about the negatives of how we aren’t experiencing management in a good way, but I think it is not malicious, just some line of communication was not very clear, and now we are rushing to meet a deadline that we have just learned about.

So my first suggestion is that if the R&D project is ever going to possibly be more than just a learning project then it needs to have definite code and functional milestones where code and functionality can be assessed and reviewed in order for the storm to be avoided when we find out just how close we are to a deadline, at least we will know exactly how the project is going.

We also need everybody doing code review. I know most people aren’t very good at it, but that is why we have more than one level of code review. But three people looking at code that nearly twelve of us produce means that they are always falling behind. Always playing catch-up.

If we have better incremental code reviews with better chunking of the tasks, then we get feedback on smaller bits of code that can be implemented for the next chunk. When 500+ lines of code are changed in a Pull Request, it starts getting troublesome for the more thorough code reviewer to trace down all the implications.

I was going to end this, before today, with an inspirational thought about how we all need to be one of a kind without breaking companies when we leave. But I would like to focus on the more practical. We have a much better, tighter approach than we had before, but we still have some major hurdles to overcome.