what is wrong with our process?

 I won't pretend that I can answer that question.  But I think most of us can sense that there are serious problem areas that either have not been addressed or are being addressed but are still problematic with no clear resolution in sight.

 I'll begin with my iteration since its both what I'm "supposed" to be blogging about and is illustratively of the problems that I allude to.  My job was to get the latest activity page working.  Incidentally, I accomplished this, but that's an aside.*

 To do any meaningful work on the latest-activity page, you have to have a stack with deliverance, opencore, and wordpress.  Getting this up was my first task.  There were various pieces of instructions on how to do parts of these things, but there was no real unified set of instructions.  And to be honest, while what I should have done is to unify the instructions, this would have involved substantially rearranging the wiki and pulling various instructions off of various threads in the dev mailing list and would have taken hours of time.  The hypothetical you can point out that this doesn't absolve me (or anyone else, for that matter) responsibility of making things right where they are wrong.  But the fact of the matter is that while not only isn't this my responsibility (taking hours off my schedule to write some wiki pages and convince people to use them), its not anyone's responsibility in particular and we don't really have time nor are we encouraged to take time out of adding new features to improve infrastructure.  I'm going to label this [Problem 1] and talk about it later.  The other reason I didn't want to tackle making a unified set of instructions is not only is it difficult to get people to use them or update them, but we have so many different ways of doing things that I am afraid that instructions I would write would just be subject to controversy and endless discussion.  This is [Problem 2].

So since we have no build process that is really capable of doing what I needed, and since topp.build is deprecated, and since fassembler wasn't even sorta ready at the time,  my solution to reliably and repeatedly getting the software on my computer was writing a shell script that tied all the build process together.  This serves to me two purposes.  First and probably foremost, the script serves as a list of instructions that is written down.  I don't have a good memory for details that don't seem interesting to me.  Things like when in the build process to substitute my username and group for the defaults in base.ini aren't interesting.  I'd just assume fix it so that I don't need to do such things, but the build is kinda in a holding pattern and I certainly didn't want to include another change to the horrible deployment process (which robianski just now codified) causing irritation to others.  So I script around it.  Secondly, of course, my build script gets stuff onto my machine.  This is important because I made several changes that affected building the software, so I needed to test building, not just the built software.  Thirdly, scripting the build, even if its a stupid shell script, teaches me about the build process.  You would think that after working for N months on the build, I would know everything inside and out.  But this was primarily as a producer and not a consumer of the build.  This is [Problem 3].  Josh helped me figure out some parts of the deployment iron out....the deliverance setup, I think (shows how well my memory works)...he couldn't understand why I was writing a script and he and possibly Robianski seemed to philosophically object to such a thing** (even though it was clearly for my own usage).  This is [Problem 2] again.  The script helps me.  I wrote dev saying that writing such scripts might help other people (at least that was the intention behind my email [LINK?]) and was told that this methodology was wrong without being given an alternative that would work for me.  Remembering all the steps and doing them by hand is not an alternative I can live with.

It took most of the week to get the build to work. Now I have my script and its taught me a few things.  I tried briefly to turn it into a python script to have an improved and more extensible full stack build while waiting for a build or two to get done, but without major success.  Learned a few things. But decided that as much as I loved coding it, now that I had a working opencore + wordpress + deliverance on my machine, I should get on with it.  So first the tests.  Ran the unit tests.  Failures!  I spent a few hours trying to debug.  Paul fixed before I could really even find out what the problem was.  I'll admit I'm not the speediest test-fixer for code that isn't mine.  While it didn't cost me much time this round (you know, only half a day, as opposed to...2.5 days last iteration), this points to [Problem 4]: poor testing practices.

Thursday through Monday I actually got to code.  And by code I mean, move stuff around in svn, fix a view or two, and write some templates.  I hit up Rollie a few times to get some UI feedback about what I was doing.  I had mixed emotions about it then and still do now.  I mean, Rollie's a nice guy and very helpful, but am I really supposed to be coming to him for "do we have classes for this?" questions? I was given a wireframe and told "make things work this way".  My implementation does not perfectly conform to spec and since Rollie or Mouna haven't been able to see it, I have had no feedback or iterations with UI, I have to assume the wireframe is canonical. The actual parts of programming that I would consider appropriate to my position was probably....half a day?  The other parts are implementing various markup and doing little detailed fill-in of templates.  This is [Problem 5]. I'm not trying to be arrogant or say that such things are beneath me.  Its only to point out that my strength and in my opinion TOPP's best use of my time is to implement (and maybe design) architectures to make things easy to develop and extend and to do 'app-ish' features.  While I can and don't mind writing HTML, I don't consider it where the focus of my day should be.  To make a comparison, I enjoy interviewing prospective candidates as part of my job, I consider myself neither inclined nor qualified for Vanessa's position. I noticed tons of things in the opencore software that was in desperate (read: "I would have done this if there was time and considered it part of my iteration") need of refactoring, to make things more sane for everyone, designer and programmer alike.  But I ran out of time, not even being able to write proper tests.  [Problem 4] again and my contribution to the problem.  So instead of paying the dime to refactor, making things nice to template and easier going forward, I paid the penny and got my hackish version of the page into everyone's svn.

 The point of my story isn't to bitch about my problems nor to bitch about our process.  Its an attempt to tie together the little problems encountered in my development to larger issues that seem systematic.  Lets examine these issues:

Problems

(in order encountered in my iteration) 

[Problem 1]: There is no space to fix problems encountered in the course of daily work.  Okay, I'm probably almost as opposed as Cholmes to refactoring just to make code pretty.  But I am even more opposed to working around problems to save a penny in the short term only to accumulate work "interest" in the long term.  Our marching orders have been pretty much since day one, and at least since the Christmas iteration, that getting new features out to our customers is more important than infrastructure improvements.  I agree with this.  But at some point the price paid for not doing anything with infrastructure is that getting new features out grinds to a halt because it becomes painful to do anything.  We're not as bad here as things were in my previous position.  But we're by no means running a sustainable shop either.  We also pay lots of lipservice to "don't do this few hour/few day activity because your mission is doing something else" [Note:  very important.  I'm not singling anyone out with that paraphrase.  I've heard that from several people and have also said it myself].  But then we'll go and put time and effort into something completely off-topic (IMHO, anyway) that spreads ourselves even thinner. As another corollary, and expressing somewhat of the opposite notion, often when I've stated that something wasn't done and it was making my work difficult, I was told "fix it".  In other words, stop what I'm doing and start a task that in some cases has been larger in scope than my original iteration.  I'm tempted to take this literally and not say "yeah, but....i need to get things done".  I'm so confused.

[Problem 2]:  Diversity of methodologies and difficulty at making group decisions.  We have talented developers with a wide range of experience, personalities, and methodological preferences.  This is one of our greatest strengths.  It can also be a huge weakness when self-governance is lacking.  We all tend to do....whatever the **** we want.  While I certainly agree that this is better than any sort of micromanagement of process (which, incidentally, we've also been guilty of, but not nearly in the same degree.  the point is that they're not opposites), we need to find a way of developing some unification of things.  When, say, Joe Programmer is starting a new project, then yeah, Joe should be able to do whatever the **** he wants.  But when other people start to work on it, we need to unify.  Looking at opencore, the same thing is done N different ways, where N is the number of programmers.  I'm not really sure how to facilitate communication such to mitigate this, but I am sure that it needs to happen.*** Similarly, while we've talking (often in hushed voices) about the need to make group decisions and abide by them, our process is pretty poor.  At best, it consists of someone sending a proposal to a mailing list, a few +1s, pages of on topic discussion, pages of off topic discussion, if you're really lucky a recap of the decision, and then maybe someone taking action.  At the worst, it just doesn't happen.  So there is unification of effort, and building of consensus.  Individually, we are all very talented.  Yet somehow not only hasn't this translated to something greater than the sum of the parts (I won't say the word), but its actually much less than the sum of the parts.  We need to figure out why and fix it.

[Problem 3]: Development is not rotated properly.  We're often pigeonholed into developing whatever we've been working on for the past ${time}.  Lets look at the reasons for this.  It is easy for us, as developers.  We know the software, we know what needs to be done next....its comfortable.  Starting a new project is fun, but working on someone else's software, being the newb?  Not so much.  Its easy for management considerations.  Jeff is an expert at the build.  Putting someone else on the build will take man-hours to get them up to speed.  We need all the man-power we can get *right friggin now*!  Jeff needs to do something.  To summarize, its easy to do and saves time in the very short term.  Now lets look at why rotating developers is good.  The obvious advantage is that you get more eyes and minds on the problem.  Don't think I need to spell out more there.  Another advantage is that developers get to learn all the different software used, which is actually two advantages in one.  The first is that they become familiar with the various software out there.  The second is that they are exposed to a wider variety of patterns, code, etc than they would find in a single software application.  A more subtle advantage and one that I think that we have sorely missed is that when one is developing a piece of code for part of a system of applications as we have is that working on a single piece of code one tends to think of a problem in a particular way.  For instance, when I was the buildmaster, my perceived job was to get the piece of software ready to run on someone's machine.  But then when I started trying to build a full stack, I realized that my architecture was designed for me, the buildmaster, instead of for the person building the software.  This wasn't my intention and its not like I did anything horribly wrong.  I just wasn't using the build in the manner that other people were and the pain points that I saw were only a subset of the pain points that someone saw that didn't care about the build but just wanted to get the stuff on their machine.  The analogy goes to all of the software we write -- their written according to the programmer's perception of what needs to be done vs. the programmer sitting in front of the product and going "this is all wrong".  Using the build as an example, what should have happened is when so-and-so had problems with the build, then so-and-so should have worked with me (next iteration or whatever) and I should have been given so-and-so's job. This is a simplistic fix and not a methodology, but I hope you take away the value of what I'm saying.

[Problem 4]: Poor testing practices.  We sometimes describe ourselves as a TDD shop at interviews.  I hope I'm not out of line in saying that this is deceiving if not an outright lie.  There are many people here that care about tests, but somewhat like the problem at large, despite this we don't have very good testing practices, much less TDD.  We have many tests.  They take forever to run.  We must be doing *something* right then?  One of our problems is that we often don't test what we're pretending we're testing.  We often don't write test -- I know I'm very guilty there.  If I do something new-ish, I often don't know how to test it.  Especially actually test it.  Take the feedparser-based snippet.  I can't use the flunc tests because they're broken.  Also, it relies on wordpress.  If it were me telling me to write tests, I would probably reorganize flunc first and give it some love.  But that would be...an iteration? ::shrug:: damned if i know.  So that leaves the unit tests.  Like a lot of things in zope, its difficult to write a real unit test, and instead you have to pull in much of the framework.  We *could* work on this problem.  But we haven't.  Worse, the feedparser needs a feed uri to test.  I could just....choose one?  And hope for the best?  And make our unit tests now depend on internet access?  Wait, that seems horrible.  Wordpress might not be around, so can't use that one.  I could of course have written tests that test things I don't really care about, just to say I had tests.  But that's exactly what I'm arguing against here.  I realize that testing is just one item in infrastructure improvements, but running the tests before checking is not only the only form of development quality control we have, its actually one of the few pieces of formal process we have.

[Problem  5]: Intelligent allocation of developer resources. We are talented individuals, but somehow we can't get a website working.  I think this is largely due to the fact that we're not throwing problems at people's strengths.  Originally, we had specific features that we wanted, we discretized them, talked about a little who was doing what ("yeah, i'm pretty good at abstracting things with interfaces, and I know http and want to learn rss"), and went.  I'm not saying what we were doing then was the solution.  But it is certainly a stand-in for something that we are missing now.  I have no idea what people are working on and how it all fits together.  Like right now I am supposed to be part of some build committee that is doing....um, unspecified goals?  I guess "define what is wrong with the build and fix it". When people have brought up not knowing what people are working on before, the response was usually "just ask them".  While I didn't have a response to that at the time, I have come to realize the flaw in this argument.  For one, it involves everyone gathering status reports from everyone else, which is not only messy + inefficient but also isn't really everyone's job.  Ignoring  this bullet entirely, it misses what we really need, which is a "big board" (with apologizes to Dr. Strangelove) of what people are doing.  I don't necessarily mean a visual aide (though I wouldn't mind one...hell, I wouldn't mind designing one) but a way of observing our strategy.  What specific issues are people working on now?  How do these fit in with their iteration goals?  How do these fit in with the next deployment?  How do these fit in with what we're working on next month?  The point to having a battle plan isn't that its what you're going to do -- its that when everything goes to hell you have a place to start trying to get back to some sort of coherent strategy.  Our strategy changes constantly.  This by itself isn't wrong.  But we need to throw problems to people that fit in with an overall strategy; these people need to know enough of the strategy to make intelligent choices (and yes, its their responsibility to find this out, but its also everyone's various responsibilities to disseminate information in such a way that people can know this information -- what is happening when and what does it depend on?); and the problems should be appropriately allocated to people in a way that they are thrown to people's strengths.

I'm sure there are more than these, but that's what jumped out at me.  If I had solutions to these problems, I would not remain quiet.  Largely I don't, though diagnosing the problem and talking about it is generally a good first step towards a solution.  For some of them, I have given nudges into the right direction.  I think some of them are mostly a matter of will.  We just gotta do them.  We can't stay in *EMERGENCY MODE* forever (of course, see the one about building consensus and doing things as a group).  Others....we just need to keep talking until we do really know what we have to do.  Much like the rest of this so called life, software engineering is not a cuddly blanket.  It isn't always comfortable.  It isn't always easy.  You can't curl up in it all day and hope things will magically get better. But it can also be fun.

 </soapbox>

---- 

* If you do think that me finishing the latest activity page indicates some measure of success, consider a few things.  Firstly, there is ALWAYS more that can be done in software, and there is USUALLY more actually cool stuff that can be accomplished.  For the latest activity page, it is hacked together to do one thing with feeds and another with mailing lists and wiki pages.  Turning latest page activity and latest listen discussions to feeds (RSS, atom, i don't care) would not only be a worthwhile activity of its own right, but would also make the latest-activity page much conceptually nicer + simpler and would eliminate cruft.  Currently there is no place that (e.g.) Rollie can view the latest-activity page (to my knowledge anyway, I'd love to be wrong) because dev.openplans.org  doesn't have wordpress (or so it seems).  I could have gotten this up and maybe streamlined some of the build/deploy stuff that has been crampin' r stile for so long, or at least had a better understanding of the problem and documented the difficulties.  I could have devoted more time to testing, fixing, and cruft-removal, though while it doesn't affect the look+feel of this particular feature will hamper the addition of new features until we streamline things.  These can all be taken to be goals for future work, but my real point is the fact that while I did (and in other iterations did not) accomplish a "paper" goal, reality is more nuanced and success cannot be measured by whether a paper objective is achieved but how it is achieved and the ramifications of work on it.  I don't think we reflect as a group enough on these issues.

** Please don't be offended if I've interpreted your opinion wrong or misrepresented you in any fashion on this page.  I initially wanted to avoid references to other people's specific actions altogether, but have found this cumbersome, self-qualifying, and overly apologetic. 

***  Note that any dogmatic statements of problems are made for purposes of clarity and not intended to cast reality as black and white.  Of course, its not pragmatic to ensure that NO overlap is done in development, but it can be mitigated with communication.

**** This is just a substitute for some curse word.