Jan 21, 2015

Large scale software development

software, scale, agile

This is not necessarily fully baked but I decided to pst it anyway before it becomes another perennial draft that hangs around and by the time it get posted it looses all relevance. So here goes, please comment if you have feelings on this one way or another.

Ever since I watched Brandon’s talk on scaling Agile to the enterprise I was left thinking what could we try to really get that show rolling? It seems that we need ideas so radical, so ground breaking that it will just turn the way we develop software in large organizations on it’s head.

##It’s already happening

Thinking about this open source immediately springs to mind. We already see large scale software development happening. We see great projects with outstanding code quality and thriving communities building some pretty amazing things. So looking at GitHub and SourceForge, Codeplex - Microsoft seems to very sensitive to the power of open source lately - what is that we can learn?

We already know that effective teams are self organizing. We can see this in action across various projects that are taking shape out there in the open source community. How can we take some of the lessons learned from there and apply it to the enterprise?

##Sustainment? What do you do on your spare time?

In large organizations there are teams actively developing software and others that are maintaining it - this is one of the most common anti patterns I’ve noticed. This is absurd - the team that originally build the software is completely disconnected from the feedback loop once the software is in production and the customer is actively using it. As far as they are concerned going to production is the end of the road. Thus, we loose a lot of valuable lessons around what works in production, what kind of code is easy to maintain, how to manage infrastructure and make it work well with the software that is running on top of it.

These teams lose sight of how to maintain software and the kind of code that lends itself to painless change and upkeep.

##Work on whatever you want

Imagine for a minute that you worked in an organization where you could join whatever project you wanted. There is a directory of projects with a description and open issues/a road map or whatever. You don’t have to work on the same project all week, you can just pick and chose what you work on commit your changes move to the next thing. Or, you could spend all of your time (maybe up to a max of 80%) on this super interesting project. You don’t even have to do development if you don’t want to - you can do some QA or BA work. It’s all good.

I know it sounds a little crazy but it might be a good way to keep your dev teams involved and up to date. I for one would love the ability to do some BA work or QA so that I gain some more hands on experience in other software development related roles.

##Start small

Ok, probably not everyone if ready to do that. But what if we tried it with a few projects at first? Some of the smaller initiatives, fringe projects at first and see if we can get critical mass and expand to other areas.

##Trust me

This won’t happen without trust. In most large organizations I’ve been engaged with there’s an apparent lack of trust in the front line people. They need to be empowered to make decisions if this is going to happen. You need to trust them to so the right thing.

##Polyglot developers and jacks of all trades wanted!

Implementing a project like this requires your developers to be comfortable with multiple languages. They need to be able to switch from C# to Javascript or Ruby - even CSS and HTML and be effective. Along with these different languages come different eco systems and established workflows. I think cross pollination here will lead to new ways of doing things and potentially some serious innovation.