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.
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.
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.
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!
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.
I am unbelievably excited about DevOps Enterprise Summit 2015. As amazing as last year’s event was, it will be even better this year. I wanted to share with you what you can expect this year at the conference and give you a behind-the-scenes look inside the programming committee goals and how they informed the overall conference organization.
The Programming Committee
The programming committee comprises some of my favorite people in the world, and all have made incredible contributions to our field: Adrian Cockcroft (Battery Ventures), Dominica DeGrandis (LeanKit), Cornelia Davis (Pivotal), Damon Edwards (DTO Solutions), Anders Wallgren (Electric Cloud), John Willis (Docker), and advising member Jez Humble (Chef).
As Damon Edwards once quipped, “Over our careers, we’ve all become professional conference attendees, so we have strong opinions on what makes for a great conference.”
The Format of the Conference
The quality of the speakers is a major contributing factor to the success of a conference — after all, why bother spending three days somewhere if there are no remarkable people there in the first place?
The DevOps Enterprise Summit is a three-day conference, featuring 14 keynote sessions and about 36 other sessions in concurrent tracks.
Last year, all talks were 30 minutes, which we thought worked very well. Even though this can be challenging for speakers to put everything into a half-hour, what TED Talks have shown us is that even the most complex ideas can be conveyed in a short amount of time.
As an attendee, I personally love the shorter talks because it allows me to experience many ideas and concepts within a short amount of time.
As a conference organizer, it’s also fantastic, because it allows us to put more speakers on the schedule. This is super important, because there are so many worthy talks that we want to showcase. This year, we had over 220 submissions. I can’t express the amazing quality of the submissions, and we would have accepted more if it were possible.
More Experience Reports
We want to hear the firsthand accounts of DevOps transformation in large, complex organizations, at all stages of the journey, so we structure the conference around experience reports delivered in a very specific form. We ask the experts to tell us about their
organization,
specific business process or application that they were focused on,
problems they experienced, ideally with metrics around deployment lead time,
followed by
what they did about it,
and the business value that was created.
In addition to a whole new batch of experience reports, we’ll be hearing from numerous DOES14 alumni, complete with updates on what has transpired on their journeys over the past year, including Heather Mickman and Ross Clanton from Target, Jason Cox from Disney, Carmen DeArdo from Nationwide, Courtney Kissler from Nordstrom, Tapabrata Pal from Capital One, Terri Potts and Michael W. Smith from Raytheon Software, and Scott Prugh from CSG.
I’m also excited that Ralph Loura and Olivier Jacques from HP will be presenting. As the CIO of HP, Loura serves the needs of over 300,000 employees (and that’s even after the October scheduled split of the company), making them the largest organization to share their story at this conference.
Based on my conversations with these folks, I’m super excited about what they’re going to be sharing, which includes how they’ve accelerated and expanded their DevOps initiatives, new engagement models with the rest of the organizations, the role of leadership, and more.
This year, we will have 35 speakers presenting experience reports, down from last year’s 50. Why? To make room for expert talks.
Amazing Expert Talks in the Top Five Problem Areas
I asked that every speaker at DevOps Enterprise 2014 end with a slide addressing one of the two following titles: “Here’s what I don’t know how to do” or “Here’s what I’m looking for help with.” We wanted a glimpse into what the top problems were that the entire community was facing, which we could then use as a research roadmap.
The top issues stated in 2014 were:
Better strategies and tactics for creating automated tests for legacy applications
Addressing culture and leadership aspects during transforming
Top approaches to organizational design, roles, and responsibilities
Information security and compliance practices
Identifying metrics to best improve performance with DevOps initiatives
This year, we reserved 15 talks specifically to address those areas. On the programming committee, we put our heads together, reached out to many in the DevOps community, and invited the most renowned experts in each area.
I’m extremely excited that some of these expert talks will include the following, where they will share their lessons learned:
Steven Spear from MIT, is one of my personal heroes, credited for “Decoding the DNA Of The Toyota Production System,”[https://hbr.org/1999/09/decoding-the-dna-of-the-toyota-production-system] with H. Kent Bowen. He also helped create the amazing Alcoa management system with their CEO Paul O’Neill.
Elisabeth Hendrickson helped pioneer quality engineering practices for the last twenty years, and is someone who Jez Humble and I have admired for years. She presented last year on “Care and Feeding of Feedback Loops,” has since been promoted to VP of Engineering for Pivotal’s Big Data Suite, and will discuss her journey around creating great engineering organizations with a culture of quality.
Josh Corman is a longtime researcher in information security and John Willis is equally renowned in the DevOps community. They will be presenting their work on software supply chains, immutable infrastructure, and how they both impact DevOps productivity and security.
Ed Bellis was former CISO of Orbitz, and will share his experiences on how information security should ideally integrate into the DevOps value stream and how it impacts compliance and reporting.
Rosalind Radcliffe has made significant contributions to our profession over her entire career as a Distinguished Engineer at IBM, and she’ll be sharing amazing strategies and tactics of how organizations can improve the state of automated testing on mainframes. John Willis says, “From green screens to GUI’s, Tivoli to SOA, then showing up on the DOES 2014 stage presenting on mainframes and Devops at IBM. Unlike most people she is one of those rare individuals that has transcended four decades and always seems to be on the bleeding edge.”
We will have two talks on how automated testing and other DevOps practices were put into practice at famous Yahoo! properties. Neil Manvar, solutions architect at Sauce Labs and former software engineer at Yahoo!, and Chris Riley, founder and DevOps analyst at Fixate.IO will talk about how Yahoo! implemented automated testing for Yahoo! Mail. Automated testing enabled the software quality team to spend more time on important user-facing product code and helped them introduce exciting new strategies for building higher quality apps faster. Jim Stoneham will present on his experiences as the general manager of Yahoo! Communities division in 2009, including his first-hand observations of the Flickr “10 deploys per day” culture, and how many of those practices were replicated in Yahoo! Answers to increase their deployment cadence from once every six weeks to daily deploys.
Representation of Women
One of the other important programming objectives of the conference was to have the composition of speakers match the technology community population as a whole, especially around representation of women and minorities.
Last year, we were pleased that 41% of speakers were women. The complete roster of speakers is still being finalized, but we’re hoping to match or exceed that number this year.
We received much positive feedback about the representation of women at last year’s conference.
See the Speakers in Action
In short, I have never learned as much as I did in any three days than at DevOps Enterprise Summit 2014. They were some of the most courageous and exciting transformation stories I had ever seen, and this year’s conference is going to be even better. I hope you’ll agree that we have an amazing conference in store for you at DevOps Enterprise Summit 2015! I look forward to seeing you there!
To see some of the speakers in action and learn about what you’ll experience at DevOps Enterprise Summit 2015, go here:
DevOps tools and principles have dramatically increased the pace of innovation and enabled the organizations that have embraced them and used them most effectively to achieve a major strategic advantage over competitors. The more the world runs and relies on software, the more DevOps can be the engine to automate and facilitate change.
There was a time it took almost half a day to build a single car. Henry Ford managed to bring that down to two hours and 30 minutes thanks to the assembly line, but for over a hundred years most of the changes year to year in automobiles have required retooling manufacturing plants so updates and modifications are developed at a relative snail’s pace. Then Tesla came along with a car that is more or less just a framework for the software that runs on it and that can have new features and capabilities the next day through over-the-air software updates.
John Jeremiah, technology evangelist and team lead for HP Software, was quoted in a post earlier this year saying, “It was just a few years ago when nobody had heard of Uber. Now, every single taxi company or taxi service is under pressure to react to a company that owns no taxis. Why is that? It’s because they’ve used software.”
Tesla has an advantage over other automobiles because it can change the way its vehicles work or improve them with new features at the push of a button. Uber has an advantage over the traditional taxi industry because it has streamlined its service through a mobile app available on hundreds of millions of mobile devices and it can modify and improve the way it works with a simple update. Software has increased the ability for organizations to adapt more quickly and DevOps accelerates that evolution even faster through continuous innovation and the automation of routine tasks.
There will still be things that require physical change—an updated vehicle frame in the case of Tesla or a new feature that relies on cutting edge technology only available in the latest smartphone models in the case of Uber. Software alone can’t do it all.
The areas where software makes a difference, though, DevOps has a major impact. A recent study conducted by Gene Kim and a team of researchers found that organizations that have embraced DevOps tools and principles effectively have 8,000 times faster lead times and 30 times more frequent deployments than their peers. They also have 12 times faster mean time to recovery when issues arise and are twice as likely to exceed profitability, market share and productivity goals. Those are all significant statistics that impact the bottom line and separate the companies that win from their struggling rivals.
Companies that can harness the power of DevOps and continuous innovation to develop new apps and capabilities faster and that have the capacity to push those updates out to existing customers have a significant advantage over competitors still slogging through “innovating” the old-fashioned way. It’s hard to compete with companies that are deploying 30 times faster than you and have twice the profitability and market share.
devopsy.kinsta.cloud spoke with Sacha Labourey, CEO, CloudBees about the upcoming Jenkins User Conference, its value, purpose, and focus, and about CD. It’s fitting coming into the JUC to highlight Mr. Labourey’s recent accomplishments. “Last year, we announced the Jenkins workflow, so the ability to build pipelines to create Continuous Delivery environments,” says Labourey. Noting Jenkins’ focus heretofore on CI and the notion of single jobs, Labourey offered that CI was not sophisticated enough to build those pipelines. “So the workflow enabling CD is receiving a lot of attention from the community and customers,” concludes Labourey.
Moving on to more recent news, Labourey agrees that Jenkins’ support now for Docker is leading the community to consider how it can better leverage Docker. “Or, if they are already using Docker, they want to see how they can streamline the process by which they are going to build those images, register those, test them and so on,” says Labourey. These developments are key to understanding what customers and the DevOps-minded community will likely bring to the JUC, and what they can hope to take away from it.
Great Expectations
Labourey has great expectations for the JUC. “First, it’s a nice party. A lot of those people discuss together at the forums or through other means and that’s a great way to connect,” says Labourey. The JUC will be one big multi-topic Jenkins / CD conversation between and among attendees and presenters. There’s something to be said for face-to-face meetings despite the many unified communications channels and presence technologies available today for remote exchanges, collaborations, and white boarding.
Second, and if the Washington and London Jenkins UCs are any clue, the Santa Clara Conference will see more of what Labourey calls “traditional companies” sending teams to this event to learn new Jenkins features, how other companies applied best practices to solve problems, and what did and did not work for them.
Addressing the Community: the State of CI &CD
devopsy.kinsta.cloud specifically asked Mr. Labourey if as we come into the conference he would briefly address the state of CI & CD. Labourey details the changing Jenkins audience and what waits in store for them.
“The historical users of Jenkins can have a pretty strong focus on Continuous Integration. That’s how the project was born. That’s how it became successful. I think we are seeing a new wave of users now, a fresh wave coming from a Continuous Delivery standpoint looking at the full lifecycle rather than just the development section of it. Sometimes I feel like Jenkins CI is the wrong name. It should be Jenkins CD now because Jenkins CI sends the wrong message. I hope a lot of people can spend quality time thinking about that and educating themselves about those new features because they’re not just new features. It’s Jenkins tomorrow. It’s really the problems that Jenkins will have to solve tomorrow. It’s like a new era for the Jenkins project. I really hope that people attending the conference can realize this.” – Sacha Labourey, CEO, CloudBees.
The JUC keynote and events will mirror Labourey’s statement in that the content, especially the presentations will include real use cases with innovative deployments and CD as well as technical discussions of how to master new features. “We see that people attending for their second year have done some quality work with Jenkins within their companies. They come back to present their experience in the form of a company use case or some extensions they’ve created,” says Labourey.
A Vision for Jenkins and CD
“It’s very important for everybody to realize the success of their company and also the success of Jenkins itself will happen if everybody makes the transition to CD and understands it,” says Labourey. Labourey sees the JUC sessions as covering the new tools that make Jenkins the leader of CD. The JUC committee carefully selected presenters and topics in order to target that goal.
And since not everyone can attend a JUC, says Labourey, CloudBees as a company will be hiring people that will be much more active in educating the Jenkins community about this new era of Jenkins.
As a freelance consultant for more than 15 years I skip from company to company of different sizes in different industries. For the last two years I have been very close to the IT-tech industry. I love to work with the “Nerds” and “Geeks” and I like the atmosphere on the devopsdays I have attended. But I am really confused about one important problem, which never ever occurred to me in this big mass before than it does in the tech industry: problems with health, psychosomatic disorders and mental illnesses.
Whenever I talk with some of the tech folk, sooner or later hints of these problems appear and with asking the right questions, lots of people start talking about their problems in the past. They talk about back problems, a lot of headaches and neck tensions. At first glance this seem to be very clear because of bad body posture combined with a lack of physical activity and perhaps bad nutrition. But the roots for these problems can also be psychosomatically. These are by the way just the “light problems”.
So many people told me about their burnouts, depression and other mental illnesses; they have also told me about being “out of job” for a year or more! And they have talked about the need for liters of coffee to get through the day, caffeine pills, energy-drinks and cigarettes! At devopsdays Amsterdam @botchagalupe talked about some talented and enthusiastic young techs and their Karo jisatsu – their suicide from overwork!
My job in companies is to coach employees and leaders on topics like communication, team culture and leadership. And with these topics the question of well-being is always involved. So when I started with my first clients in the IT industry I did a lot of research and I found some studies about health problems in Germany. These studies said that tech people do not often stay at home because of common colds or something like that. But it told that there are above average problems in matters of nervousness, insomnia, stomach problems, mood swings, depressions and burnout. And there is an extremely outstanding usage of anti-depressants and other psychotropic drugs.
There are other studies about pharmacological neuroenhancement and brain doping – the consumption of drugs to increase the “brain power” without medical necessity – which are frightening to me.
What really puzzles me about this is, that all the people talk about colleagues with some kind of these problems or about their own experiences; that they know about it – and then they go on and “do business as usual” – nothing happens!
Like a neon sign there is one big question in my head: Who really cares about well-being in tech?
But why are there that many health problems in the IT-industry? On the one hand it is because of the nature of IT: faster and better is the credo of IT-projects. Continuous or daily delivery put a lot of pressure on the employees. Management systems like Scrum or Kanban and methodologies like Devops try to meet the requirements of the market. But are the single individuals really fit for it? What is done to enable the employees to meet these systems or methodologies on eye-level so that they feel well with it?
Special management systems and methodologies need special skills – technical skills as well as soft skills. The companies´ focus is a lot on technical skill education, but mostly they don´t care about strengthening the soft skills! Employees are left alone with issues of bad communication, misunderstandings in the team, leadership full of pressure and – caused by this all: bad emotions and feelings!
Now let´s have a look at the people working in the IT industry! One big skill, you really need to work successfully in IT is the ability to concentrate and focus on one special issue, to submerge into one task and fade out the rest around you. I experience this at home once a while, because my companion in life is a software architect and CEO. Being in a demanding project his head is working 24/7 and it seems as if nothing else could reach him. The ability to fade out everything which is not important for the project is on the one hand a gift but on the other hand it could be a really dangerous demon if even the physical and mental needs of oneself are faded out! This will perhaps be okay for a period of three months or so. But reality could be that project is followed by project and the period is no period any longer; it is the norm! People start with too much coffee every single day, caffeine pills or energy drinks or even worse with brain doping! Being tired or headaches often are signals, the body is sending us in case to stop us. But with ignoring the signals and working against them with some kind of drugs, situations will get worse! A downward spiral is started.
What kind of life is it, if we do not care for our own well-being?
The next point is, that the IT and tech-industry is still mostly a men´s world – sorry ladies, hope that will change some day! And even in modern times, in a men´s world you do not talk about emotions, excessive demands and mental illnesses, because lot of people believe that these are signs of weakness! So the risk is very real that people try to hide their problems until it is too late.
So, who has to care for the well-being? WE ALL DO!
At first everyone has to take care of their own individual well-being and pay attention to what our bodies are telling us! If we don´t care for ourselves, how will we be able to take care for others?
Then there are colleagues, who should have a closer look at each other and talk about emotions and problems. Communication is a very important key for the well-being and the recognition of health and mental problems.
Last but not least there are the leaders who play, to my opinion, a vital role in this issue. They are responsible for the success as well as for the employees. But what will happen to the success if the employees are insane or out of job for a long time?
A paradigm shift is the only way! You all know about the problem! So please start to take care of yourself and of others! This will boost yourself personally and the team´s and company´s success!
In the fall of 2014 Microsoft and Docker unveiled a new partnership—a commitment to work together to bring native support for Docker containers to the next major release of Windows Server. Earlier this week the two talked about the progress made so far and gave some clues to what customers should expect once the next Windows Server hits the street sometime in 2016.
Mark Russinovich, CTO of Microsoft Azure, was in San Francisco this week at Docker headquarters meeting with his counterpart, Docker founder and CTO Solomon Hykes. The two met to talk about how their collaboration is progressing to bring Docker containers to Windows Server. The two didn’t share many specifics, but did say that the effort so far is achieving established goals and is proceeding according to the schedule they’ve laid out.
What is that schedule? We don’t really know. All Russinovich or Microsoft will commit to officially at this point is 2016. Whenever it arrives, though, it will represent a significant step forward in creating a platform-agnostic environment for developers. Windows developers will be able to integrate Docker containers natively with Windows Server, Visual Studio, and .NET applications.
The CTOs clarified that Docker support in Windows Server won’t allow Linux applications to run on a Windows operating system. Likewise, Windows applications in Docker containers won’t run on Linux. The value of the partnership and the integration of Docker support in Windows server is that developers will be able to leverage the same tools and common platforms for deploying, running, and managing the Docker container environment.
Microsoft Azure already added support for running Docker containers on Linux servers within the cloud platform. Once the new Windows Server hits, organizations will be able to run Docker containers on Linux or Windows and manage it all through Azure. It also enables developers to create application services running on opposing platforms and run it as part of a distributed application spanning both Windows and Linux.
The advantage from a Windows developer point of view is the ability to use the tools they’re familiar with. Developers will be able to use Visual Studio and .NET along with the built-in collaboration and workflow tools, as well as debugging and source-code control. It allows organizations to employ existing development practices and tools for creating and deploying Docker containers.
From a DevOps perspective the integration of Docker containers natively with Windows Server will enable better automation and continuity. DevOps and containers result in frequent changes to the app code and the underlying infrastructure, which is a bit of a culture shock for both traditional developers and traditional IT admins. Straddling the line between the two worlds by incorporating Docker containers and DevOps tools with the familiar Microsoft development platforms organizations are comfortable with takes some of the pain out of that cultural evolution.
Ultimately, the partnership between Docker and Microsoft will lay the foundation for completely platform-agnostic development. The app containers themselves may still require a specific OS to run, but at an organizational level the environment and infrastructure can be viewed and maintained as a holistic whole.
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”.
At the end of July we opened up nominations for our inaugural 
