It's been...

... a wide spectrum of experiences. I didn't want to just say "fun" because it hasn't always been fun. But then again, it is work, so fun is an added bonus. The company I have been with for the last 8 years (plus a few more as a co-op student) is closing down. I've been trying to think of some words of wisdom, summaries, histories etc. but I don't think the time is right for that just yet. Instead, I found something in this article that nicely illustrated what I enjoyed about "the old days" at work.

The article is an ACM Queue interview with one of the original designers of the ARM chip, Steve Furber. During a description about why the original ARM chip was so small, power efficient and cheap, Mr. Furber commented that:

This is good management retrospective: by depriving us of resources of any sort, they forced us to make decisions in favor of simplicity. -- Steve Furber

There were many parallels to BBC Micro and my old company - both were small, had limited resources and was an outside player in a potentially large market. In those earlier days, trying to do the impossible seemed like the only way to survive, so we went for it. They were exciting times and it worked - for a while. The later down hill slide is where my old organization and BBC Micro differed. I believe the small size and lack of resources resulted in steps forward that could not be duplicated by the company we became.

Whoa

Guess I should use my computer at home more.  Or at least some kind of better mobile blogging software 'cause I haven't written anything for 5 days!  That's pretty horrible given how I was doing before...  I just haven't been up to using the computer for the past few days.  At home at least.  It's been pretty busy at work, what with meetings and just so much stuff to do.  That is a good thing, but sometimes it leaves one tired and out-blogged.

One of the things I've been involved in is around our branching/release strategy.  It's funny because we've had this conversation too often as far as I'm concerned.  In the meeting we had to discuss it, we talked about the same old set of arguments about the basic different ideas.  It took a few days, but I think I hit why that was.  We were not establishing the correct base questions - we didn't know what all the root issues were, so we argued over the proposed solutions.  Also the arguments also revolved around the benefits of the proposals, not the drawbacks.  I wrote up my ideas, but the analysis of the problem hasn't been done yet.  That's probably something for tomorrow, but I think it is absolutely necessary.  Otherwise we'll end up with the camps of "this is newer/better - let's do this" and the "this works, why mess with it?"  Of course neither camp is that extreme, but hey analogies aren't fun if you don't push them a bit.

Anyway, I'm going to construct an analysis of the proposed solutions and identify if they can each meet the requirements and then see which one does the least harm.  Maybe show which provides the best benefits with the least effort - both good criteria.  I've been saying for a while now that the best way to evaluate a process - because that's what these solutions will be - is to pick the one that makes it hardest to wrong thing and easiest to do the right thing.

That is kind of tricky in the software business because you can change so many parts at once.  For software processes, it's important to pick the process/tools that make it hard to do the wrong thing and then make your process fit the process implied by the tools.

You may have noticed something controversial a few paragraphs back as well - that we were picking a process.  It doesn't seem like it because the choices revolve around different tools, but each tool implies a different process.  Picking a process implies picking the tool to use.

Wow - I'm writing this in a very abstract way.  I hope it's clear to other people what I'm trying to say... It's all that math training over the years - I tend to remove the parts that are irrelevant to an argument and replace them with variables or generics (when writing).  The more involved the process or tools the more abstract the references become so we end up with this gobbledy-gook.  Whatever - I wrote up something interesting to me and that's why I'm doing this.  You can read for your own reasons.  Individuality springs up everywhere.

Another work day

Busy day today - workin' away at stuff that wasn't scheduled, but necessary.  Gotta get that stuff done so that the new work can be done.  Made it to the gym.  Again.  Twice this week - that's pretty good for me, at least lately.  Hopefully I can keep it up 'cause I really needed it.  Before I went on Tuesday I had a weird ache in my elbow and an arm workout cleared that up.  Guess I needed some good arm stretching to work things out.  Got hockey tomorrow so we'll see how things hold up.  Maybe I won't be quite so winded, but I suppose that also means I need to get the heck to bed.

My eldest son seems to be enjoying Rock Band quite a bit.  He appears to be getting better at the guitar at a rapid pace.  Not surprising really, given his age.  After a week of regular play he is vastly improved.  He tried moving up a difficulty level and had some moderate success, so hopefully he will try some more.  He probably doesn't see that if he spends three or four days working at the harder level he'll achieve the same success he has now at the easy level.  That remains to be seen.  Anyhoo, I must go and sleep now so I will be ready for hockey tomorrow.

Nice day outside, but I gotta get better at this meeting thing...

It was a very fine day out there, beyond the computer room and the car window.  Positively warm at times!  Got one son outside running around for a bit anyway - lots of the kids on the street congregating and running around.  A good thing.

Work was weird today - two of our six team members left for another team.  Personnel changes always make things different, although it isn't a problem, just different.  It will be weirder when the four of us move in with the three others to form a larger team.  What I really learned today at work was that I have to plan out meetings much better than I have been.

I organized a meeting earlier in the week because we have three different teams collaborating on a set of features.  We have had meetings on and off over the last couple of months, just to get things off the ground.  We still have 2 deliverables between now and the project this collaboration is for.  One of the participating teams has been able to spare a person to work ahead, which is a great way to take advantage of these weird times between projects.  I wanted to have a meeting to go over our coding standards and talk about some patterns I'd seen in code reviews.  I booked an hour and said the meeting was about coding standards, but I knew that we probably wouldn't fill the time with just coding standard talk.  We spent the first half talking about coding standards and then the rest talking about the work being done and what we should keep a look out for.  I left pleased that we were able to discuss all the concerns I had going in, plus we were able to talk about planning future work as well.  What I found out today was that some, but not all, the other attendees disagreed.  One person in particular left feeling like something unspecified was imposed and that work that was entirely premature was being demanded.  

This happened because of a break down in meeting structure.  A good meeting would start with an agenda established ahead of time, a facilitator keeping everyone to the agenda and time reserved at the end to make sure everyone is agreeing to the same things.  Specifically, the meeting had a single item on the agenda and it was vague.  Deep and unrelated topics were raised during the meeting.  No summary was proposed at the end.  To resolve this issue, I talked individually with a few participants to find out what they took away and to tell them what I took away.  This worked well - we all wanted the same things, so it was easy to get agreement with a little clarification.  I also learned some important information that completed changed my opinions about planning for the project - pieces of information that were known before the meeting by half the attendees.

Next time, I will create a more specific agenda, save time at the end to tell everyone what happened, and make sure to ask everyone about any project news at the beginning.  That should save at least a half-hour for each person and keep things moving smoothly.

Related?

Apparently, I'm distantly related to Barak Obama.  Like so many others on Facebook.  Guess I should look into that...

An interesting day work, in that two long-standing members of our team are moving on.  To another team within the company, but things will not be the same.  Plans were to merge our team of 4 with 3 others in a nicer part of the office, but so far we haven't been able to schedule the move.  So far our new team wouldn't be that different as we would be working on distinct pieces of work, but that will change - hopefully.  At the very least, we'll all sit together and that will help our manager.

Found out my kids had fun at school, what with all the pranks being pulled!  My youngest (in JK) found his teacher's chair was stolen!  By the other kindergarten class.  My oldest (in grade 3) discovered all the kids chairs removed from their room with the culprit leaving a message in mirror-writing on the blackboard.  More fun than I remember having on April Fool's day!  I think they enjoyed it.

Friday - it's not my fault.

Just a little joke from today - a new theme song for our group at work I guess.  Re-did the lyrics to "Friday I'm In Love" by the Cure to show how a bug is not because of our team.  The things you have to do to stay sane...  But it is the end of the week again and that's a good thing.  Did a lot of typing today at work which is why I can type this on autopilot tonight.  Nice and smooth flowing output - don't think, just move those crazy fingers.  So very tired.  Pretty productive at work, what with all the typing and all.  Just to be clear, typing means I wasn't doing software development.  Software is not written with much typing - everything is autocompleted or copied or referenced or whatever.  You spend more time staring at the screen then creating code.  At least if you're careful you do.  I've seen some people that code as fast I type these blog posts and the reason they are so fast is because the end up doing the same thing many times.  They tend to throw out and redo whenever there is a bug.

Hockey was pretty good today - I think I got a goal, but I don't remember.  I do remember making some nice passes that ended up as goals and that is probably more important.  One of the benefits of shooting all the time is that defenders assume you'll always shoot.  Problem for me is that I spend so much time lulling them into a false sense of security that I don't get enough practice passing through traffic.  

There's been some talk around the house about getting some inline skates, especially since my wife is liking her figure skating lessons.  I think she's going to continue her lessons over the summer, but inline skates would be something we could get the whole family doing together and that is a rare and special thing.  Getting outside is important and we definitely don't do that very well as a family.  I think it will be a good investment.

Week end approacheth

The end of the week is rapidly approaching.  "Rapid" is more a perspective thing, but whatever - I think it's headed this way quick - so there!  It's not moving at breakneck speed yet, but whatever.  I did read on Slashdot that Mythbusters is trying to test the phrase "knocked his socks off" by using a dummy, socks and 500 lbs of ammonium nitrate.  Let's say the townspeople didn't expect the Spanish Inquisition, er, window-shattering kaboom.  No word on the state of the socks, but maybe they'll do "breakneck speed" next.

Got pulled into a call with lots of far-flung people at work today.  I think the call was pretty productive, considering the diverse group - offices from all over North America, representing parts of the product with potential conflicting requirements.  I felt like I was able to productively contribute a few times - clarifying instead of fogging issues.  It's nice to leave a meeting and have the feeling that everyone shares the same perspective on things.  Never lasts long, but it's nice and it is productive.  I'm optimistic about the upcoming project this meeting was related too - the different parts of the company will be united with a common set of tools and, hopefully, common procedures for using those tools.  Breaking the isolation of each part of the final product will lead to a better result and I think everyone believes that.  Well, the people at the higher levels do and that's good enough for now.

After I got home I took my son over to his friend's house to play after dinner.  He's visited this friend more frequently since the boy's father passed away.  I really can't imagine how they are doing, but they seem okay at this point.  I have a feeling they'll be playing together more often.  Plus they had a good time - pointless running followed by Super Smash Brothers Brawl - very nice.

Code and stuff

This is post 191 - a nice 3-digit prime.  Don't really have enough posts to stretch the checking necessary - 191^(1/2) == 13.82... That means I'll have to wait until post 289 until the next prime past 13 needs to be checked.  Anyway, I spent the day working with code - something that hasn't happened in a while.  Always seems like a shock, but there you go.  People still don't believe me when I say that more time is spent debugging and testing than writing code.  Or designing code.  Or whatever with code.  Some stuff to look at though - something applicable even outside the small domain of our business - a thread pool.  I didn't find the bug, I didn't come up with the fix, I just applied the fix to the correct branch and added some comments.

Frankly, I'd like to be able to add some more tests before going forward, but I definitely didn't have the time now.  I know this sounds like an excuse - we are approaching a release - but there has to be balance between what should be done and what I'm being paid to get done.  In this case, the situation called for a targeted fix, so I relied on existing unit tests to verify the change.  Ideally, I'd like to spend more time checking the unit tests to make sure that items weren't missed, but that wasn't practical.  Next week is a different story however...

What's worse is that this issue is related to a low-frequency, high-impact bug that our team hasn't isolated yet.  I think that next week I'll try looking for it by writing more unit tests.  I have a feeling that may be the most reliable reproduce scenario - one that I create out of thin air.

Discovered something else near the end of the day, related to something I've seen often - improper shutdown/exit of software leads to problems.  This is an issue in embedded development, where restarting a problem subsystem is a good uptime strategy.  The Qnx operating system uses this philosophy, where the microkernel never goes down, but the real work is done by processes that can be restarted as appropriate.  Since everything, including device drivers, are "processes", a device driver upgrade consists of putting the software in the right place and "restarting" the driver.  Being able to shutdown and restart a small piece of functionality is akin to modular programming.  Unfortunately this modular, restartable philosophy was not something hammered home at the beginning of this project, so this issue keeps recurring.  I also think that being able to stop and restart a module without side effects demonstrates good modularization qualities - particularly isolation.  It means that the writer and designer of the piece of software has considered its interactions and resource requirements and they are well identified within the code.  Losing sight of these things means that module can be shutdown, but not restarted.  

Well, I guess that is something I'm going to have to talk-up at work.

Maven thoughts, then patterns thoughts

I'm still plodding away at Maven at work.  There was some discussion as to naming patterns, conventions, directory structure etc.  Most of these things weren't ground-breaking, just items that require agreement.  Without agreement, some benefits are lost.  The only point I wanted to see was that modules and Java packages corresponded.  Everyone in my group agreed with that idea, so I went to voice my concern with one of the main drivers behind the Maven efforts.  He said essentially the same thing, but pointed out an exception.  Imagine an interface is described in module I, with two concrete implementations in module A and module B.  If module I uses a factory, it must have special access to module A and module B.  Specifically, module A and module B should be non-public, package protected perhaps.  This leads to having the interface, factory and implementations in one Java package even though logically they three separate pieces.  I wasn't 100% comfortable with the example, but I couldn't identify any flaws in the reasoning.  Then I hit on why I didn't like it - I don't think I like factory classes.

I've used factory classes a few times in the recent past, but they aren't something I agree with as much.  They are hard to test and the classes that use factory are also hard to test.  I think I would prefer each of the modules be a separate Java package with a single public entry point in module A and module B.  The user would be able to determine which implementation to use, instead of putting all that logic in the factory class.  However, either implementation would work and are equally correct.  It also illustrated the point that the name conventions and layouts are guidelines, not rules.  The exceptions occur frequently enough that slavish adherence to particular rules will cause more problems than necessary.  Rather the rules are there to help remind people to really consider why they are using complex constructs.

This brings me to some thoughts on patterns.  The Abstract Factory pattern was mentioned above and my desire to avoid using it comes from a certain unease with ideas of software patterns.  I've previously had discussions with a co-worker who expressed the idea that there is something wrong with patterns, but he couldn't put his finger on it.  I suggested that it was because the patterns don't solve all problems (otherwise software development could have been fully automated by now) and the pattern requires adjustment all the time.  It seems like the problems are fit to the patterns, rather than using patterns to solve problems.  I think that patterns have been used by those that want to turn software development into more of an engineering discipline with common issues that simply need to be recognized and well-known (well-described?) solutions applied.  I agreed that these were my ideas on the topic, but didn't do the unease any justice.  My co-worker has been reading Christopher Alexander's book on pattern language, as Alexander is the source of the ideas adapted to software development.

I suppose the real issues come from those who apply the software design patterns too easily, without first considering the problem.  As time has gone on, I've been adding criteria and considerations to things I need to design.  Things like ease of understanding the result, simplicity of implementation, testability, current requirements.    Also, with the various patterns I've been involved in, they've been customized and adjusted in ways that suggest one of two things (or both): 1) pattern didn't fit and the problem is being adjusted to suit the pattern and 2) so many adjustments are made so that the pattern is only partially there.

Anyway, this is not a well-reasoned argument - it's barely written down at all!  Hopefully I will be able to devote some more thought and then more time to describing some of these things more coherently.  Not tonight though.

Build tools

I referred to the Maven change at my work the other day, but I didn't take the time to describe some of the basic principals that I was using.  These principals generate questions rather than exclude or include things.  As I mentioned in this post, any build tool can be configured to support your environment.  Using that logic, why would anyone move beyond shell scripts and batch files?  That's the first item in the philosophy:

1.  Can this project use the build tool in the way it was designed?

For make, this means try to use only the implicit rules and organize your pieces so that all the interdependent files are within the same directory.  For maven, this means organizing your project in a modular fashion where each of the configuration files describe only the dependencies between the modules.  When you move out of the comfort zone for the tool, you increase the likelihood of mistakes, or design cul-de-sacs.  Every design has certain features that shape it, and those features exclude other items or make them difficult to achieve.  Using Maven to build a project developed entirely in C raises a flag.

2. Can the build tool handle the corner case you know about now?

Pretty simple thing to remember - if the tool can't handle all your current requirements, how will you deal with the unexpected?

3. Can the tool be setup to run correctly from a sandbox?

By sandbox I mean can the tool be useful without referring to non-local items.  I understand that one of the features of Maven is that it can keep various libraries up-to-date by retrieving the latest version.  By "retrieve" it means connect via HTTP, I believe.  I've been informed that this behaviour can be disabled, which would be a plus in my view.  When building a particular project, it is preferable to be able to identify, before the build, the files that will be included.  That doesn't really provide any more or less protection from error, but it makes the process more repeatable and leads to the next point.

4. Can the tool be setup to run correctly from a source control?

Imagine you have a project in a source control system and you connect with a new machine.  Can  you do a single check, run the build tool and generate the proper output?  This is something that I value highly.  It speaks to repeatability and how fast you can get new project members up to speed.  It also means that as long as you have project source, you can build it.  Someone I knew at university was doing his PhD, but he said that he could no longer print or display his Master's thesis.  He wrote it in PostScript or LaTeX dialect and could no longer find the pieces the render the source as it appeared in the hard copy.  Many companies and individuals rely on open source tools.  If they do not keep the tools along with the project, they risk not being able to build the project from source in the future.  

5. Can developers operate effectively without modifying the configuration files?

One of the problems I've seen in various workplaces is build configuration differences.  If the build configuration files have to be checked out of source control and modified to build correctly, that is a large potential problem.  Ideally, build configurations would not need to be altered unless files are added or removed - even some tolerance of those changes would be good.  If these files have to be checked out, different groups produce slightly different builds, which leads to errors arising from these small changes.  These errors are very hard to track down and can be avoided with proper tool selection.

To summarize - the idea is that doing the right thing is easy and the wrong thing (unexpected things) is hard.  It should be easy to identify where everything came from and how something was built.  These things may take a large amount of configuration - a ramp up time learning how to use a tool properly.  As for Maven, so far I think it's right for what we are doing at work - but there are caveats.  The main one being the potential for cross-module changes, of which I know of one current example at work.  Items that touch many modules can be refactored by adding more indirection (or abstraction), but this has it's own cost.  Oh well - such complexity is what makes things difficult and what keeps me employed.  I just want to make sure that I don't forget the potential problem areas in the future.

A Friday at work

Post 177 - not prime, but at least the product of two primes: 59 and 3.  Had a pretty good at work, especially at lunch hour.  The last Friday of every month some people bring in their Rock Band and have at it over lunch - but must be done by 1pm.  Anyway, it's a pretty good time - there are quite a few people that are really good with the various instruments, especially a couple of incredible drummers.  Always impressive.

More interesting was the initial reports of some investigations into using Maven.  Maven is a development tool, used to compile/package and generally create a piece of software.  Other similar tools are "make" and "ant", with ant being more closely related.  Currently we use ant to manage our builds, but there will be a move to maven for the next release.  Given some of the problems encountered testing it out, I wanted to find out what has been motivating the move.  Especially when I found out how easy it was to retrieve libraries from Internet sources.  For an open source project, this is a tremendous feature, but for a proprietary embedded system, I'd be more comfortable with a rigidly contained system.  By that I mean one that will not attempt to search for data beyond a specified file system area.  So I went to talk to the person who has been working on this initiative for the longest and he had all the "goods", so to speak.

The reason for the move had two main motivations - the first being the default mode that Maven operates in.  Maven expects projects to be structured as a series of modules.  This encourages projects which have lots of pieces with well defined boundaries.  This is something that our company wants to promote internally, so Maven promotes it by making it the simplest choice.  Maven's strength comes in the way it describes dependencies between modules, with the simplest configurations being when most configuration files only contain the dependencies.  The second motivator was that modules can describe a dependency on an old version, so development could continue in place without breaking other modules.

After my conversation, I was pretty happy with the discussion.  The tool doesn't eliminate problems, but steps will be taken to minimize the likelihood of certain problems.  I wanted to convince myself that we won't be walking into a new set of pitfalls without enough forethought.  I believe if certain configurations are used, the future project will have fewer potential problems.

Ah well, I guess that's a first cut at that discussion.  My brain is tired and trying to get me to sleep, so it won't let me continue heavy thinking.  Tomorrow then...

Communication

It's review time at work.  That usually means it's time to try and figure out what happened in the past year and how to phrase it just - communicate what makes yourself stand out.  Hopefully you stand above.  Now review time means all the rehashing and debating is done and the explaining begins.  I sense that most of the managers dread this time of year, but I don't think they should be too worried.  I think they're worried about all the questions that arise from the reviews, but it's pretty much what it is and I don't think there will be too many questions about how - more about what comes next.  One of the things mentioned by my manager was that I have to improve my communication.

It's interesting that I decided to do some writing every day to improve my communication skills and that it's something to work on.  I think the idea was that I'm not a bad communicator now, but I could be so much better.  Potential and all that rot.  So I endeavor to be a more nuanced communicator.

Which brings me to this post over at Kimota94's Place.  I find it petty that someone would expunge all comments by a particular person.  I suppose in the blog system the comment removal would be hidden from the wider audience, so once the decision is made to decline comments from a particular source, it can be accomplished in secret.  The thing is, if someone disagrees or displeases you that much, it shows more character to leave the comments there.  It's one thing if someone is being belligerent, but in general the comments speak for themselves.  If the comment is that contrary or disagreeable, it should be evident to everyone.  Then such irritation reflects back on the poster rather than the blogger.

Sentences make sense not.  Sleep must obtain.  Cease communication.

No hockey!?!

Just found out that hockey for tomorrow is cancelled due to rink troubles.  Both pads are having trouble with the chillers apparently.  Which sucks because we had enough people committed to have a few people sitting on each bench!  Wow!  That hasn't happened for some time.  I hope people get the email before the head out tomorrow.  Maybe I ought to get to the gym instead then - my paunch is getting unruly.  I need to drop a bunch of weight and I haven't been controlling my eating the way I should.  Which is to act like some kind of adult and demonstrate some restraint.  Crazy I know, but there it is.  Actually doing physical activity helps out, but whatever.

Did a little research into RMI and IxC at work today.  Don't really get a chance to explore new stuff there, but this important for our upcoming projects.  RMI is "Remote Method Invocation", a system to run code in a "remote" Java Virtual Machine (JVM).  Depending on the environment, the word "remote" can mean different things.  It could represent a distant machine on the Internet or an app running in a logically separate sandbox (or context).  IxC is "InterXlet Communication", and is part of some of the mobile Java profiles (J2ME, PBP, CLDC and lots of other acronyms).  You can look at JSR-217, which is Personal Basis Profile (PBP) 1.1, looking for the package javax.microedition.xlet.ixc.  What I've discovered so far is that IxC removes the generic portion of RMI by eliminating the registry and replacing with the IxcRegistry.  Not really very much, but we spent a bunch of time trying to work out if it was possible to replace RMI registry with something of our own devising.  So far, we have to say "no" if the objects to be exported were written to use IxC.  

Before you get all huffy and add comments to illuminate my idiocy, the code in question has two parts - simple calls and callback registration.  The first part can be done without much difficulty, but callbacks are tricky.  The callbacks originate in the object to be exported.  Let's say there are two app contexts, A and B.  Class Foo is registered in context A and sometime later app Woogle in context B uses RMI to get a reference to Foo.  Class Foo was written to be used over RMI, so it can marshal data and so forth.  All we need to do is create the registry and setup the communication path between context A and context B.  Now let's say Foo.addListener(Remote listener) is used by Woogle to pass an instance of MyListener.  So when class Foo wants to invoke the listener, the instance resides in context B.  The only way to make the invocation is to use RMI from context A to invoke a method in an object in context B.

Such is my work.  Maybe I'll have more interesting (read: concrete) details in the next few days.  That way I can accomplish the task of learning something new at work.

Careful...

Got to be careful not to go into deep-rant mode tonight.  Don't really want to spend a long time going on and on about some topic, probably because it could take all night and there is more than one thing to rant on about.  We're getting closer to that time at work where we discuss money and goals and the coming year.  Since many things have happened between evaluation time and epic monetary meltdown, er, now, this will be an interesting set of discussions.  It also has me thinking about my current financial state and getting my income tax done.  One of those yearly chores that needs to get done, but I simply haven't got to yet.  I'm hoping that I get a bit of a refund this year - I usually do get a little something.  The question of what to do with it weighs though.  The simple answer is always "pay down debts", which I cultivate through a line of credit.  Whenever I think of money like this, I realize I could do better and I should really get to where I can save by default instead of reduce debt by default.  I'm still pining for a nice big TV, but it doesn't make sense right now.  Anyway, money is a never-ending rant, so I'm going to move on.

Today was mail day on The Current, so I listened to people rant on about the things they heard this week.  Some mail was about a piece on fertility, centered around the 60-year-old woman who recently gave birth to twins.  Some of the letters line up with my personal opinions - people over a certain age will find it difficult to raise young children because they don't have energy for it.  One letter in particular noted that they were considered strange by other parents when they had a child in their 40's, but now it is far more common.  I think it's not a great idea, personally.  If having children is that important, why can't you sacrifice a little when you can handle things best.  Put another way, you should have kids before you're old enough to realize how much work it is.  The older the parents are when the process begins, the more likely they will have a single child that is coddled/treasured/bubbled.  If it took until you were in your 50s before you could have a child, that represents a huge effort and you'd like to protect that effort.  How will you ever be able to let go?  How will you be able to give the child the distance to let them grown on their own?  When you're younger, I think it is easier.  Bill Cosby would say that when he got in trouble, his father would say "I brought you into this world, I can take you out.  And don't think I won't because I make another just like you."  Good detachment, little be too heavy on the discipline, but you get the idea.

That is only the warm-up rant on the assisted fertility topic however.  The letter that got to me was from someone who pointed out that fertility treatments are a for-pay enterprise that costs a good deal of money.  A single course of IVF (In-Vitro Fertilization) treatment costs about $10,000.00.  The author of the letter thought that the government health plans should cover it, comparing this to knee replacement surgery.  The comparison was "If someone can get a knee replaced so they can go running, I should be able to get IVF."  That's paraphrased - I'm working from memory here.  First of all, the analogy is very, very poor - it implies that a person selfishly gets knee replacement surgery to continue doing something that will damage their knee and IVF is less selfish and less burdensome on the healthcare system.  Each successful IVF treatement brings additional load on the healthcare system - a new person.  There are no guarantees that the treatment will work, so often several treatments are necessary to achieve a successful birth, another large load.  The knee surgery person is hurting only themself.   The next part of my argument is a not as fully worked out, so I apologize for any incoherency.  Maybe there is a system reason why a particular couple can't conceive - systemic in the natural system sense.  Maybe there is something about those two people, the time, the place etc that makes it impossible for them to conceive in the regular (fun?) fashion.  Considering how important new life is to species, that says something.  I don't mean that IVF technologies are inherently wrong and I don't believe that it is "fate".  What I mean is that we do not know very much of how our bodies operate on the whole, so the living whole may be sensitive to things we don't currently understand or recognize now.  What bothered me the most about this letter was not the suggestion that fertility issues should be covered by our Canadian public health care system, but the insistent tone of entitlement.  The author implied their right to proper life were violated because the gov't won't pay for them to special treatments to conceive.  Why do they need to have the same life as all their friends?  Does their best friend having a child mean they need a child to complete them?

Now I'm getting petulant, so I'll move on.  I can't know what motivates their need for a child, so I'll continue on and say that I think it would be a good idea for the public health care system to support fertility treatments in some way.  An expert came on to help talk about the issues in the letter and he indicated that some treatments are covered by the system now, but IVF is not covered.  He mentioned that some countries in Europe will cover IVF for the implantation of 1 embryo, and will not do it for women past a certain age.  This tied back to the 60 year old woman who had IVF treatment and birthed twins - she had the treatment done in India.  I think IVF should be covered, but it should be provided in a system like the organ doaner system - patients are triaged and served in the order of some list.  Devising the rules for ranking of that list would be difficult.  I would use age as a factor, but there is obviously more parameters to consider.  However I don't think that the private option should be removed - if you have the money to pay for the treatments, have as many kids as you like.  Obviously you have money to support all these treatments.  Free-market thinking has huge holes, as octo-mom in California proved (my wife's term).  The woman who recently gave birth to octuplets in California is single, no job, has several kids already but somehow afforded the treatments that resulted in the octuplets.  Anyway, I suspect we'll find in the future that the natural methods are the best - most robust, safest, most reliable.  We shall have to wait and see.

That's aaaallll evverybody!

Guess today is the 50th anniversary of the death of Buddy Holly, so the title's a decidedly weak play on a Simpson's joke (the gravestone of the Big Bopper).  Just a random item - not something I'm commemorating or celebrating in any particular fashion.  What I did just do was watch Scrubs, and it's still going strong.  I like its simple formula - consistent, straight-forward comedy with an ongoing story to tie everything together.  I have a real hankering for some gium and tonic though... Don't really want the gium-legs though.  I haven't seen all the episodes for this season, but the ones I have seen I've really liked.

Got a new Spectrum today and I was surprised to find an article that strikes a chord with where I'd like to head at work.  It gives some handy points on how to make the jump from being a heads-down techie to someone that can talk with management and be helpful.  Fortunately for me, I do some of the items naturally - speaking with candor (is there any other way?), real-time ideas (again - is there any other way?).  The other items - "what-next ideas" and "management mind-set" are things I have to approach.  The "what-next ideas" is looking forward to next steps - something that developers/engineers/techies don't really get a chance to do because they're too busy making things work now.  The "management mind-set" is the hardest of all because it includes items like:

4. Can you learn to tolerate the fact that some decisions are based on politics? Can you accept that the technically right solution isn’t always the right organizational solution?

I'd judge this to be one of the most difficult for the engineer/developer/techie/{label} to adapt to because part of their job is to make the right thing happen, where "right" is measurable in an objective manner.  I've heard this described as "picking your battles".  The purpose is clear - you can't oppose every item, can't fight every little thing because nothing would get done.  This was something that I started on the road to since about grade 7.  I was doing a special project with a partner - group projects weren't really done in grade school.  I had an idea of what I wanted, and I just kept sticking to them until they were all that was left.  It took a few years to realize all the levels of wrong that was - ignoring the opinions of my partner, letting my opinions spill all over their ideas until it was clear to my partner it they shouldn't try.  Not my finest moment, but that's what we all need - mistakes to show a better way.  If I was truly enlightened, I'd be able to predict mistakes and correct them ahead of time, but I don't think that happens much.  

What I realized much later was that it was best to gather everyone together and try to verbalize ideas.  At least, that's what helps me the most.  What I have been refining is how to guide such a discussion without leading it.  I've come across as trying to lead (or herd?) and that isn't a collaborative  method, shutting down disagreement and taking things in one direction.  What I am really doing is working through all the ideas by approaching them from different angles.  So I have to be more finessed (subtle) with this technique, so I can keep people participating and collaborating while I still get value out of it.  Very complicated, but whatever - it's a new skill and it's good to develop new skills.  Much like writing and blogging.  Blogging helps me to express myself quickly in print (in bits?).  Probably should do some review and editing to get any real benefit out of these efforts, but whatever.  I'm typing onwards, no backwards! Upwards not forwards!  And always whirling, whirling, twirling towards freedom!

Hopefully, tomorrow will be a good hockey day and this cold will get a little better before then.  Hopefully both goalies show up.  It's a time for hope and I have to keep hoping I guess.

Day 30 - The end of January

Pretty good day - we had a successful demo, though all I did was bring Timbits.  Something that our company adopted and I feel is an excellent part of the software lifecycle, is the demonstration of the completed feature.  This probably doesn't happen often enough, but whenever it does occur, I think it helps bridge the gap between the line-items that managers and higher-ups have spent so long talking about and what the ultimate user will see.

Something Agile-related that I heard this week, but less positive than demos, were questions from a status meeting.  The question centered around whether we (as a company) should mark a particular feature done or "at risk".  The reason for the question is the trouble - a defect in third-party software.  To make the issue more accessible, let me pose a question: Alice and Bob are writing software that must be combined to form a final product.  Alice's portion requires Bob's to work.  Is Alice done only when the final product works?

I'll let you think about that.  That was probably long enough, or you're impatient and don't want to think about it.  Either way, if Alice isn't finished until the final, combined product is working properly, then Alice is responsible for Bob's piece as well.  Not directly of course, but if Bill wants to buy the final product from Alice, then Alice is responsible for the whole product working correctly.  If Bill combines the piece from Alice and the piece from Bob, but Alice says her part isn't finished until the combination works, Alice is assuming responsibility for ensuring Bob's piece works, even if Alice has no influence over Bob.

That explanation isn't really any better than the original description, but what I'm trying to say is that the questions in my workplace tell me that there are some people that feel that our company can't be finished until the end product works.  I have a big problem with this because we are in the middle of a software sandwich, with one company building hardware and the first layer of software, us, and then another company builds the portion that sits on top of everything else.  If we can't say we're done until everyone else is, we've failed if any of the other two companies has a problem.  But our company can't alter the software from the other two or even influence them.  We'd be taking responsibility for things we can't change, like being responsible for bad weather.  Sure it makes things less nice, but we can't alter the weather - how can we be responsible for it?

After that rambling description of the problem, I'd like to state that I understand the motivation behind the statement.  It is motivated by a desire to make the best possible product.  However, being part of a compound product means that all we can do is our part as good as possible and help identify areas that need help in the other portions.

Had a pretty nice evening - brought some pizza over to my sister's place where the kids were having a good time, but not in the same room as the adults.  Makes life so much better when there is an appropriate amount of distance between the two groups - too close and you drive each other insane, too far and you wonder what's going on (or get lonely - haven't run into that yet).

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.

Day 21 Work intrigue

Soon I will quit tagging each post with a day - I think after this month, that should be good.  It's a nice reminder now - keeps the whole thing moving along nicely.  Not so nice was the brief meeting at work today.  We were abruptly summoned to an "all-hands" meeting to find out... that some people were being let go.  Not people in the area I'm directly a part of, but people that I've worked with, possibly for years.  Something that was really nice was that they were not named by those in charge.  They have 2 weeks and have been encouraged to spend those two weeks on the job.  We were told that some may come to say goodbye, but that would be a personal descision.  That was followed up with reassurances that these were the only cuts.  The areas effected were named and it did make sense that some would be let go as there was a re-organization a few months back.  That re-org made a few positions redundant and this was the ultimate result.

We had been assured, earlier, by one of the big bosses (boss 3 times removed or some-such) that our company was dealing with the economic changes by halting expansion but preserving all current positions.  This was true for those not effected by the re-org apparently, but it did hold true for most of our company.  Turns out any "cuts" that may have come our way were done by elminating some of the positions to be filled.  I consider that to be the best kind of cuts - the cuts to positions that might-have-been.  Among our two sister offices, one made cuts similar to ours (elimination of positions not yet filled) but one had to cut other staff.

On that note, I would like to say that I'm really sad to see that anyone has to be effect by these changes and hope that those who find themselves without work will find something quickly.

On the hockey front today, we managed to get nine skaters out, but one of our goalies pulled out, having misplaced some equipment at home.  That provoked a discussion in the dressing room after on how to handle the situation.  A popular view was to have a goalie who commits but doesn't show pay their portion (normally goalies don't pay at all).  I suggested they should cover the cost of a rental goalie, but I'm not sure that is the best way to deal with the situation.  The problem is the balance between getting goalies to come out, which is difficult as they are a pretty precious resource, and making sure enough skaters show up consistently to keep costs reasonable.  Everytime two goalies are promised but don't show, some people leave disappointed and don't come back for a few weeks.  So some kind of system needs to be worked out, but I still don't know what that solution is.

The new skates are still reminding me that they are there pretty good, although my feet didn't have that constant ache.  The right foot got irritated on top again, altough this week it was much better.  Took almost the whole game before I noticed anything.  I tried to keep the last few eyes loose, but it wasn't perfect.  I suppose I'll find the right balance soon.  Plus I'll take them in to get reheated and fit again.  I'm beginning to think maybe I need a different insole on the right foot.

Day 14 Chilly, but not bad

Not playing hockey was weird - stayed up too late because I didn't have to be up early.  Didn't sleep in too much, but then headed out in the weather.  Not too bad - it was about -12 when I got going.  Shoveled the driveway and relished the cold.  I like being outside in this temperature if I'm prepared for it.  I had a nice sweater on - something I can only do when it is cold out.  That and moving a little bit of fluff around and the whole thing is quite pleasant.  I can remember actually being cold when I was a kid.  That was usually after 1 or 2 hours of building snow forts and some-such, and my gloves (or mits) had doubled in weight.  When the sweat from underneath meets the snowmelt soaking inwards, that's when its really cold.  That or when I'm standing around while the my kids are doing that.  The standing around is always what gets you.

I'm going to have to find an excuse to hang around at night at my parent's house some clear night in this cold.  It is the most special time to be outside - bright moon, blue-black sky, gleaming snow blanket criss-crossed with the ever-thining branches.  The air precise and the silence sharp.  Moving around makes that bright squeak, but that seems like an insult to the night.  Got to remember to breath - but not too deep or else the air stabs at the lungs.

I think I could do better to describe a meditation, but that's something.  What I wonder is what would happen if I'm standing outside in the bright-dark and the deer start wandering by...  They keep looking for acorns and the remains of the garden produce, so it could happen.  Maybe I need to find myself a sturdy deer-whomping, er walking, stick.  I think my dad still has that one I cut a 15 or 20 years back - a nice young hardwood (beech? ash?)  about 5cm in diameter.  I think it must still be in a garage somewhere - hard as all get out, and never cut so it keeps all the strongest aspects of being a tree.  I thought I saw it a few months back, but it would be an excellent walking, er deer-whomping, stick.  That is something I have to go looking for - definitely.

Day 12 - The Pudge Factor

One thing about the holidays is that whole "gaining weight" thing.  I am not and have never been the person with the tiny waist.  However, the last few months have been sitting rather uneasily around my middle.  The main problem is simply not getting to the gym.  It's kinda nice to avoid it right around January 1 as there are people in attendance that won't be in attendance in short order.  I'm gonna have to get back on track with that tomorrow morning.  Playing hockey a couple of times a week keeps things reasonable in terms of energy level and total-body-squishiness, but when I can get to the gym for the other 3 days of the week, that does a body good.  Especially in my business - the sitting down staring straight ahead business.  Like the salesman at "The Vast Waistband" on the Simpson's episode King-Size Homer:

Work, huh?  Let me guess. Computer programmer, computer magazine columnist, something to do with computers?

His speculation of "...it must be all the constant sitting and snacking..." is one of the great banes of the information industry.  Ah well - a job is a good thing - it pays for my blogging habit.

Anyhoo, I'm involved with an issue at work that seems to be gaining some traction vis a vis a root cause of the problem instead of an eternal examination of the symptoms.  The current line of investigation suggests the issue was a small problem that leads to performance issues over time.  This is the type of problem encountered at this stage of the project.  The software development is long done, much testing is over and we are left to sort through the "long tail" of remaining issues.  These are the bugs that arrise from complex or long-term interactions, exactly the problem in this case.  We've been working on this project for quite a long time and I suspect that many developers at my work have either passed by or never knew about the "embedded" aspect of our work.

The devices we work on are embedded, but (fortunately) they aren't the embedded ones I first learned on.  These machines have more computing power, memory and long-term storage than I had access to for the first 15 years of using a computer.  My first PC had 1 MB RAM, a 80286 processor and a 10 MB hard-disk.  These devices have 50 MB RAM for Java (plus much more for the underlying OS), hundreds of MB of Non-volatile memory and 300 MIP processors.  So I can understand how embedded ideals can be overlooked during development.  This is the stage of the project when those embedded design patterns pay dividends, or come back to bite us.

One of the best things that these embedded designs lead to is software that is compact, fast and resource-sparse.  These ideals will be more necessary when this software is more widely deployed and possibly developed upon.  Hopefully I can call some attention to this move away from the "small" before we begin the next project in earnest.