Retrospective on 2015


The past year has been exhausting. I’ve never felt so much like a hamster on a wheel.

This year will mark 8 years into my transition, 5 years into my social transition, 3 years since my last gender affirming surgeries.

I’m very much at peace with my body now. The change came so slowly, I could hardly tell as it happened, but looking back at myself 10 years ago? I was a mess. Gender dysphoria had me over its knee, I was constantly distracted by it, it consumed me. It was a constant buzz at the back of my skull, pulling all my thoughts in towards it.

I did some pretty awful things to myself, the worst of which was letting an herbal supplement regime mushroom out to un-supervised self-medicated HRT. I was buried in shame. I lied to everyone, including myself about it.

Today, if it weren’t for the advocacy work that I do, I wouldn’t really be thinking about my gender at all. It’s no longer a concern. It’s even a bit awkward right now to write about it, because I have to dig up how I feel. Is this what cis privilege feels like?

Being comfortable in my felt-gender role (as opposed to my physical being) is a bit further off, but I push against the bounds of this one. Maybe it’s the feminist in me. I think that this is a struggle I have in common with many women.

I find myself drawn to communities where the struggle is ongoing, launching the Durham Region chapter of Ladies Learning Code (LLC) was a hallmark event for me here.

Earlier in the year I found my “tribe” at the Agile Coach Camp Canada conference in Cornwall. This set the stage for my courage to start the LLC chapter. It was an amazing event and I learned a lot about myself that weekend. I’d been unable to express why I enjoyed my team coaching engagements until I spent the weekend with so many wonderful coaches who shared that enjoyment.

I feel accepted by the LLC community, by the agile coaching community, and that seems to drop a hand-grenade into my lifetime of internalized transphobia. How this makes me feel is impossible to express in words. Suffice to say, I feel good.

Regular life of course is still a struggle. It’s a common struggle though, and I feel better equipped to bear it.

This year marked the launch of my first software service ( in 12 years. I’m excited for it, but I have the same fears as many entrepreneurs – will it be successful, will it survive, will people care about it. 2016 will tell me that.

What I find most interesting though, is that for years I’ve strived to figure out a product that I could build, and after the turmoil of 2014 what arose seems a merging of my social justice advocacy and my software skills, two worlds I didn’t see colliding, yet in hindsight it seems so obvious.

I fear for the social entrepreneurship bubble, it feels a bit like the popular kid in the fickle startup community. Like it was created to capture people with my core values and draw us in to the startup community and its constant search for the new megastar, constantly taunting us with promises of venture capital and government assistance. I have no interest in that endless chase.

Honestly, the reason I have what these folks call a social venture has nothing to do with their bubble and everything to do with my core values.

In the meanwhile though, it’s nice at a business level to be in the same room with others that hold these values, more than superficially. Startup practices like honing your pitch and cash management skills are universal and important, so for now it doesn’t feel too far wrong to be here. I do anticipate a falling out with the crowd though. That capitalist startup smell is present, and oh so unappealing.

At least nobody has suggested to me so far to offshore my development work. That ought to be an entertaining “conversation” for onlookers.

I still have far too much on my plate. In addition to my business demanding more of my time than it has in 10 years, launching Gender Journeys Durham, joining the CMHA Gender Journeys team in Peterborough, and launching the LLC Durham chapter, I feel like over the past few years I’ve filled far beyond the extra capacity I’ve gained with my gender congruence. I need to let go a thing or three, but focusing on the things that bring me the greatest joy will also bring me financial ruin, so I continue to sit on the fence. My latest two  joys at least cover their own costs (CMHA and Ladies Learning Code).

Thus is the lure of a social venture, work that is good for the soul AND pays well. It does still feel like I’m refusing to make this decision doesn’t it?

On the family side there’s not much change in 2015. I did attend a family picnic hosted by a cousin, none of my immediate family came (that would have been “interesting” – still estranged from my family of origin). Our oldest daughter is slowly re-engaging with us after a year of isolation. Our youngest still struggling to complete high school though she’s aging on. Our middle is past the middle of her University undergrad.

My spouse and I continue our journey, still reconciling our relationship, now with my physical changes. That’s a rough road, and not one I’m ready to share.

I don’t get to see many friends, or grow many acquaintances into friendships, but that’s OK. I have a couple friendships that blossomed in 2015 and help keep me energized, and I’ve always been a quality over quantity person when it came to friendships.

I don’t know what 2016 will bring me, but change is not only inevitable but required. My cash position needs to improve, and continuing on my current path isn’t going to do it. That’s OK though, I think it’s going to be fun!


Signed and Encrypted Email on OSX and iOS


I’m writing this as much for me as I am for you, my fellow netizen.

Signing and encrypting email on iOS is a black art. Get your incense and candles ready.

To start with, I usually use the free email certs from Comodo –

They’re, well, free. That’s about all I can say about them.

Each year, when your cert expires, you are issued a new “private key” along with a new certificate. Every fibre of my being screams against this, but hey, most folks don’t know how asymmetric cryptography works, so I can forgive most folks for not having this same reaction as I. In my world, your private key is your golden egg. You keep that private, handle it with great care, and never, ever, ever lose it. That private key is your personal identity in digital form.

OK end of rant on that. Moving on.

When you complete Comodo’s process, you will download to your computer a file, for some reason they call it CollectCCC.p7s and that’s how it hits your downloads folder. This file holds both the private key they just generated for you, and a certificate signed against it issued by Comodo.

On OSX, when you double-click that file it opens up Keychain Access and installs nicely. At that point, Apple Mail is pretty much ready to start signing and decrypting messages from others. In fact, the simplicity here is a bit deceiving because all kinds of things are happening behind the scenes that you might not be aware of, that give you a glimpse at why the h-e-double-hockey-sticks iOS seems convoluted as frak.

In order to get that private key and certificate to iOS you’re going to have to do something that I’m still washing off in the shower. You’re going to have to email it to yourself.

Here’s how:

  1. Open your Keychain Access program (it’s in Applications / Utilities – I just use Spotlight, command-space and start typing keychain… it’ll show up there)
  2. Go to Category: Keys and find
  3. One of them (you may have a few) has an arrow that you can fold down to see your email address certificate. Make sure the certificate isn’t an expired one if you’ve been doing this for a while. And for the love of all that is holy, keep those expired certs and private keys otherwise you won’t be able to decrypt messages sent to you in years past!
  4. Right-click on the listing with the unexpired certificate underneath it, and go to Export “”. Choose Personal Information Exchange (.p12) which is actually a PKCS12 file. Enter a good password – when it exports, that’s your private key all out in the open there for anyone to peek at and steal your identity.

OK, now you’re going to have this shiny .p12 file. I hope you’re at least using SSL / TLS for SMTP and IMAP/POP, but that’s yet another story. Email that file to yourself so you can get it to your iOS device(s).


When that email arrives on your iPhone / iPad / iPod you’re going to tap it, and install it. You’ll need to enter that password you entered on your Mac, and I do hope it’s as inconvenient for you to type as it should be. I fact I also hope you mis-enter it a couple times because it’s so complicated. And I really really hope you didn’t write it down, and I only kind of hope you had to do this process more than once because you forgot what it was between saving the file and getting that email. I’m not that much of a jerk, very often.

Here’s what the screens look like as you install your certificate…


You can verify that the certificate is in place if you go to Settings / General /




Now, go to your Settings, then Mail, Contacts, Calendars, then choose the account for which you had Comodo issue that certificate, then tap Account, tap on Advanced, turn on S/MIME, tap Sign, and make sure your email cert is selected. It’s fairly safe to leave Sign to ON and sign all your emails that go out, but once in a while someone may complain about the signature attachment if they don’t understand what it is and their email program is dumb and shows it to them.

You might want to encrypt your messages by default, but don’t worry – Mail only knows how to encrypt for the people for whom you’ve explicitly imported signatures… so you won’t all of a sudden be sending encrypted email to people that can’t read it.

Here are some screenshots of that process:


And now, you’re ready to go into Mail. There’s a couple gotchas and things that just aren’t that obvious.

IMG_0117First is when you get emails from people who have signed and encrypted it, you get these two little symbols – the seal with the checkmark means it’s signed (and you can grab their signature – which you have to do before you can send encrypted email), and the lock means it’s been encrypted (only you can read it and only  where you’ve installed your key and certificate).

Email is encrypted specially for each recipient against their signature. If I want to respond to this email, I must install this person’s signature. To do so, tap on their name, then tap on View Certificate, then tap Install. Here are some screenshots:

IMG_0118 IMG_0119 IMG_0120And now, when you’re writing an email to someone you can indicate that you want it encrypted. Just tap on their name, and tap the Lock symbol that appears.

If you get the messages below, this is where things get a bit funky:

IMG_0121 IMG_0122

So what’s actually happening here, is it doesn’t know what key you want to encrypt the message using, and/or it doesn’t have their signature/certificate installed. Make sure you’ve done the procedure above to install their certificate.

Now, go to your Advanced email settings again, go to Encrypt by Default, turn it on and pick your email address.

IMG_0116 (1) IMG_0125 IMG_0126Now go to Mail, create a new email to your friend whose signature you’ve installed, tap their name, and tap the lock symbol again. This should work now.


Now you can go back to your email Advanced settings and turn off Encrypt by Default. You shouldn’t have any trouble from here on in.

So there you have it, it’s a bit of a complex dance to do this, but once you’ve done it things should work pretty good for you.

Don’t forget to drag that .p12 file to your trash, and empty your trash, and delete that email both from your sent-items on your Mac, and from your inbox (and, of course, empty your email trashes)!

Through the iOS and OSX versions, Apple has tinkered with how this all works a bit, with each release sometimes introducing a new set of quirks, but hopefully this will do us at least until the fall.

Why a Worker’s Cooperative


This past weekend I was at the Software Craftsmanship North America conference (SCNA) hosted by 8th Light in Chicago. This is a wonderful conference that each year I manage to drag more of our staff down to experience.

SCNA was a bit of a break for me, as much of my time lately has been going in to setting up The Commons Cooperative, a new organization that I’m building focused on software development services for businesses, entrepreneurs, and what I’ll call “social good”.

While at SCNA, I was having a conversation with Dave Thomas (@pragdave, co-founder of The Pragmatic Bookshelf I was describing The Commons, and mentioned that we were proud of it being a different legal structure than most companies. Specifically, we are setting up The Commons as a Not-For-Profit Worker’s Cooperative.

His simple question was basically, what’s the benefit of a cooperative versus a partnership or other traditional business structure?

Not being well practiced in talking about The Commons, I stumbled. I found myself at a loss to verbalize why I was so passionately pursuing this avenue. Since then, I’ve been thinking about how I want to answer that question.

You see, my current business, Three Wise Men Inc. (which is being renamed to Mojility Inc.) is a standard corporation. I’ve been running this business for nearly 12 years, and we try very hard to retain a stable staff of developers. We have managed to establish a healthy collaborative culture, with people that care, enjoy mentoring others, and fit very well with the values of the Software Craftsmanship movement.

Now, I’m not the best at business development and sales. From time to time, when business is down, I’m struck with the difficult decision of when and how to lay off excess staff. I have a very hard time with this, we invest so much in our people, both professionally and emotionally. I think this is one of the reasons why our staff is so loyal, and our workforce so stable.

Now, think of the job of a CEO. As so bluntly put recently in Ruby Rogues #125 – Loyalty and Layoffs, it is this person’s job to maximize shareholder value. If the CEO does not do this, they aren’t doing their job, and should be removed by the board of directors. These are the values of a Corporation, a purely capitalistic abstraction, with the purpose of generating wealth for its shareholders.

So here I am, CEO of Three Wise Men Inc., with a fiduciary responsibility to myself as sole shareholder, to shed staff to the point of profitability.

There was my friction. These people, that form the foundation of my value proposition to our customers, that I so fervently and frequently argue are not a commodity, that cannot be bought and sold on the market, needed to be shed in some heartless savage act.

This here to me represents the fundamental difference between a Corporation and a Worker’s Cooperative. The values that drive the actions of the CEO.

The values of a Corporation are hierarchical, profit-focused, maximizing shareholder wealth. The values of a Cooperative are democratic equality, sharing, taking care of the needs of the community.

So I find myself having attempted to run a Corporation with the value system of a Cooperative.

Sure, by and large it mostly works. It’s very short sighted for a Corporation to neglect its staff in exchange for profitability. Corporations invest in people, not out of the needs of the people themselves, but the need to avoid the cost of re-staffing, retraining, reduced productivity.

It’s this alignment of values about which I find myself most excited.

The promise that I can execute, with full responsibility, using my own value system, to the benefit of our staff and customers.

And here’s the best part – I’m not alone! Every one of our workers is aligned. Not just doing their job for a paycheque, not just working for the financial benefit of some unseen group of shareholders, but working together, towards all of our common cause, for our customers, as people.

I have frequently referred to software development as a social endeavour. Now, it’s in our bones.

7 Simple Steps to a Successful Software Project


1.  Imagine an end-result in only the coarsest detail

Let’s face it, we’re all human. We can’t juggle everything in our heads, and we don’t have perfect clarity on day 1 of a project. You want to get your system in place quickly, and you definitely don’t want to waste time playing imagination games for weeks on end writing detailed documentation and pixel-perfect mock-ups that will be difficult for others to understand, and could be impossible to implement.

There is definitely value in a study of business requirements, written project requirements, and simple sketched mockups, but stay high level!

The more you layer imagined details on top of other imagined details, the further from reality you get. Write down and verify your facts, sketch out your vision, and get the ball moving!

2. Keep and communicate a clear and consistent vision

It’s OK if you realize during a project that your best chance of success means a slight change in direction.

However, be wary of too many or drastic changes in direction – pause your development until you’ve re-established your vision and reconfirmed your facts. It doesn’t make sense to continue spending time and money along any direction to which you’re not fully committed.

3. Stay engaged

Don’t send your development team away on auto-pilot. They will need your help, and you will need theirs – daily communication is healthy. As each iteration goes by, they will rely on you to imagine more and more detail on top of the code they deliver. Imagining the details on top of real concrete running software is what will keep you on track towards delivering your product.

In addition, if you see something going in the wrong direction, the sooner you talk about it with the team the more you’ll be moving towards your goal.

4. Ship

It’s OK if the product is not perfect on day 1. Call it an open beta if it makes you more comfortable, but the sooner you can get your product into the hands of your users, the sooner you will start collecting valuable feedback.

Remember, don’t imagine what your users will want, find out for sure by putting the product in front of them.

Sometimes you’ll hear the idea of focusing on your “Minimum Viable Product”, the simplest product you can build that has some value to your users. How can you fully imagine this without your users’ direct feedback?

 5. Keep the feature set small

Remember the words of Antoine de Saint-Exupery, “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.”

It doesn’t take much effort to build something complicated, and it is very challenging indeed to build something simple. It’s compelling as the project moves forward to imagine all the extra things it could do. However remember that by and large every new feature you add will make the product harder to use, and more expensive to maintain moving forward. Be very, very sparing.

This includes incorporating user feedback. You will get a volume of feedback from your users, but don’t take it at face value. Understand where it’s coming from, read between the lines, and either discard what doesn’t align with your vision, or re-align your vision.

6. The Long Haul

Your software isn’t an island. It lives in a world that constantly changes, and as with everything it must either adapt, or fail.

If you approach the project with a single up-front budget and leave nothing for ongoing maintenance, you’re ensuring the future failure of your product – it’s as simple as that.

Some technologies will be inherently most expensive to integrate from a maintenance perspective. Right now, social platforms like Facebook and Google+ are in constant flux and products that integrate with them can carry the highest maintenance costs as they adapt to what can be weekly changes. But who doesn’t want their product to integrate with Facebook these days?

Choose carefully and with your eyes open what technologies you integrate. Some will have a far higher impact on your maintenance costs than others.

7. Have Fun

Creating software is a uniquely rewarding experience. When you can see it in the hands of your users, and they appreciate it, it is tremendously gratifying.

But also remember the journey, product life cycles can span years or decades – revisiting the path to maintain and better it should be a positive and pleasant experience. If it’s not, you’re not going to want to do it.

Everyone does their job better when they enjoy what they’re doing. Keep your vision front and centre, keep a positive attitude, treat your users, peers and developers with respect, and it will be hard not to build something meaningful.

The Chaos in the Matryoshka


Those that know me know that I’m not afraid of change. I’m a big proponent of “strong opinions loosely held”. When something makes sense, grab ahold, if you can disprove it, move along. Don’t become too attached or you’ll find you’ve turned into an apologist.

About 4 years ago I announced I was done with fixed price projects. It was the best business move I ever made.

There wasn’t really any change in the amount of money we made on each project. But the spirit of collaboration we were able to bring to customers, stopping the seemingly constant disagreements over what was included or not included, what was a bug or not a bug, just ceased for the customers that understood what we were about. Software development became fun again, fulfilling. We have delivered much better work because of it.

Of course, the odd customer (who we’ve gotten better at purging) would still want to argue these points. For whatever reason, maybe they grew up in a world of fixed-price contracts, they’d try and turn collaboration into confrontation. Try and change the terms of our engagement.

I spend a lot of time thinking about the whys and hows of this, and I think it comes down to this – they’ve become blind to the chaos around them.

Chaos is everywhere, and builds on itself. It starts with a poorly understood requirement, snowballs into misunderstood emails and conversations, avalanches into the maelstrom of shifts in understanding.

Chaos is deceiving. It wears a mask of order and alignment. The human brain is brilliant at finding patterns, and it is so tuned to the idea of patterns that it will perceive them where none exist. Countless times, a customer has presented a requirement as a simple thing, we listen, we write it down, “this should be trivial” we think. And then through conversation and examination the mask comes off. Then we find it’s like a matryoshka doll, behind each mask is yet another that appears ordered and aligned. Eventually deep enough into the project we take apart the last piece and voila, chaos.

Real life is messy. Countless times we’ve had the conversation around the whiteboard where we’ve just scrapped a really elegant data model saying “Wow, this is awful! If only this business case didn’t exist…” We just discovered the chaos in the middle of the matryoshka.

Customers tend to get this. They know their business is complicated. Sometimes they’ve been ingrained in it so long that they’ve become blind to the ways in which it is complicated, but when things are drawn out logically they tend to say things like “Yeah, I know it’s strange, but that’s just the way it is.”

The risk in the software project lies in not knowing how deep in the matryoshka the chaos lies.

A fixed-price fixed-feature contract expects the software developer, with little to no prior knowledge of the customer’s day to day business dealings, to take on that risk and price the project accordingly. They’ll take wild stabs, based on their own prior experiences, sometimes masking it in a thin veil of reason. A fixed-price contract will never reflect the true cost of the software, you’ve either bludgeoned the business into paying more than they should, or the developer into delivering more than they could afford to (or worse, they walk away).

A target-budget contract has more of a shared risk. The customer accepts that they may not have a “complete” solution at the end, but that it was fairly priced because it cost exactly according to the work that was put into it. The risk on the part of the software developer is simply that they do their job professionally, and engage the customer appropriately to explore taking the matryoshka apart.

Over the past couple years though we’ve very much enjoyed a more holistic and sustainable approach than target-budget, but that’s the subject of another post…



I’m writing today with some important personal news.

Over the past several years, I have made a number of very positive changes in my life leading up to the most important life change I’ve ever made.

In a nutshell, I’m transgender and have struggled from a very young age with Gender Dysphoria – my gender identity, how I feel inside, does not match my gender assigned at birth. Being transgender is not a choice, but what you do about it is.

After two years of therapy, and a great deal of soul searching, I realized that I could not achieve my full personal potential until I began living my life authentically as a female. As a result, in 2010 I began taking permanent steps towards this end.

After August 1st, I will finally begin living permanently as Stacey Gillian Vetzal. “Steve” will cease to exist.

Initially I realize this may be a little awkward for some. For those of you who have known “Steve” for a while, it will take some time to remember to use female pronouns and my new legal name — and that’s OK.

I already live much of my life as a woman, in fact I have many friends that only know me this way. However unravelling 40 years of socialization as a male doesn’t happen overnight.

The wikipedia page on Transgender gives a great, if academic explanation of the term, but for folks close to me I keep a copy of Joanne Herman’s excellent and brief book – Transgender Explained for Those Who Are Not – for lending. Because transgender describes such a wide variety of people, it is hard finding resources that I actually relate to. I generally discourage people from using Google and the Internet at large to learn about transgender, it’s not very helpful.

Unlike many transgender folks, my life is at peace. I have an incredibly supportive family, very supportive friends, and a great work environment. Because I am an entrepreneur my transition is a bit more public than I’d have originally chosen, but when seeking personal growth it’s important to step outside your comfort zone.

The reality is I’m the same inner person I’ve always been. My interests are the same, my hobbies are the same, and my work ethic is the same. I will now simply be able to do these things with a greatly improved sense of inner peace and dignity.

I look forward to continuing to work with all of you, and welcome any questions you might have moving forward.

Decisions In The Dark


We write software today, it’s important to always remember this.

Often when we are asked to write software, we are typically provided with a list of “business requirements”, constraints under which we need to build it. Some of these are architectural, some are design, some are technological, some are legal or regulatory constraints, some are business goals, and some are expected features.

Depending on the customer, these constraints have received different levels of consideration. A large established business may need a tactical solution under which many constraints are imposed (you must talk to this database, interact with this webservice, solve this problem). A new startup business may have pages full of features they want, but an intense requirement to make money as soon as possible.

The problem is, that every requirements document is incomplete. To the extent that it’s been said that the most important information in it is the author’s phone number.

One reason for this problem is that often when we write, the words we put down don’t always say to everyone what we intended at the moment they were written.

Another reason for this problem is that the requirements document was written at a time at which we knew the absolute least about the project: before it has started (see Steve McConnel’s “Cone of Uncertainty”.) Invariably and despite the best intentions and utmost upfront scrutiny, it is incomplete.

In our experience, as you begin working on a project, as stakeholders and developers accumulate knowledge about the project, you discover new information and have the opportunity to clarify many things in your original requirements.

Agile and Lean Software Development tenets tell us that if we defer the decisions we make in a project as late as possible, we can make a more informed decision simply because we know more about the project. The key is finding the “last responsible moment” – an idea championed by the Poppendiecks.

The last responsible moment is that point in time when you can make the most informed decision, and when that decision can truly no longer be deferred.

So think back to your project constraints, which of them are truly constraints and which of them are decisions made in the dark?

The idea is so insanely simple, who could possibly make a good decision without gathering as many facts as they can muster?

We should all strive to be more aware of the last responsible moment, we owe it to our customers to ensure that our projects aren’t governed by decisions made in the dark.