Why a Worker’s Cooperative

Standard

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 http://pragprog.com). 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

Standard

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

Standard

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…

Changes

Standard

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

Standard

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 often 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.

Cannibal: A simple Object permissions framework for Ruby

Standard

I’m proud to announce that we’re releasing one of our newer frameworks into the open-source community – specifically under the Simplified BSD License.

Cannibal is a permissions framework for object-to-object declaration and querying of permissions or capabilities. It is distributed as a standard gem library through rubygems.org. You can also view the source-code at github.

So far, Cannibal has done reasonably well for us on various projects. It’s syntax could use some improvement but we believe it’s fairly expressive as it is – if you have suggestions for improvements, please write!

Basically you declare a class as either an Actor, or a Subject, or both. You do this by including the appropriate Cannibal mix-in:

class User < ActiveRecord::Base
    include Cannibal::Actor
end

class Thing < ActiveRecord::Base
    include Cannibal::Subject
end

Then you declare permissions for your Subjects. For example, if you want any User to be able to view any Thing object, but only want users with the “Administrator” role to be able to edit them, you might declare that like this:

class Thing < ActiveRecord::Base
    include Cannibal::Subject
    allow User, :view
    permission({
        :actor => User,
        :verb => :edit,
        :actor_proc => Proc.new{ |user|
            user.role == 'Administrator'
        }
    }) 
end

Once declared permissions are easy to query, and read very well:

if @user.can? :edit, @thing
    ...
else
    ...
end

As you can see the permissions() method on Subject is still a bit ugly, and is the main reason for the < 1.0 release number. I’m definitely open to suggestions on improving its syntax.

Testing coverage is not bad, though there is some duplication between our rspec tests and our cucumber tests, and there’s a ton of refactoring yet to be done, but it’s working on a couple pet projects of mine and will be going into production for a customer project or two within the next couple weeks.

Enjoy :)

Software Development Is About People

Standard

We as an industry forgot this for a long time, and I am proud to be part of the movement to bring it back.

I hear all the time from people about projects being late, features missing, broken or “I can’t believe that ever worked” code. Often this is the voice of the customer feeling like they’ve been “had”. That their developer just didn’t listen to them. And now they’re stuck with something that they didn’t want.

This is definitely the symptom of a relationship that didn’t exist or just went bad.

I have seen projects do this, even been intimately involved. Projects where the technology that was delivered was even great but the customer relationship falls apart because it missed the mark, or they became so frustrated with the process that they just gave up.

And make no mistake, it was the software developer that failed here.

I’ve said and heard this so often that it sounds cliché – but the vast majority of time spent on a software development project is figuring out what needs to be coded.

Align what’s in your developers’ heads with what’s in your customer’s head. This is easier said than done, but regular face to face collaboration is key here. Two way participative engaged collaboration. Watch for when meetings become one way. You know what I mean, one side talking and the other side nodding giving the illusion that the idea is getting across. Fix this immediately, questions are your best tool here.

If something is said at any time that doesn’t fit, don’t let it slide! It could be a contradictory requirement, an unspoken assumption, a change in motivation. Stop and talk about it, figure out where it came from. It might just be a bit of ad-lib that is easily discarded or you may need to abort your sprint and have another planning session.

Also, recognize early when it’s time to pull the plug. Sometimes a customer is so unfocused that every status meeting they’re looking in a different direction. Agile tenets tell us this is ok, they can change their mind at any point and queue those changes for the next sprint, but if they aren’t pulling in roughly the same direction every sprint you may be going from Toronto to Montreal via Boston. Maybe you should have focused on getting to Kingston first.

So, take time during a project to connect everyone. Get them talking, honestly and openly. Don’t be afraid to look like a fool because you’re not. Show your courage from the start and you can avoid the illusion of incompetence later.