That’s right, you get a _lot_ of geek talk!

SAW

I was invited to join this years Software Architecture Workshop which was held in remote Oppdal, Norway. This is a group of people that spend 3 days a year discussing al kinds of software related innovations and problems. SAW was originally introduced in Europe by Jimmy Nillson. The three days are formatted like an open space event, and I can tell you; that is a lot of information to swallow. This year was my first time, but I am going to do my very best to attend the other coming SAW gatherings.

Another cool part of SAW is that each year it is organized by different members of the group which means that next year it will be at a different remote location. Being remote is a key to this event, it ensures no interruptions.

Open Spaces

Like other open spaces at the beginning of the day everybody can put their meeting topics on a post-it, and place it on an open slot. Any topics that would not fit the schedule would be placed on a parking lot to be picked for a next round.

We ran three parallel tracks so there where enough good topics to choose from at any time. Before the day starts there is a marketplace; this is basically the opportunity to sell your topic to the other attendees. After that there is the change to negotiate with the people having the sessions if you want them to move it to another slot, incase you want to join two talks that run parallel. And of course at the end of the day the great discussions continued during dinner and in the bar till very late at night.

Sessions

The sessions I joined where about:

• Lean and Kanban
• Testing and Mocking
• Architecture (different topics, among CQRS that I hosted, REST, SOA and EDA)
• Creating a great presentation
• Systems Thinking

As you can see the range of topics is really wide and that is great, it enables you to go to a session where the topic is completely new to you and really open your mind.

Snowboarding

Each day had a break from 12:00 till 16:00, during this break there were no sessions planned (which of course didn’t stop everybody from talking about software), but for me this meant a great opportunity to do some snowboarding. Something I had never done before and I have to say that it went better then I imagined. I was actually able to get down the mountain, be it only sliding from right to left and back again facing down the mountain. But hey I was getting down the mountain. It was very heavy on the legs but loads of fun.

Finally

I completely loved the whole experience and would recommend everybody to go to Open Spaces events, they are truly the most interesting events where you learn the most. I do think the break is a necessary thing as doing this for eight hours straight would be to tiring for sure.

So now we got that out of the way lets look at a particular way that I find very effective.

Software Conferences.

Software conferences offer the unique opportunity to first of all listen to some great people in the software industry talk about the topics that they are passionate about. Secondly you can have great discussion with the speakers, get more details about the topics that interested you.

I think that this might be the best way of introducing new ideas, you won’t know all the ins and outs, but you will know enough to determine whether or not to continue investigating them.

But

Lets go back to that it is your responsibility to educate yourself; so you want to go to one of these great conferences like for example; QCon, NDC or Øredev. These conferences are very focused on software craftsmanship and learning, but when I look at the costs of these conferences then I realize that it is almost not possible to be responsible for going to these events yourself. It is easy to spend 1.500 to 2.000 Euro on a three day conference including travel and hotel.

So these big conferences are really targeting companies, and they don’t really consider that there are many developers that cannot go because their employer is not willing to pay for their education.

Now I completely realize that having these conferences costs a lot of money, and also that if they would give some sort of discount for developers that pay their own ticket it would be misused by more then a few companies.

But honestly paying the 1.005 GBP for the QCon London event does hurt my wallet, I hope it is worth it Please note that this post has been tagged as a rant, but I hope it was an ok rant.

I would just like to get the correct answers on the following questions in the comments section and then the first person to get them all correct will win the subscription.

1. I use the name “Fohjin” for my github project, what does this name mean?
2. What is the current name for the book that I am writing?
3. What is the single digit that the free giveaway coupon code starts and ends with?
4. What is the name of the _big_ Norwegian event for developers?
5. How much do you value product knowledge f.ex. ASP.NET MVC? When do you learn this?

Question 5 obviously cannot really be wrong, but I would appreciate an elaboration.

For a consolidation prize I got Google to get me 20 Google Wave invites to giveaway! Woot!

So why did I get a subscription for TekPub and not Pluralsight, well mostly because a.t.m. TekPub has a few topics that really interests me, Git & NHibernate, and one that is on its way that is very cool as well.

Disclaimer: I am not earning anything by writing this post and have no affiliation with Pluralsight what so ever. While it is true that David can decide to drop my blog from Elegant Code whenever he seems fit, this fact did not influence this post in any way

After only having watched a few tutorials and one part of the Agile course I can already say that the quality and clarity is very high. The instructors do a really good job in explaining the different topics in great detail and at the right pace.

Content

The content that Pluralsight On-Demand offers is very orientated towards the Microsoft product offerings, they include (but are not limited by); ASP.NET, ASP.NET MVC, WCF, WPF, .NET, SharePoint, BizTalk and Visual Studio. The offerings are divided into three different categories; How-To Videos, Tutorials and Training Courses. The time you spend on one subject in the different categories ranges from 5 minutes to 22 hours.

Of course I first went in and watched the recording David made while using my code (just to see what kind of bad things he had to say about it). I have to say I was pleased with the time spend watching it, given that I now know how to start using some techniques in Visual Studio 2010 that makes discovering and reviewing code and its structure a lot easier. And I learned this in only 20 minutes.

Currently I am watching the Agile course that again is presented by David, and again the structure and clarity is very good. An other good thing is that this course is split up into many smaller parts that you can skip to of replay, so there is no need to write down some time-code information in order to hear something again, or when you take a break.

After this I think I’ll take a look at some more indebt LINQ stuff.

OSS and Design practices

The content that I am missing a bit are describing / tutoring the various open source products and different coding patterns and practices. But I guess a.t.m. TekPub and DimeCasts are good supplements to fill these gaps.

Finally

I would highly recommend looking at this when you have to learn a new or brush-up on a Microsoft technology. In the meantime I still have quit some time left on my trail, so I am going to enjoy some more tutorials, and my next post would hopefully be technical again

We’re starting a software company!

Specifically, we have partnered together to open the doors on Guild 3 Software. Readers of Elegant Code are probably familiar with our writing and interests, so hopefully you can guess what we’re about.

Jarod, Jason, and I are strong believers in the ideals set forth in the Manifesto for Agile Software Development and in the Manifesto for Software Craftsmanship. Our shared appreciation for the craft of software development has always drawn us into a huddle at user group meetings and other places where developers gather. We are excited to bring this passion to our customers and our products. Accordingly Guild 3 is founded on four core values:

Integrity, Craftsmanship, Agility, and Community.

You can read more about these, our founding values, here.

But, What Are You Doing?

Several things.

We are working on some exciting, super-secret product opportunities. Maybe they’ll be more on that another time.

In addition, Guild 3 is a professional services organization committed to bringing the ideals of software craftsmanship to our work. We are already working with a few clients and delivering software, of course!

Further, we are participating in community events, conferences, and other opportunities to learn from our peers.

Regarding Elegant Code

To be very clear, ElegantCode.com is not a business. It is a blogging community of professional software developers who simply enjoy each other’s contributions. We will all stay actively involved in ElegantCode.com and will retain our blogging sites here.

Wouldn’t have it any other way.

On a personal note, this doesn’t change my status as a Pluralsight instructor. That’s still a large part of my life. Hopefully I’ll get a chance to visit your company some day.

Shameless Appeal for Work

Surely you saw this coming!

If you have any software development projects you think might be a good fit for an intensely focused group of software craftsmen, give us a ring.

Anyway, back to the point that I’m trying to make here. The only way I can learn is by actually doing development work, whether its as big as a two year project or as small as a Code Kata. In order to become a software craftsman someday, I need to practice. Lots and lots of practice.

I also learn a lot from reading books, articles, blog posts, watching screencasts or video recordings from conferences and last but not least by reading code from respectful open-source projects. But in the end, they only sharpen my theoretical skills. In order to really challenge my thoughts, I need to be practicing.

Practice is what makes people craftsmen in other fields as well like surgeons, plumbers, repairmen, etc.. But for some reason, developers think that they can sit back, write code from nine to five and muddle on. While there is a time and place for everything in our lives, this particular attitude makes that the state of our profession can be much compared to the dark ages. We need to become better at what we do and who we are.

Somehow related, I completely agree with this blog post from Uncle Bob where he talks about being responsible for your own career.

YOU, and NO    ONE ELSE, is responsible for your career. Your employer is not responsible for it. You should not depend on your employer to advance your career. You should not depend on your employer to buy you books, it’s great if they do, but it’s not really their responsibility. If they won’t buy them, YOU buy them! It’s not your employers responsibility to teach you a new language. It’s great if they send you to a training course, but if they don’t YOU teach the language to your self!

Every book I’ve ever read about software development is a book that I bought myself from my own money. All the magazines I’m subscribed to, I pay from my own pocket. I’m responsible for my own learning, and I’m willing to invest whatever it takes to accomplish that. Whenever I want to learn something new, I’m not waiting for my employer to give me an opportunity. I make my own opportunities!

I realize I’m a bit late for the previous Butter’s Monthly Bone. I can only hope that Butters won’t eat me alive .

Application lifecycle management (ALM) regards the process of delivering software as a continuously repeating cycle of inter-related steps: definition, design, development, testing, deployment and management. Each of these steps needs to be carefully monitored and controlled.

Does this sound familiar? It should. This is YAW2QH2DS (Yet Another Way to Quantify How to Deliver Software). This smacks of other big acronyms you may be familiar with like CMMI or *UP.

I don’t mean to trivialize this with curmudgeonly developer attitude. The idea of measuring our organization’s maturity level in the software delivery craft matters. It matters because successful small companies typically get bigger, and the challenge to every one of these organizations is how to stay successful as they struggle with issues of scaling up. It matters because it isn’t good enough to compile and run software. It needs to work well, solve a good problem, and actually be delivered into the hands of users.

Measuring our organization’s mastery of delivering great software is also important for organizations needing to get back to a good solid quality baseline. When things get big quickly without a control mechanism (companies, code bases, my belly, etc.) they trend toward entropy. ALM maturity can help provide that control mechanism.

Don’t take that the wrong way. It am not saying, "Let’s use a manager’s tool to measure and manipulate those pesky developers."

Quite the opposite, what I am really saying is closer to, "Imagine never having to explain to management that unit tests are a good thing and worth the effort."

If we have a common reference for measuring our collective skills, we can agree collectively that we can improve in certain areas.

What if (brace yourself) the framework itself (the one your CIO bought off on) required that unit tests, measured code coverage, automated builds, and automated testing were present in your delivery cycle on order to be level 2? Now we’re cooking with a little more gas, eh?

Microsoft and ALM

So, guess what? Microsoft makes tools for software developers. Big news, but there are lots of tools that others in your organization use to complete the delivery cycle: System Center, MS Project, Project Server, Portfolio Server, etc. These are the tools used by people in your company up and down stream of developers in the delivery lifecycle. Go ahead and resent them, but wouldn’t it be nice if these things were used well and worked more cohesively with your tools?

There isn’t a terribly cohesive story when flowing things between these tools (phases of the ALM cycle) but they are getting there. The real value here should be:

• Tools that are frictionless to their primary users.
• Tools optimized for the specialist using them. Whether this is developers, project managers, program managers, IT helpdesk, system administrators, developers, or testers.
• Tools that seamlessly integrate, allowing passing the products of these tools between each other.

Obviously, Microsoft has a strong story for these tools as individual solutions. In the last few years, Microsoft tools have actually started to integrate more easily and this is why. Integrating them up and down stream to complete the ALM story will be a significant effort going forward. The Visual Studio Team System story is a particularly strong start for Microsoft in pursuing an integrated ALM line. The effort is underway to integrate the ALM story across all disciplines.

It’s Not Just a Tool Story

"Great," you’re thinking. So this is a part of world domination through tooling? Not exactly. The fact is that the tools themselves are being built these days to embrace many different processes or methodologies (read TFS Process Templates here). Project Management tooling is certainly due for an overhaul, but System Center has some shiny newness that is heading in the right direction.

As long as the base tools themselves continue supporting extensibility hooks, the community should be able to plug and play as desired. The key will be in getting full integration supported in the community tools. As an example, we really should put in the hooks for nUnit to integrate with Team Build for integrated reporting.

The bottom line here is the tools are getting more extensible along the stack as well. This means that we should be able to support any wonderful, decrepit, promising, or ill-advised silver-bullet process or technique that comes along. "Now don’t that make you sweat chickens", my dad would say.

The ALM Maturity Model

So what about the model itself? Exactly what is this all about?

The basic ALM model endorsed by Microsoft includes the following Practice Areas.

• User Experience (UX)
• Requirements Management
• Quality & Test
• Code Quality
• Architecture & Design
• Project Management
• Software Configuration Management
• Deployment & Operations
• Data Management

What I like about these areas is that it doesn’t really matter whether you are a waterfall-driven Inicorp Employee or dyed-in-the-wool Agilista, these Practice Areas can typically be agreed upon as important. We can also all agree that being mature (read: competent) in these areas is important.

How mature are you? Microsoft provides an online survey for evaluating the ALM maturity in your organization where you can see a measured range of maturity for each Practice Area and specific competencies within each area.

Think about the questions you would ask to gauge competency in these Practice Areas. I was surprised to learn that the online survey asked many of the same questions I would have asked. Nice.

So?

So, what’s the big deal and why is this different? I find a couple of things interesting.

• Several tool vendors are embracing similar ALM models, not just MSFT.
• CMMI is so 8 years ago.
• It’s not about tools. It is about tools that support the business we need to do.
• There’s a boatload of money coming behind this. Your executives will hear about this. This ALM TLA will come up in a meeting.
• This framework actually embraces, rather than eschews, Agile Software Development practices. Seriously.
• It gives your department lead something to brag about when you write unit test (don’t undervalue this one).

This has a chance. This has a chance to actually improve the craft and to improve the bottom line at the same time, and that’s a powerful combination.

My default recommendation is to do a clean, fresh, manual import rather than to migrate source code with existing structure. I have several reasons for this including:

• Code migration is more complicated and it will take longer (cost more).
• Tools have flaws. Everything may not turn out the way you think it will when you have been branching and labeling in that old system for 6 years.
• The majority of code file comparisons occur at the tail end of source control. Very rarely is a comparison made on a code file in SCC older than 60 days.
• The reason you want to retain history is to blame that guy.
• Your branching model was probably over complicated anyway.
• History for auditing purposes can be found in the old system, kept online and read-only for a year or two if necessary.

But the number one reason I don’t want to bring the source code over in the same model is because this is a golden opportunity to improve.

It amazes me that the structure of a SCC system reflects the nature of the organization that created it. I have learned, however, that it does. Are management decisions hectic? Are releases going out buggy? Look for lots of deep branching structures. Are developers working in separate branches on the same release? Look for lots of cherry pick merges.

It is a fundamentally healthy exercise to pull a large pile of source code out of the old system and bring it into the new one one project at a time, ensuring that each one is self contained. In other words, break the dependencies between projects and all of those weird references to resources outside the boundary of the solution.

It comes down to this, why are you making this tooling change in the first place? Odds are that the tool change is being done because the team wants things to get better. Whether you are moving to Team System, SVN, or something else, you are moving to a new system to make an improvement. Given the desire to improve, take advantage of the opportunity to actually make things better rather than to persist old dysfunctions into a shiny new tool.

As a manager of development teams myself, I found great value in migrating source control every 2 years or so, just to cause such a spring cleaning event.

And the number one thing you can do to make this a true Kaizen event? Ensure that each and every project (that is, every *.*proj file) gets build built via a CI build before adding another project to the system.