Day 29 The End Approaches!

The end of the month that is.  Then I won't be labelling these posts with numbers... I almost feel lost just thinking about that.  At least I've been able to keep this up in a reasonable manner.  Like many things, practise makes the entire process smoother.  I was going to say easier, but that isn't exactly correct.  Maybe it is right - my typing speed is increasing and my initial spelling mistakes are decreasing.  The hard part, as always, is the content.  I sound like some kind of beleaguered television executive.  I like the description of the writing process that a recently ex-co-worker described: "Staring at the blank page until the blood squeezes out of your forehead..." It went on from there, but honestly I forget the exact details.  I think it was a matter of letting the blood hit the page and tracing the outlines with your pen and then it was done.  I assumed that editing involved a different bodily fluid, but I decided I'd have to find out on a different day.  A day when I had a lighter lunch...

Had two parts to my day at work - the beginning, which was depressing and the second half which was collaborative and productive.  The team discussed some of the upcoming work for the closing phases of the current project.  The work that was left wasn't the depressing part - it was the amount of work we saw ahead to convincing other teams that they may be missing some pieces of the puzzle.  Not that any one team is way off track, but attitudes may result in more work for everyone down the road.  Since this is the finishing stages of a project, we are doing more and more about testing.  I think some teams haven't hit the balance between things that need to be done all the time (testing-wise) and the final big-push testing phase.  We seem to be missing cross-team, integration-style testing.  Each team has a testing environment, a testing framework  and so, a testing infrastructure that is much better than even a year ago.  Some people seem to think that this testing is great and that this final concentrated testing is redundant.  There is still room for more direct testing, testing that breaks silos and testing of areas that are not a person's speciality.

I found it pretty daunting to contemplate how to convince that more work needs to be done.  It's not something that people like to hear.  The effort is not in convincing people, but in how to create a palatable argument that will lead to modest improvements.  Someone pointed out to me later in the day that the upcoming new project is like a light at the end of the tunnel, the promise of new work, the shiny porch light to mothy employees... New stuff is always more interesting than the final details, so I could understand why some sound so distracted finishing.

The productive, collaborative part of the day, which was happily about half of it, was working on the new project.  Going into these early planning stages for the new project, I was hopeful that I would be able to have a say in the design or planning of what was upcoming.  The team I'm on has a specialization in the current project that won't be in the new project, so we are working on things that are entirely new for everyone on the team.  The encouraging part was that all the people I've talked to about the new project has been easy to ask questions of, given great answers and accepted ideas and opinions readily.  So far, it feels like a team should - not everyone agrees, but everyone listens and problems are solved through consensus.  The test of such an environment comes later when there are other pressures, sort of like starting a business.  You can't say you have a good business until you run into hard economic times for your area - if you can survive that, you have a good business.  I believe there is an old saying "gold tested in fire" which is the same idea.  Three teams came together over the past week and we have sketched out a design "framework".  

I hate to call it a design or even a plan - more like a back-of-the-envelope drawing.  From that, the work that needs to be done can be identified and sized.  Now an iterative design approach takes over, with prototyping and measurement being the basis of what comes next.  So I don't consider this a plan or design - more like an agreement on the rules.  Rules in a game provide a framework with which to operate inside of.  Too many rules and there is basically only one way of doing things.  That's a heavily, tightly, specified design.  The designers do all the work, the implementers do little more than data entry.  Such designs and processes are very brittle - if they work, they can be very very good, but any missing requirements or specification flaw can shatter the result.  I believe that the best designs place trust in the implementers to create something that meets the requirements ("the ends") without specifying how to do that ("the means").  A minimal framework is necessary to allow many people to work in common purpose, the balance being how much detail is necessary to keep people together.  This is something that depends entirely on the specific group. 

To use some Agile terminology, evaluating the people is important to tailor the process.  One of the pillars of the Agile Manifesto is "People over process".  I believe that too many read this as "people no process", where process becomes a bad word.  I think the proper reading is "processes work for people, not the other way around".  Good processes help people work more efficiently, bad processes are actions that are mandated but don't advance the project.  Taking this analogy further, the skills of the "people" dictate the processes.  The more skilled, self-motivated, adaptive the "people" are, the less there is to the process.  Many Agile descriptions end up like this because best people can take a one sentence directive and turn that into a productive working environment.  Not everyone can do that, so more words are necessary.  Or there may be many words to start with, but eventually the descriptions (processes) are reduced to simple phrases to remind everyone where they came from.  The design of software should also follow this model - the design depth will be dependent on the people doing the work.  It is a mirror of the Agile methodology.  In Agile, the result is the running of a project and this is done by the people.  For software, the result is the program which is created by the people.  In both cases, the processes that lead to the result are dependent on the people, with lighter processes being used by more capable groups.

Having written all that out, I think that's why I was so pleased with how things were working today.  The design that came out of the meeting was enough to base the next 6 months off of, but can be written on a single piece of paper.  I think everyone left the meeting feeling like something had been accomplished and agreed to, but it was simple and more of a guideline or framework than anything else.  The ease with which this was achieved was great.  I hope things continue in this manner for the rest of the project.  Hope is important.