When it comes to software development, I’m against documentation. At first read of that statement, most techies should assume me to be a caveman developer. It should outright scare most software management types as most processes are about providing management a means of controlling the development process. This relies on the development team documenting their work in a way management types can grasp. That’s obviously a real need but let’s put that aside and assume that your real goal isn’t to control the process from outside but instead from within.

The need for development documents is a symptom of communication issues within the dev team. They perform other tasks like force you to actually design what you’re going to build. If you had a team who did that without documenting it, would it matter that it wasn’t written down?

My ideal development team, a completely unattainable ideal, would have no need for documents and every character they type would be actual code. I’m not referring to requirements docs or functional specs from the business team. I’m referring to documentation within the dev team itself.

The ideal team would be a Stanley Cup winning hockey team. They wouldn’t have to talk, there’s no need for verbal communication, they just know what each other is thinking, what they’re about to do, where they’re going to skate next. When they started the season they made mistakes and passed to open ice where they thought their teammate would be. As a hack, they started yelling out “drop pass” or “go to the net”.

The point is that the documents should never be viewed as the end goal because they never were. The end goal is working software. Most teams will always need some overt communication, never able to completely abandon it but the best reach another level.

Instead of looking at a dev team’s documents as unavoidable paperwork, try looking at them as hacks. Think about what could be done, in terms of team structure and dynamics, to remove the need for them. It’s like the stop sign at the end of your street. Our goal should be to take that sign down as we all now have the common sense, compassion, etc to stop our cars at that point.

Ok, like I said, it’s an unrealistic ideal. Do I ever see myself being part of a development team with no dev docs? No, it’s not realistic nor is that my point. Can we learn how to improve our team and how we go about building software by analyzing these “signs”? I think so.

We don’t have an office. We all have our own offices and improvise when we need to meet, choosing to meet at one of our offices, rented space, a coffee shop or pub. It works and keeps things fresh.

As I’ve mentioned before, it’s also something I wrestle with, would we be better off in a traditional office? Looking into coworking is about maintaining the positive aspects we possess today while gaining the good parts we’re missing from a traditional office space, hopefully leaving behind the annoying toxic parts.

“Teams work best when you get to know each other outside of work”

That’s key. Whether you have an office or an RV, that’s a big part of building a functional team. Having an office doesn’t guarantee you that and even without one I think we’re better at this than most offices I’ve worked in. Having an office can act as a crutch and leave you not explicitly focusing or working on this aspect. This should be our focus, not simply keeping up with the jones’ by getting back into the cube.

I reworked the shiftMode sidebar, adding a picture of moi, and a zoomcloud to provide another way to browse content. I’ve always cringed at the idea of adding a picture of myself. It strikes me as such a vain thing to do. I finally caved on this as I’ve come to realize that I want to know as soon as I browse to a page whether or not it’s written by an individual, a group of people, or a company. The fastest way to convey that a site belongs to an individual is to add a picture of yourself to the main page.

I apologize for putting you through the agony of seeing my mug but I swear, it’s just so new visitors know that this is just me not some shiftMode Inc.

Since I made reference to Flock not being there yet, I feel I should mention I’m using Flock almost exclusively now. The deal breaker was discovering how their search bar actually worked. While they don’t seem to detail it here, the search bar also searches your bookmarks and history. It does this not upon hitting enter but while you’re typing your search. The result is a fast, usable means of searching all relevant locations using only the keyboard.

So using the example I used in my previous post, I can now type “CTRL K tsn” then the down arrow once and enter to get to tsn.

Does this Globe & Mail piece count as plagerism?

“So she organized workshops that encourage managers to stop telling people what to do and, instead, ask thought-provoking questions of employees.”

I’m kidding and while I don’t pretend to pull any ideas out of thin air and we’re all just reinventing each other in the end, I’m sure glad I put that post up before today’s paper. Had I not, I would have hesitated in order to prevent the appearance of outright copy and paste. The G&M piece is a good read and details some specific steps to move forward with this approach.

If you’re using two monitors, give this a try. They offer a full functionality demo version. I’m using the trial and will be purchasing when my trial ends.

It’s a soapbox day….

You can’t raise a responsible person by not giving them any responsibility. You can’t build a team capable of making intelligent, quality, fiscally responsible decisions if only a small subset of people make decisions for them. Instead of a small subset of a company making the ‘important’ decisions, leaders must ask intelligent questions of their people.

Lead people with questions, not answers. Have faith in them and be willing to accept decisions and answers that differ from your own. It’s far more valuable to the long-term development of an organization to have a company filled with individuals confident in making decisions. The alternative is a group too scared to do anything but sit and wait for their next chance to ask the guy who makes the decisions.

Get excited about wrong decisions and bad news. Encourage individuals to take action, make mistakes, learn from those mistakes quickly and take more action.

View team members who trumpet only good news as red flags. They’re either misrepresenting situations or aren’t comfortable conveying the bad news. This is partly symptomatic of reward systems based on managers having to evaluate their own teams. People hesitate to bring forward the bad news, or they happy-filter it, as it directly impacts their compensation. Bad news exists, even if hidden, and we are in a far better position if we know about it as early as possible.

If leaders punish, frown, whince, or discipline people for making incorrect decisions then you’ll quickly have a group of people taking no meaningful action. Their actions will be the absolute safest, most innocuous path they can think of as they continue in ‘just don’t screw up’ mode. The team will stagnate and innovation won’t exist. Leaders must view mistakes as exciting learning opportunities and drag them out into the daylight.

Even college basketball’s Final Four used this approach.

Seth touches on a similar topic to my recent IT battles post. The key difference being that Seth‘s example deals with company policies on how employees interface with their clients. While it’s the same issue, my post used the example of company policies for how employees interface with each other across teams and departments.

Of course I love his idea but the issue is never the idea. In truth, 99% of retail companies out there today would require a major culture shift to even consider this idea. Even that isn’t the real issue though, ideas are cheap, coming up with them is the easy part. What I’m interested in is how do you actually pull this off across a large retail organization?

This is about formalizing the process of questioning standard operating procedures. Shifting your organization from simply doing “what’s in the book” to doing what’s right for the business today. In the real world that has to be balanced with getting things done and not creating a culture where every employee shows up to work with a different idea of how things will run today. The key is building a communications network between those people and getting them comfortable with this topic. Ultimately it’s about asking them the right questions and giving them a forum to discuss it amongst themselves.

Some Links:

• A great article on questioning SOP in the military.
• While I haven’t experienced it first hand, Great Harvest appears to have done an outstanding job of focussing on, and creating, that communication network. They demand that each of their stores are run uniquely and then work on sharing the experiences to allow other owners to learn quickly. They view each of their stores as individually run R&D labs. Quite different from the typical franchise approach where the only decision you get to make is….actually I’m not sure there is one.
• Book: Bread and Butter, What a Bunch of Bakers Taught Me About Business and Happiness

Wish I’d known about this before, now I do. Let’s say you need to refer to Custom.Session and NotCustom.Session within the same class. Refering to Session alone is clearly ambiguous but it’s annoying, and clutters the code, to have to type those full paths in every reference. C# allows you to alias them in the using call:

Sorry for getting violent, or hinting at violence with the written word, but I really can’t stand Visual Basic.

Fine, I get it, C# and vb.net are almost indistinct from a functionality perspective. In the end it’s all compiled down to MSIL but no one writes MSIL, okay some probably do but not 99% of the development community.

As Nigel Shaw sums quite nicely in Not Another C# Versus VB Article, it is ultimately a culture issue. In the end Microsoft took such a soft road with vb.net that they left the door wide open to every ‘worst practice’ imaginable.

Some other quotes I had lying around in notes that I don’t know who to attribute to:

• “C# is a future language with international standardization muscle; the others are just legacy language reruns. Don’t write new code, especially class library code, in them!”
• Microsoft’s developer roadmap specifies that C# is intended for class library development while VB for RAD development.
• C# has much greater potential for widespread adoption, not only by developers but also by platforms, already having been released on other platforms (Mono 1.0).
• C# has the lead in language extension while VB continually plays catchup.