Conversation has continued in the comments, and I think it's going in the right direction. But then Anthony takes offense to the fact that I call out to Jason on my blog.

I'm engaging the conversation through my blog because not everyone is on twitter, and not everyone is on mailing lists. I can safely say that the majority of the alt.net regulars in London are not even subscribed to any mailing list. By bringing the conversation outside of the echo chamber silos that exist in mailing lists and twitter, we get more point of views and that helps me understand things better.

Which was also a reason for posting. I genuinely dont get it. It's either just a manifesto showing intent, or it's much more and that much more I've yet to hear about.

I raised two things in my post: the first on the fundamentals of craftsmanship, the second on community involvement. On the former, the discussion has started and Cory has raised points that make very much sense to me. I'll be bringing more of that conversation on the craftsmanship mailing list, and see what happens there.

The second fundamental is the one of community engagement. I called on Jason on my blog because I assumed he was involved in the Software Craftsmanship movement, having organized a conference bearing the name, and both being presented together on the wikipedia page mentioned in a recent message on the craftsmanship mailing list.

From that assumption, I made an additional one: if you put your time in organizing a conference about something, you want to see this something go forward and you go out there to discuss what it is and why it's important.

And I made a final assumption: any new community grows by having ties with existing one. You embrace and extend. Otherwise communities grow in a silo.

On the first assumption, apparently the only relationship is the book and the wikipedia page, and Jason has said he was not in the job of convincing me or anyone else, he was just a signatory supporting them (Did I understand it correctly this time?).

By extension the second assumption also collapses and someone else may have to come and take up on that offer to come and talk software craftmanship at one of our meetings. And the third assumption is my own opinion on community building, still stands but has no value now that the other two collapsed.

The thing is, with Jason proposing a regular meeting around the topic of Software Craftmanship, and with the focus the alt.net Beers has had so far, our event would become completely redundant and unnecessary. And I'd be quite glad if that happened But if no one comes and engage us, and if my attemps at engaging fail, it's just not going to happen.

So, Anthony... I really don't engage your brother for the sake of it, I engage him beacuse I assumed his involvement was more than it was, and because my few messages to him on twitter have either received no response or responses that were not educational. By blogging it, Jason has responded, points have been cleared and we can move forward in the conversation. So overall I know more now than I did then.

And finally, I haven't belittled the conference in any way. I'm sure it was a very successful one, and people seemed happy enough blogging about it. But I am very surprised it hasn't been broadcasted much in my neck of the wood, even though one of the guys helping organize (Gojko) is *definitly* in my neck of the wood. Why? I'm not sure. But if the intent is to grow and learn, then there could've been more outreach to existing communities.

I don't think I have trolled or attacked anyone personally. I'm just profoundly confused by the why, and the apparent disinterest in involving and engaging existing technical communities.

And I could've answered that on your blog, Anthony, if the comments were not disabled. But at least that'll clear-up my personal rules of engagement when it comes to communities, bloggers and the twitteristas.

[Update: Jason has responded in the comments that he was not responsible for teaching or convincing me of the values of the software craftsmanship movement. If anyone in London is interested, I extend the invitation to come and talk about software craftsmanship with the rest of the alt.net community. Don’t hesitate to email me.]

There is a slight breeze coming from a corner of the software development world. The software craftsmanship community has released a manifesto.

I’m not signing it yet. I’ve read the mailing list, I’ve read the manifesto, I chatted with people on messenger, and I still can’t figure out what the objectives of the manifesto are. And the few questions I have or had have not been answered.

Mark was kind enough, on twitter, to explain to me that it was about creating awareness that there is a problem with the current state of software development. Of course I couldn’t agree more with that statement. After all, this is one of the things that the alt.net communities have been focusing on a lot lately (as in, in the last year).

But just like the post-agile thing I never really understood, I don’t understand how this has much relevance beyond making a statement. I value the craft, but I do not believe that my craft, which is of a different category from what some developers do for a living, is necessary all the time.

Then I have an issue with the word craft, because it is always being opposed to the word mass production. But there is no such split in the software world. Any historical effort to turn development in mass production has failed (4GLs, software factories, etc). It never happened and it never will, and as such I do not see it as a positive outcome to encourage people in making the distinction.

The other thing that I’m confused about is that, while London had a Software Craftsmanship conference organized by Jason Gorman, I have not heard about any of this till very recently, nearly by accident. A search on the alt.net mailing list has triggered no apparent results. I only heard talks about it from one ex-BBC at the alt.net Beers, once. Nothing at KaizenConf. So it comes a bit out of the blue. So I invited Jason Gorman to the alt.net beers a couple of times, without a response. Let me reformulate the invite once more on this blog. Jason, come and explain to us why Software Craftsmanship is important and why we should care about the manifesto. I’ll even give a theme to the evening so we can discuss it for the full hour.

Finally, there are scents of local optima in the air. What is the value of the craft beyond the value brought to the customer? What is the value of becoming better locally, in our approaches to software development, when the rest of the organizational structure is left to its own progression? Indeed, Markus Gaertner proposes the following on the mailing list:

While our highest priority is to satisfy the customer through early and
continuous delivery of valuable software, our second-highest priority is to
write well-crafted code to do so.

And that’s where I seem to differ with the current trend. I don’t believe in the value of changing the software practices as a separate priority from the one of satisfying the business in generating value.

We do software that is well designed and changeable because they let us react faster to the business changing needs, and minimize costs of maintenance in the process. And knowledge and practices only exist to support those needs.

Without the business needing us to help it generate profit, there is no value in our craft. None. Nada. Zip. And when you start decoupling our needs as craftsmen from the needs of the people relying on us, you risk falling in the trap of early optimization and local optima.

So if you have a better understanding of it all, and I missed the point, please explain, I’m a willing learner.

Every organization goes through a stage in its life where boundaries between teams start appearing: developers do the development, infrastructure handles the admin, testers do the testing, etc.

With the specialization comes a redefining and splitting of responsibilities. And time and time again, the whole process comes with a corporate exercise of wall-building between teams: you need release documents, you need a UAT phase, you need to fill this form here or request that deployment there.

In itself, a more structured communication is not an issue, quite the contrary. Generating artefacts in a project to describe processes that cross teams is an important step to take in ensuring maintainability.

Where the team-splitting becomes an impediment is when teams start allocating themselves exclusive competencies: developers shouldn’t know about build scripts, release teams shouldn’t know about development, testers would build their own test scripts and not share them…

Why are teams claiming exclusive access?

Often, teams start by holding many responsibilities. Start-ups are full of people that know everything from coding to deployment to admin. They’re not experts in any particular topic, and they may do mistakes, but they have an involvement in all parts.

As the teams grow, those skills get dissolved. And as products become larger and more complex, and as companies gain visibility, the required skills become more specialized too. Failing a deployment in a small start-up has less impact on the business than when you have signed those 4 or 5 9s contracts with a corporate client.

The immediate reaction at this point is to create a specialized team and focus the skills of team members. Those teams are now responsible for only a small part of the project lifetime, and are judged on the reliability of *their* process rather than on the project itself.

You end up in a situation where the cross-competency skills have already been dissolved because of a larger team with more specialized skills, and what skillsets were present have now been moved in a separate team, diminishing the spread of skills even more. Of course, this will mean that more mistakes will be done by a less-skilled team in a specific area, and the team responsible for that competency will start building walls to protect itself from the resulting unreliability.

Doing some root cause analysis

You’re now in a situation where each team has built walls around it to enforce any phase transition through gatekeepers.

I am convinced that gatekeepers are a symptom of a wider problem in your software development lifecycle. Gatekeepers become a bottleneck, be it because of resources or because the gatekeepers usually know what’s inside the castle but have less knowledge of what is outside the castle. This is true for each competency needed to deliver a project: analysts, testers, build masters, developers, project managers…

How do you solve a problem like Maria?

The first step to resolve those bottlenecks is to take a courageous stance: recognize the competency of teams while preventing them from isolating themselves from the other teams.

There’s usually a lot of hidden pain, a lot of untold mistrust to resolve. Empowering teams starts by recognizing that every single person in the company *is* a skilled professional and *wants* to deliver better software. No buts allowed. You need to start addressing why you hear “those idiots have done this in that way, we can’t trust them”. Why did they do it in such way? Could it be prevented in the future? Can the chain of events that lead to the deadlock be resolved?

Once everybody has gone over their distrust for others, teams need to move from being gatekeepers to being enablers. Instead of building walls and processes, teams should be providing the tools needed by other teams to deliver. Developers provide the tool for the business to make money, analysts provide a tool to help developers understand requirements better. Testers provide the tools for developers to understand what success criteria are defined, and developers will provide testers tools to remove the manual steps involve in their job.

You do everything in your power to avoid groups becoming optimized at their job without the full chain of production being efficient. This is what avoiding local optima is all about.

Ideally, the organizational structure of a company gets changed: people work together on a per-project team. They don’t get shuffled around randomly, and they don’t get judged on metrics specific to their competency.

If a project fails, it’s the team’s responsibility. If a project succeeds, it’s thanks to the team. The project metrics are the only ones that matter. By empowering people and focusing them on project-based success metrics, you not only ensure that everyone has the same objectives, you also cross-pollinate competencies across the company.