Foggy Software

or... what does actually matter in an agile process? The holly grail of any software outfit is: deliver high value, high quality results; consistently and predictably. Talk about a loaded sentence ! but those are the requirements to make a software team  valuable to the business (or is the business). Breaking it down:: Team - A single developer doesn't need process.... And finding a unified process that works a huge conglamorate corp is not likely. A process then is meant for a TEAM of some reasonable size. High value - if you deliver the wrong thing at the right time.... well, I've been at too many (now deceased) startups to recognize that value is key.  High quality - need I say more? If you want to deliver 2.0, but your stuck bug-fixing 1.0 into existence you will have 2 customers - the one that is unhappy with 1.0 and the one waiting for the features in 2.0. Neither would keep the revenue coming in. Results - activities by themselves, with no results, provides littl

Or, here's my pet mini-cloud I first used VMWare workstation as a development tool somewhere around 20003. It was a cost effective way to test the software I was working on against quirks of different operating systems. On one linux desktop I could have all my development tools, including a few Windows95 installations. So, now you're asking - "what does that have to do with  clouds?" Well, no much yet. For my current project ( Crowbar ) I found myself needing a setup that includes: Multiple OS flavors  Win XP for access to corporate resources ubuntu 10.10 and 11.04 - main testing targets Redhat  and Centos - for some dev work and testing Varying numbers of machines, pretty much depending on the day For basic development 3 machines - development, admin node and a target node For swift and nova (components of openstack ) related development - at least 5, sometimes a few more Weird-ish network configurations Network segments to simulate public, pri

Or.. .why do you care about DevOps (and why you want devOps ++) If you've ever written (or tested) a piece of software, you've heard this all before - "but... it works in my setup". That endless back and forth of finger pointing, until way too often, it ends up being some silly environment setting that causes the application or service to miss-behave. DevOps is there to help. No more manual deployment steps to deploy an app. No longer 13 page project plans requiring coordination of at least 5 geo-distributed teams (half of which are in a timezone where the sun has long stopped shining). The DevOps motto is simple - "if it hurts and its dangerous, do it often". The industry has accepted this in the Continuous Integration case - builds that integrate disparate development streams are painful. Assumptions made in isolation prove to be wrong, and whole hell breaks loose when you try to put different, independently developed pieces together. This is a pai