Earlier this week, a really smart architect and I were evaluating various methods for managing software code changes, bug fixes, releases and major features. We both were in agreement with the primary direction, a popular one in nimble companies. Have a primary "trunk" or "master" branch; Any commits to "master" automatically get built and tested and ready for production (and possibly deployed); Any changes occur on "feature branches", temporary parallels streams of development that eventually - hopefully sooner rather than later - merge into "

Is hard return on investment all there is? In exploring business (and tech) projects, we have a tendency to think about the immediate, quantifiable ROI. Yet, there are times when the soft costs or other benefits outweigh any measurable ROI, and sometimes are even worth a negative ROI... in the short term. This was highlighted to me again yesterday. A colleague of mine is heading up a project to move tens of thousands of VMs from on-premise to the public cloud.

I used to hate taking long day flights. If I had to spend 12 hours in the air from New York to Tokyo, or Zurich to Bangkok, or Tel Aviv to Newark, I preferred overnight flights. Even since the advent of on-demand entertainment, personal video screens and portable devices like the iPad, those flights just seemed to last forever. So most of the time I would fly overnight. However, the timing didn't always work out, and overnight flights tend to be significantly more expensive than all-day flights, often much greater than 50% more.

When at the Container Summit, I heard a great (if somewhat perverse) line from Jacob Groundwater of New Relic. I liked it so much, I tweeted it out immediately: If you want people to drive slower, don't give them an airbag; put a spike in their steering wheel! While a rather morbid image, Jacob hit on a core truth: if you make dangerous activities safer, people will do more dangerous things.

Since the dawn of software, more or less, companies wrote their software in a process that went something like this: Product defines the specifications. Architecture designs it. Engineering/R&D builds it. Quality Assurance (QA) tests it. If it passes, it is scheduled for release; if not, goto #3. The jobs of QA teams historically have been procedure-oriented. Whereas engineers tend to be more creative and inventive, QA teams provide the process and constraints (remember the term "

What are the three biggest impediments, or roadblocks, to fast product cycles, especially in the cloud? Incomplete Testing. If you are not 100% confident that your testing covers every known use case, you will be fearful of releasing. Actually, fear of the risk of deployment often is the "canary in the coal mine" sign that your testing is incomplete. The other sign is infrequent releases, defined in the Internet era as less frequently than every few days.

When I went to business school, I worked closely with an incredibly smart woman with whom I shared a very similar method of thinking and mindset. When we would find the same responses to the same questions in the same manner, inevitably I would quote, "great minds think alike." She taught me that there is a corollary: "...but fools rarely differ." The great challenge in life often isn't to agree with someone, no matter how smart; it is to determine if you are both great minds thinking alike, or both fools who are not differing.

In our most recent article, we explored why "true cloud" really matters: it has a significant impact on: Your gross margins Your speed As a company providing technology services, as opposed to products like software, you cannot get cloud-scale gross margins and speed - and therefore valuations - unless you are operating as a true cloud. Today, we will look at a different set of advantages to running your service as a true cloud: how nimble you can be.

In our previous articles, we discussed what cloud is, the types of cloud services, and the difference between true cloud and "market cloud", or hosting. The big question is, so what? You are a software provider offering a cloud solution. Does it really matter if it is "true cloud", or just hosted? Isn't it just a difference in architectural design, a matter for your engineers but not your customers or your bottom line?