OpenPlans Operations

¡Bienvenido a operaciones!

I’m going to take this opportunity to christen the operations blog with a little management blogging update. This blog is open as a window to the world on how we do stuff, but the general idea is that things that are more import to the day to day function of our work vs. that of our code would go here. The pointy head stuff seems to fit here.

Séñor Engineering Catching Up

We are in a bit of a transitional period and nick has been polling everyone as part of a year end wrap up. Yesterday afternoon, ian, rob, nick and I had a phone meeting to catch us off siters up on what was going on in the office and to talk a bit about where we are and where we are going.

Rob and Ian have been plugging away with many of you on fassembler. I’ve been pushing along some work started by rob on getting opencore to run on updated versions of the underlying frameworks that let’s us use repoze, an all egg wsgified zope.

First Ballots In

Nick gave us a preliminary idea of the types of info he had been getting from folks and it was nice to hear everyone felt pretty positive in general. Some items that struck me::

1. we need to improve our testing situation in opencore to really do good (enjoyable) TDD.

   I think there are alot of ways to improve here and I’ve been thinking about it alot since the last week has mainly consisted of running the opencore tests over and over.

   Some general thoughts:

   • The slowness is in opencore, then plone, then zope. Most of the time is lost in the setup of the OpencoreContent layer.
   • For initial development (the part where you really need speed so you can try and throw away lots of stuff quickly), we need some basic assurance coverage that runs quickly.
   • Most of our tests that give basic assurance live in OpencoreContent or plone dependent layers.

   Separation is king. An interesting though experiment is if we had taken the time up front to make stubs and mock objects and enforce separation, would we have saved the time back already in test runs? As a person who suffers though tests runs alot, I feel like I personally would have.
   

2. Our architecture feels more complicated than complex or simple.
   
   We’ve embraced a common difficult sysad problem (how does one manage heterogeneous interelated servers) as an architectural plan. This doesn’t change the fact that it’s a difficult problem, and the freedom it gives us can be a bit overwhelming since we are not all bickingesque webapp ninjas yet.

   There is a meta problem here of making the heterogeneous feel more homogeneous to us as developers. Without diverging too far into yakshaving, thinking about how one makes software in this situation play nice with each other and our fellow developers is an important goal, since it is the feeling of complication and confusion that slows us down on deliver userfacing changes.

   We also need to do some knowledge sharing to flex our abilities to navigate the heterogneous environment we currently have as to enable all of us to make it better. We have alot of cool software, but most of us at best only partial knowledge holders which makes it hard for us to be agile and make the most of it.

   We also need to concentrate on simplifying and minimizing certain area (I’m looking at you zope).
   

3. We need more communication and education
   
   Always right? It sort of dovetails with the previous point. This I believe is both in a horizontal and vertical fashion. The flow information is the main thing here. Those of us in the position of senior engineering need to be a little better at delineating what is a recommendation of senior engineering vs. what is us hashing out our opinions to keep the top to bottom flow smooth. All of us need to be aware of boundaries and trying to keep information flowing in a efficient and productive way.

   We should actively try to work together. Now I know this sounds sort of simplistically dumb, but what I mean is that we should make sure that we are not becoming a personal silo, either by pairing, doing code reviews *together*, picking up the phone, scheduling a little time to talk, etc. Get the mild meld going so we can keep the communication overhead minimal.

   In this vein, senior engineering and nick are going to meeting once a week to sync up and figure out what the most important things going on are, particularily in reference to #4.

   Also, I think it would be cool to spend a little time for each of us to explore parts of our code we are unfamiliar with and record the experience. Sort of little howto’s, contributions to the documentation of our project, maybe cleaning up a little corner or two. Nothing big, just some small poking around and shouting about it.

4. We need to get the user more in our face
   This was more from Rob and Ian than from nick’s conversation but it really hit home. We tend to float away from our real users and our real users have real problem that we are not solving. We talked a bunch about this and the important effect of making the work real. When a real user says something is wrong to you, the impact is way greater than getting the info second hand and the relavence of our work is validated.

   This is an awesome feedback loop that we should do more to foster.

Coming Up

Coming down the pike, we talked about the following in the short, mid and longer term. I’m going to hit them lightly and more info will be forthcoming (and if I’ve forgotten anything, will try to get it up).

1. Beating down the user issues. TransAlt has some feedback and has waned a bit on referring folks to nycsr. We need to get this situation fixed.
2. Getting fassembler to full speed (almost there!)
3. Launching mapping
   
4. Implementing the findings of the user testing.
5. StreetsWiki III. January 15th coming to an openplans instance near you. I’m going to start on the super simple pieces today and will be pinging folks for help soon.
   
6. VHosting and the deliverated future. A little further out but starting soon, but this is a hot ticket for Mark’s vision of our software.
7. Events: Not the programming pattern, but those things people attend with other people for a wide variety of cavorting, conspiring, etc. Even further out: nick is gathering the user stories so we can start thinking about what events would look like in openplans.
   

And to all a good [morning]

Some of you I probably won’t talk to till the new year so may flying unicorns bring a sleigh of good cheer to you and yours in this multi denominational season of celebration! I’m out friday - wednesday, ian is out thursday - thursday, and rob is gone next week.

-w