devopsy.kinsta.cloud

Category: Features

‘Tis the season to up your speaking game

Well it’s football season in the US, that means Fall is here. It also means that we are coming up to conference season. No matter what segment of the IT market you live in, there are probably a slew of conferences both local and national/international vying for your attention and attendance. For the overwhelming majority of attendees, going to a conference means watching and listening to others speak on topics of interest. Maybe this is the year you should really up your game by speaking!

This was driven home for me last week when I was speaking with the IBM DevOps team. We were discussing how plans for IBM’s InterConnect 2016 conference were coming along. The call for speakers for this major event is open until September 25^th. The IBM team was very pleased that the DevOps stream is tracking among the leading topics for submissions for InterConnect 2016.

That is really quite a feat when you consider the scope and scale of the event. InterConnect 2016 is IBM’s Premier Cloud and Mobile event, February 21-25 in Las Vegas, and is expected to draw over 20,000 attendees, delivering 2,500 sessions, workshops and labs in 10 major topic areas – including DevOps – and infinite networking opportunities. But it also speaks to both the popularity of DevOps in general and IBM’s focus on it in particular. In fact, the DevOps stream covers key DevOps adoption paths: Plan, Develop, Test, Release and Deploy, and Operate. There is a track specifically focused on transforming application delivery with DevOps, and another track called DevOps for Enterprise Systems that will focus on topics related to continuous delivery for two-speed IT including z Systems and Power Systems. There are other streams such as App Platform, Hybrid Cloud, Mobile and Security where DevOps topics will appear. Each track is packed with quality client success stories, technical deep dives, labs, meet-the-expert panels, interactive workshops and more. What’s nice is the sessions are tagged for interest for management and techies and for skill-level. There is a ton of content.

To find out more join me and 14 great DevOps leaders on the crowd chat DevOps: Code, Culture & Community on September 22, 2015 @ 1pm eastern time (60 minutes). You can visit https://www.crowdchat.net/ibminterconnect2016 to add to your calendar or follow along on Twitter #ibminterconnect2016.

So what does this mean to you? It means that there are still some great slots available to share your DevOps skills, lessons and experience with the world. Having spoken at numerous events over the years, I can tell you that participating as a speaker in an event brings a completely new level of learning and understanding. It is also a great way to meet your peers, other speakers and attendees and expand your own network.

What should you talk about? That is probably the biggest obstacle for many people submitting to speak. Randy Newell, Director, DevOps Marketing at IBM, commented to me,”highly-rated sessions are typically DevOps journeys told by peers – shared candidly, complete with the successes and the challenges around technology and culture. Transparency and passion, told from the front lines, go a long way.” I feel that you should speak about what you find interesting. If you find it interesting, chances are others will find it interesting as well. Also, when you are speaking about something interesting to you, your passion for the topic will shine through and others will feed from and join in your passion.

In a large show like this, the good news is that with all of the session slots available they have the ability to afford people to explore specific aspects of a subject that might not be available at a smaller event.

If IBM’s InterConnect is not the event that you choose to share your thoughts and ideas with the world, that is OK too. Pick another event and submit to speak there.

Of course speaking at conferences like InterConnect is a great career move, raising your stature and visibility among your peers. But beyond your own personal benefit, it really benefits the whole community. The best way for us to learn is to share our experiences and stimulate the discussion.

I realize that some of you reading this may still be hesitant to take the plunge and submit to speak. If that is your final decision, of course that is OK, too. You can still be an active participant in sessions by asking questions, joining the conversation. Don’t be a passive conference attendee. You get out of these conferences what you put into them.

As for me, I have two or three different speaking topics that I am submitting this week. Some are panels where I will be with key DevOps thought leaders and influencers who are also my colleagues to discuss key trends defining the future of DevOps. Panels are a great way to get your feet wet with speaking at events, btw.

So what are you going to do? Share your lessons learned, explore new frontiers, advance the state-of-the-art. Call for papers for IBM InterConnect 2016 is ending on September 25^th. Don’t miss the opportunity to up your game by speaking at the biggest DevOps event of the year! Submit to speak at IBM InterConnect 2016 today. http://www.ibm.com/cloud-computing/us/en/interconnect/

September 17, 2015
DOES15 – A Focus on DevOps Execution

“I recently attended my second DevOpsDays, and even one year later I noticed that the audience had changed a lot” – says Travis Cunningham a Software Engineer at SmartFile during an interview about their development environment. What Travis is speaking to is the fact that DevOps has matured dramatically in a short amount of time. Around two years ago the community was a members only club. It consisted of the innovators, and smaller organizations who could adopt DevOps in one fell swoop. But now the benefits of DevOps are shared objectives for most organizations.

(more…)

September 16, 2015
The Third “S” To A Successful App: Street Smarts

We have discussed how scalability and simplicity are leading factors to an app’s success, but in addition to having a strong coding skill set, developers need street smarts, or knowledge of the state of the market and of themselves. Why? Because an app is unlikely to reach its full potential and achieve success without the developer knowing their strengths and what markets to build for. That is the third “S” to successful app.

Know Your Strengths

A key characteristic developers need to know is their strengths. People are always coming up with new ways of doing things, and it is easy to get caught up in the latest programming language or new database technology. While new tools can be helpful and support your development initiatives, it can also be time consuming to learn how to use them. When you have a great idea, stick with your strengths and build a product you know will work, without losing time.

Identifying strengths also applies to choosing which platform to develop for. The language or platform you are strongest at or have a specific preference for should be used for at least the first version because it will allow you to make iterations more quickly.

With strengths come weaknesses, and it is important to be able to identify those as well. For example, sometimes a developer is unable to go out into the field to gather user feedback. When this is the case, it may be wise to look into bringing in a market expert. This is an individual who is an industry expert in a certain marketplace; ideally for a market that you have an app idea for. By bringing in a market expert, you’re able to marry your coding skills to their market knowledge to gain deep industry knowledge of the marketplace while allowing the developer to focus on building something great.

Market Validation

Whether a specific market expert is brought in or not, a good app developer should realize the importance of user feedback immediately. More often than not, a developer will have an idea for an app and go into a code trance, where they start hacking and building code but does not take the time to develop a long-term plan for their vision. Building an app without market validation can be very risky, as developers want to get into the code but fail to take a step back to identify what they can use to validate the need for their app.

AppSumo, an app that offers bundles of software for discounts, started out with a very lean model where the developers would manually input website traffic data into a spreadsheet and then analyze the purchasing behavior of their target audience. AppSumo had no code written at all, but this manual data input allowed them to validate the need and demand for their product. Because of this initial research, when they started writing their code, the team knew the app would be valuable.

Ship Imperfect Products

Once you have market validation, you’re ready to build and eventually ship your product. It’s important to know where to cut corners in the beginning so you can ship product as soon as possible, and also knowing where you can’t to ensure you’re shipping a quality product. This is ultimately the hardest facet of management: knowing how much tech debt to accrue and when to pay it off.

In the case of a brand new app, it may be best to accrue tech debt and solve it at another time because shipping a perfect product that no one uses means you’ve essentially wasted precious time. Willingness to failure is critical to success. It is rare to release an app that has perfect product fit, that perfection comes from rounds of testing and versions. Therefore, a key component of developer street smarts is a willingness to ship imperfect product.

Final Thoughts

Gaining effective developer street smarts means interacting with other developers to learn their perspectives and gain their knowledge. Sharing stories, asking questions and challenging yourself are all a part of becoming a better developer. This means taking some time off-screen and going to meetups, listening to talks and elevating your skills by learning new things. You’re also growing your professional network which increases opportunities for your business and your personal brand. These opportunities begin through the online channels with research, but getting out in the world and making face-to-face connections is invaluable for becoming a better developer and creating the best apps.

September 11, 2015
Chef raises $40m and a full house
Big news today from Chef who announced a $40m Series E round of financing. This round and its size is indicative of the continued high demand of DevOps in general and for a leader in the space like Chef. The round was led by DFJ Growth. Existing investors Battery Ventures, Citi Ventures, DFJ (venture), Ignition Partners, and ScaleVP also participated. Other noteworthy new investors in this round are: Millennium Technology Value Partners & Hewlett Packard Ventures (as a strategic investment).

I had a chance to speak with Barry Crist, CEO, Chef. Of course Barry was very excited about the raise (what CEO wouldn’t be) but what really made an impression on me is that Crist was excited on several levels about this announcement:
1. While Chef didn’t need the capital right now, as Crist says, “the best time to raise money is when you don’t need it.”, The money came at a time when the global market for DevOps is exploding and Chef is exerting its leadership in taking DevOps to the mainstream. With more than half of the Fortune 50 using Chef, 80 percent of Chef’s exponentially growing revenue comes from enterprise businesses.
2. Chef has scored a rare double of both DFJ Growth and DFJ Venture investing in Chef. Having both arms of the well known investment house among Chef’s investors is both a testament to how much they value Chef and how well Chef has performed to date.
3. The strategic investment by HP Ventures represents one aspect of a deep and growing relationship between HP and Chef. HP is poised to be a strategic partner bringing Chef to its large world-wide channel. This investment speaks volume about HP’s commitment to this relationship.
4. A full house for Chef. With the HP investment, Chef now has deep strategic relationships with Microsoft, AWS, IBM and HP. This represents a “full house” of major technology partners and bodes well for Chef to continue its dominance as the leader in DevOps automation.
This was a series E round for Chef and I did not ask Crist what type of valuation this money was raised at. But one of the nice things about raising money when you don’t have to is that generally you can afford to be a little pickier and get better valuations when you raise money.

I had a chance to speak with Crist about his outlook on the VC and investment market. With many voices chiming in that we might be seeing a dip in investment and valuations in the tech market, Crist said he didn’t have a crystal ball. But all the more reason to raise this money now. If the market does turn those with cash in the bank and dry powder will be in the cat bird seat to leverage their capital for strategic purposes. We might very well see Chef as an acquirer of technologies to tuck in as they continue to grow.

In the meantime, a rising tide will lift all boats. This kind of investment and buzz in one of the DevOps market leaders should help other DevOps companies in their own capital raising activities. While few may achieve the heights that Chef is rising too, there is lots of room in the market for DevOps companies of all shapes and sizes.

Congratulations to Barry and the rest of the Chef team on this raise and looking forward to see what the future holds.
September 9, 2015
The Sea Change that is DevOps – DevOps is changing tools and infrastructure as we know it: Part 2

In the first part of this series, I explored the factors that have lead DevOps to where it is today. From a three to six month deployment period to regular weekly (or even daily) deployments, DevOps has certainly changed the IT landscape as we know it. Now, with the growing adoption of a DevOps mindset, the IT world is seeing a huge growth in software companies created specifically for DevOps professionals.

The explosion of monitoring tools and evolution of the software engineer role

With the added complexity of SaaS software and the rapid innovation of the platform, issues occur more frequently. With the adoption of unified cloud infrastructures more and more of these issues are application layer in nature. Service providers like Amazon are now consuming the need for foundational monitoring from tools such as Nagios at the IaaS (Infrastructure-as-a-Service) layer. Today, problems are popping up at a higher level in the stack and, monitored by tools such as NewRelic, that output is directly destined for software engineers. The ability to know if something is working correctly is now a comparative operation performed by the engineers who wrote the software.

The changing landscape of the NOC

If getting software built and into production was the nirvana that everyone had been marching toward, the NOC (Network Operations Center) was the manual switchboard of the past standing right in the way.

Traditionally, the NOC has been the catchall command center for people who monitor the systems that monitor the software. NOCs were designed to be the first line of defense against technical problems, customer problems, and general communication of issues to the wider company. Historically, NOCs have had an infrastructure bias as the software higher in the stack changed less often. But as the true infrastructure layer of SaaS companies began to move away from the company and into IaaS platforms, that need was receding. At the same time, as application deployments were increasing in frequency, often first responders that were not highly technical were adding drag in system resolution times.

Today, companies are looking for ways to direct problems straight to the “makers” that created that component of software in the first place. With the speed of SaaS businesses, the company can no longer afford for the first responder to be anyone other than the person or group that created the logic in the first place.

If the NOC of the past had two critical functions, solving technical problems fast and communicating with internal and external stakeholders, suddenly half of their charter was starting to fail dramatically. This led to the explosion of software like VictorOps and monitoring tools like New Relic and AppDynamics to help diagnose these problems quickly.

Operations is dead, long live DevOps

In all this time a lot of things have changed for operations people. While a technical operations manager in the past might hire system admins to do all the manual configurations, now they are looking for team members with coding skills. While understanding hardware was a requirement in the past, now suddenly virtual servers that you can rent from Amazon, Rackspace or any of 30 other IaaS providers can be created (spun up) in an instant with no knowledge of hardware at all. In the past a system admin had little to no knowledge of how the application software worked, but now that is their primary job description. In short, today you want to hire a software developer of a different skill set – one that codes the infrastructure and understands the application. While the NOC was once your first line of defense against system problems, now the team that wrote the software is the only defense necessary for technical matters.

For many, the end game has been realized

Now, for more progressive companies, the big gain has been realized. After literally a decade of innovation, for the first time it is easier to fix a production problem in-stage, rebuild and redeploy (all automatically) than it would be to fix the problem in production. Today the reality of being able to execute an Agile development sprint front to back is possible.

September 8, 2015
Come to DevOps Connect: CD Summit in Austin, October 8th with Jez Humble

Here at devopsy.kinsta.cloud we are very happy to announce that we are teaming up with Prospera Events (producers of the InnoTech Conferences), CloudBees, the enterprise Jenkins company and IBM to bring a DevOps Connect: CD Summit to Austin, Texas on October 8, 2015. The event will be held at the Austin Convention Center as part of the InnoTech Austin Conference. Full details can be found here.

The event will be headlined by renowned author and Continuous Delivery/DevOps expert Jez Humble. Jez will speak about architecting CD. Additional keynotes will be by Andy Pemberton of CloudBees and IBM. Additional topics will be covered in two separate tracks, one technical and one business related. Additional speakers in the tracks include DevOps pioneer Ernest Mueller, of the Agile Admin and Boyd Hemphill who will speak on “HomeOps”.

In addition to lunch and an after conference reception, CD Summit attendees will join with and have full access to the InnoTech Conference taking place at the same time. An expo floor of exhibitors will include a demo theater to showcase some of the leading apps and technologies in DevOps. Among these IBM will demonstrate Bluemix, its market leading cloud application development platform.

Attendance for DevOps Connect: CD Summit requires a separate $99 admission which includes InnoTech admission too. There are sponsorships available as well. More information is available on the DevOpsConnect site.

Besides the Austin event, additional CD Summit events are scheduled for December 3rd in Los Angeles and later in December in Boston. Further details on these events will be announced shortly.

September 4, 2015
Test-Driven Development (TDD) Drives Smart Developers at Smartling

Supporting Swift Cyber Business Ramp Ups Around the World with Translation and Localization Sped by CD

Smartling technology enables the business to quickly translate content in websites, apps, and documents into any language in the world. “We streamline all the non-linguistic work associated with the translation,” says Andrey Akselrod, CTO / Co-Founder, Smartling, a translation management platform provider for localization anywhere, globally. Using the Smartling platform, companies upload content, making it instantly accessible by a Smartling translator partner or a translator that the company acquires independently.

I viewed the Smartling demo and I can tell you that the platform offers many innate, seamless, intuitive abilities. Briefly, it allows the translator to largely automate translation, localization, and content re-use and editing against a backdrop of how it will appear on a website, in an app, and in electronic documents. The platform includes workflow automations to speed translation along to the next stage in the project. “This allows for a reduction in complexity, cost, and time for the translation process, without sacrificing the high-quality translation that only a human can do,” says Akselrod.

The TDD Testing Secret Sauce

Smartling developers first write automated regression tests for the code they are about to create. Then they confidently code their software knowing how the tests will challenge the code because they wrote the tests themselves AND did so before they wrote the new feature or innovation. This process accelerates development because the programmers write the code knowing what it takes to ensure that it won’t break anything. This enables Smartling to deploy live code as many as ten times per day, according to Akselrod.

Test-Driven Development (TDD) saves on refactoring and validates the tests. Smartling discovered this when certain test and development issues disappeared after they moved to TDD. When you code the tests after writing the software that you need to test, you may have to refactor your code so that it is suitable for testing. “You find yourself in a position of doing refactoring without tests to validate that the code still works,” says Akselrod. There’s an old carpenter’s saying that you should “measure twice and cut once” to make sure you don’t waste what you cut or have to cut again. But this sounds like the reverse, expecting the coder to cut (code) twice and then measure. The absurdity in that is self-evident.

Developers who must create tests after they innovate their software don’t test whether the tests could fail. “This results in low-quality tests. We’ve discovered this the hard way—we had pretty good test coverage, but a number of bugs in the code base led us to discover that our tests were failing,” says Akselrod. TDD resolved all this, saving time, energy, and investment, and satisfying customers.

Though these automated tests run much faster than manual regression tests do, Smartling gauges test performance over time and refines testing efficiencies to ensure that tests keep pace with accelerating deployments. “We distribute test execution among multiple servers to make sure that the tests run as quickly as possible,” says Akselrod.

Can Get Enough of That TDD

Developers find themselves obsessed with the TDD development process for the prompt props they receive as they deploy code directly rather than wait to see it run successfully. “TDD makes for quick customer feedback. Customers are thrilled because we react to their requests quickly. This fosters an exciting and fulfilling conversation between developers and customers,” adds Akselrod.

TDD’s competitive advantage wets the appetite for market penetration. TDD moves Smartling through the OODA decision cycle at an accelerated rate. “Modern software development cycles through an OODA loop such that developers Observe, Orient, Decide, and Act. If your OODA loop is faster than your competitor’s is, you win,” says Akselrod. TDD enables Smartling to rapidly deploy, respond to the customer base, and instantiate innovations, expediting aggressive market growth.

Results

Customers are seizing the benefits that savvy platform provider Smartling serves. As this throng of growing businesses increasingly hitches its wagons to Smartling, Smartling in turn sees three-billion page views per month in traffic flowing through its Global Delivery Network of translated dynamic pages, according to Akselrod. No matter how you slice it, three-billion is a number you simply cannot explain away.

September 3, 2015
Where will DevOps be in 10 years’ time?

What will the DevOps landscape look like in 10 years’ time? Ten years ago, Agile was seen as new and different. Now it’s part of everyday life of most developers. Will it be the same with DevOps? It’s time to clasp the crystal ball and unravel where the future is headed.

First things first. DevOps is here to stay. The overwhelming trend towards the digitization of services accelerates the need for agility and shorter release cycles with DevOps as an invaluable building brick: think the Uber vehicle booking service, the Airbnb property rental service—even Amazon’s move to take the terrestrial version of Top Gear and launch it as a digital-only, on-demand broadcast service. Services are going digital. And so are companies: banks, retailers, telcos and others are increasingly positioned as software-driven businesses where IT makes the difference.

These organizations will need to develop and deliver compelling, customer-centric apps quicker than ever before. Agile development will become the battle cry of every business. Dev and Operations teams will increasingly need to shake hands in a middle ground of rapid development and reliable, high performance services delivery.

At a technical level, DevOps enablement will be driven by increased public and private cloud adoption: Infrastructure, Platform and Application Service Clouds are all important enablers for DevOps practices. Moreover, DevOps will also grow through the replacement of IT Operations Management tool chains – including automation, monitoring and service management – from non-DevOps to DevOps-enabled and DevOps-ready tools.

If agile is a journey, DevOps can be seen just as another part of it; one, that suits companies, which successfully completed the first phases of agile transformation and are now looking at ways to further enhance their agile maturity levels and accelerate releases. The increased adoption of agile development methodologies and the increase of related maturity levels thus will also fuel growth. Gartner, for example, has indicated that agile development is essential for mobile application development, arguing that the traditional methods used to define and develop desktop applications will not work with mobile application development.

Still not convinced? Then how about this. Research by Computing in the UK shows that 30% of 300 organizations surveyed in the run up to the 2015 DevOps Summit had either started to implement a DevOps strategy or had already merged Dev and Ops, with another 13% planning to go down this route.

Awareness of existing DevOps success will also fuel this continued growth. Recent research, for example, shows that high-performing IT organizations are deploying code 30 times more frequently with 50% fewer failures using DevOps practices. And demand for DevOps skills is soaring too: DevOps engineers are among the highest paid IT practitioners today, according to APM Digest.

Make no mistake, the software delivery chain will continue to accelerate and change cycles will shrink. In many competitive scenarios, an advantage can only be sustained through organizational agility. In fact, agility can make such a competitive advantage sustainable. Since IT is so important already in the “legacy” enterprise and becomes even more so in the digital economy, existing IT systems and methods will need to move towards agile.

Here’s another thought. I predict that within the next 10 years the split of ‘Mode 1’ and ‘Mode 2’ companies will disappear. Mode 1 is the traditional approach to development, emphasizing scalability, efficiency, safety and accuracy. It’s the blueprint for how IT Operations works. Mode 2 meanwhile is non-sequential, emphasizing agility and speed. And it requires new thinking and processes around issues such as investment management, governance and collaboration.

It will disappear for two reasons. First, distinct cultures and operational modes are not sustainable within the same business. Second, if agility is not a requirement, the service should not be operated within the boundaries of the firm for strategic reasons. Own “mode 1” operator companies should be used to outsource non-differentiated IT services.

In due course, bimodal IT will flourish within organizations, servicing two modes of IT, each designed to develop and deliver information- and technology-intensive services in its own way. Success in both modes demands smarter, more flexible tools that support today’s complex IT operations. Bimodal IT is not without its risks and challenges, but it will be increasingly powerful in helping companies meet ever-growing customer expectations. DevOps will help firms help them bridge these two modes.

Market demand for DevOps skills will continue to grow too in the next 10 years. Research indicates that DevOps engineers are among the highest paid IT practitioners today and aggressive hiring of people with DevOps expertise will continue in the years to follow.

One final, more controversial thought. In 10 years’ time, we might not even be talking about DevOps anymore. By then, all stakeholders will understand how to work holistically to achieve business value through the end goal of delivering high quality applications and services to customers. So DevOps might even become redundant. But continuous delivery will be the norm.

September 2, 2015
Vote for the DevOps Dozen

At the end of July we opened up nominations for our inaugural DevOps Dozen, to recognize the top 12 companies in DevOps. Over 1500 of you voted (thank you) selecting from over 120 different companies. We have taken the top vote getters in each category to come up with a list of the final 32 finalists for the DevOps Dozen.

Frankly 32 finalists was more than we were planning on. But so many companies were so closely grouped in the nomination voting that we didn’t feel comfortable selecting one company for the finals and leaving another out.

So now we are opening the final phase of voting to you our readers. Voting will be open for the entire month of September. But you can only vote once. On our DevOps Dozen site most of the finalists have sent us information that they would like you to know before casting your vote. Please take the time to read some of this, especially for companies you may not be familiar with.

The finalists range from open source projects, to cloud service providers, DevOps tools vendors to service providers. When voting you are allowed to select 12 of the 32 as DevOps Dozen winners. So take the time and make your selections carefully.

Just a word about the 32 finalists. Every one of them is already a winner. Having made it past the nominations means that at least 350 of the 1500 people voting voted for them. On top of that if you take the time to check out these companies why they are here is pretty obvious.

So help us recognize excellence in DevOps and vote today!

September 1, 2015
Tomorrow’s News and the Code Lifecycle Automation Imperative

Of course you should’ve known Heinz and Kraft would merge. Of course you should’ve known the Shanghai market would tank. Of course you should’ve known Oliver Stone would make the Snowden movie.

But, of course, you didn’t. None of us did. It just made perfect sense to us after we read the news.

That’s why it’s absolutely imperative that we all automate our code lifecycles.

An Uncertain World

Much of the narrative surrounding DevOps and continuous software delivery makes it sound as if C-suite leaders are omniscient strategists—and IT is the only thing standing in the way between them and market domination. According to this narrative, IT must move faster so the business can execute its awesome plans without technological friction.

This narrative is occasionally accurate. But the deeper truth is that business leaders are human beings operating with incomplete and/or inaccurate information. So they make lots of decisions that circumstances require them to make.

Of course, with Big Data and advanced analytics, we make much better predictions than ever before. We figure out that the customer who just watched “The Big Lebowski” will probably like “Fargo.” And we can stagger the lights on Eighth Avenue more precisely to get Jersey people out of town faster.

But we still can’t predict what Buffett or Bezos will do next. Nor can we be sure how next year’s Presidential election will affect re-admission penalties for healthcare providers. So we have to be ready to change course. Quickly.

Which is exactly what code lifecycle automation lets us do.

Baby, It’s Code Outside

Code, after all, is increasingly how we do things. So if we’re doing things one way and tomorrow’s news requires that we do them some other way, we have to change our code.

But you can’t make that change quickly if you’re stuck with a slow, manual process for capturing new requirements, mapping fulfillment of those requirements to the right team, putting the code they write through the right paces, and releasing it into production.

In fact, given the volatility of digital markets, code that takes too long to release can be obsolete before it gets there.

Or, as may more often be the case, a slow software lifecycle won’t let your LOB executives find out how wrong they were soon enough for them to change course before they do too much damage.

Faster, Smaller Mistakes

Your company may be an exception. Your executives may never get blindsided by a shift in market dynamics or an unexpected regulatory mandate. In that case, a small dose of Agile and a few DevOps best practices will be sufficient to make sure you deliver market-aligned software.

But the rest of us need to make sure we can rescue our business from code that efficiently, reliably, and securely does the terribly wrong thing we told it to do. And then change it again when we read tomorrow’s news.

So we are going to automate.

August 28, 2015