Software Quality Insights


June 5, 2018  8:17 PM

5 reasons the Microsoft, GitHub acquisition makes sense

Darryl Taft Profile: Darryl Taft

After weeks of speculation and rumor, Microsoft has agreed to acquire GitHub, the hosting service for version control using the Git version control system developed by Linux creator Linus Torvalds, for $7.5 billion. There are various views on why this move may not work, but here are several reasons why a Microsoft GitHub combination makes sense.

Microsoft is big on open source

One reason why this deal makes sense is that Microsoft is the biggest single contributor to GitHub. Last year, about 1,300 Microsoft employees actively pushed code to 825 top repositories on GitHub, compared to Google with 900 Google employees that contributed to about 1,100 repositories, and 134 Amazon employees that pushed code to 158 top projects.

In addition, Microsoft now depends on GitHub for all its open source activity, since it shut down its CodePlex open source code sharing site last year and selected Git as the version control system for Windows development. Under a “One Engineering System” companywide policy, the Visual Studio Team Services (VSTS) team chose Git over other version control systems––including its own internal Source Depot. They also developed the open source Git Virtual File System (GVFS), which enables users to manage massive Git repositories. Microsoft and GitHub later ported GVFS to both macOS and Linux.

GitHub complements Microsoft’s DevOps story

Microsoft recently integrated Visual Studio App Center and GitHub, to help GitHub developers automate DevOps processes as they build mobile apps for iOS, Android, Windows, and macOS devices. Visual Studio App Center enables mobile developers to build, test and distribute mobile apps to a variety of different devices, including iOS and Android, monitor the performance of those apps,  and collect analytics and crash dumps to iteratively improve their apps. Additionally, integration with Microsoft’s Azure DevOps Project lets GitHub developers configure a DevOps pipeline and connect it to the cloud with no prior knowledge. And GitHub Checks API, now in public beta, enables users to perform continuous integration, linting and code analysis.

Nevertheless, questions remain about a Microsoft GitHub marriage, such as what Microsoft will do with VSTS and GitHub Enterprise.

At $7.5 billion, it’s a good deal

Although the $7.5 billion price tag seems huge, Microsoft stands to gain significant value from GitHub, the largest code host in the world.

GitHub’s customer base of around 27 million developers is a ready-made ecosystem for Microsoft to tap for support, and also a big revenue opportunity to host all those open source apps on Azure.

Chris Wanstrath, co-founder and former CEO of GitHub, joins Microsoft as a technical fellow, while Nat Friedman, former CEO of Xamarin which Microsoft acquired in 2016, takes over as CEO of GitHub.

It further establishes Microsoft as a steward for developers

Microsoft founders Bill Gates and Paul Allen built the company with developers in mind, and the company has worked closely with its developer community to establish a platform and strengthen the platform’s ecosystem. Now, as the company opens up to open source, it must expand its horizons.

Staunch open sourcers and some Microsoft haters have fled GitHub or are contemplating it. I get it. Nobody wants a big, scary vendor to manage their code and tools. But I believe Microsoft will leave GitHub alone and keep it open. Putting Nat Friedman, an open source veteran, in charge is a positive move. I compare this to my beer geek friends who refuse to drink the beer of any craft brewer that sold out to AB InBev, Budweiser’s parent and largest brewer in the world. I know there are underlying issues to their refusal. But all I can say is, Goose Island sold out to AB InBev and I still love me some Bourbon County Brand Stout.

VS Code and TypeScript are wildly popular

The success of Visual Studio Code and TypeScript, open source projects that originated at Microsoft and hosted on GitHub, bodes well for Microsoft’s future interactions with the open source community. Visual Studio Code, a source code editor for Windows, Linux and macOS, supports debugging, embedded Git control, syntax highlighting, intelligent code completion, snippets, and code refactoring. TypeScript is a superset of JavaScript.

VS Code is developed in the public on GitHub and has had over 17,000 developer contributions, and companies such as Google use both VS Code and TypeScript to build software for their platforms. Technologies such as .NET Core, NuGet, Power Shell and Azure SDKs are other projects that Microsoft has developed in the open and hosted on GitHub.

June 21, 2018  9:27 PM

Why QA, CI falter without automated release management

Jan Stafford Jan Stafford Profile: Jan Stafford
ALM, Continuous deployment, Continuous integration, QA, Release management

Software release management is really not a new area of technology, but adoption of formal processes and automated tools in this area is shockingly low. Surprisingly, some IT organizations still think they can manage release management with Excel scripts. That’s just not true now.

The release of software is now part of a company’s brand promise. So if the firm’s software fails, its brand fails. If the software fails and the brand fails, there are more costs than there would have been to invest in modern software release management tools and practices.

The complexity of software systems is creating greater need for better software release management for automated ALM. IT environments are not simple, on-premise data centers. Today software often is released on multiple platforms and there are more types of software – apps, microservices, APIs – being deployed.

The more places an organization deploys applications, the more it needs application release automation, according to Theresa Lanowitz, co-founder of voke inc. “You need it to automatically keep track of everything that’s in a particular build,” she told me. This includes not only features in a new release, but any changes made in the staging environment, your test environment, and so on.

Lanowitz frequently hears DevOps pros say that their organizations are doing continuous integration, continuous deployment, continuous testing and “continuous everything.” Yet, voke’s research shows that very few organizations are really doing continuous integration. “The automation numbers are low, and you can’t really do anything continuous unless you have good automation basics in there,” she said. Not a whole lot of organizations have that. There’s still a lot of manual activity going on the software lifecycle and in software release management.

To do continuous processes, an organization has to start with architecting software systems soundly. The enterprise has to invest time and money to allow its application processes to evolve to the point where automation can be used. It takes automation to do things such as continuous integration, continuous testing, continuous deployment, and continuous release and so on.

“When people think about application release automation, they’re thinking about speed, speed, speed of deployment,” Lanowitz said. Agile development brought good things, but the main message people took from it is: “You just have to develop faster.” Because developers have to move at this quick pace all the time, the work of QA teams often has been pushed aside.

Time-to-market has been businesses’ top application development priority for over a decade, Lanowitz said. Her recent research, however, shows a shift to software quality being the primary concern. “QA has to play a dominant role in software release management today,” Lanowitz said. In particular, QA must take over requirements, because the quality of requirement elicitation is still abysmal in the enterprise.

The need for quality assurance is a critical reason for automating software release management.  When companies invest in automation, QA is built into software release processes. Rather than being overrun by the need for speedy deployment, automation enables DevOps to control the software life cycle.


May 31, 2018  7:15 PM

Missing out on software conferences? Here are four worthy alternatives

Ryan Black Ryan Black Profile: Ryan Black

Developers, testers and QA professionals all like to fill the seats at software conferences. While there are ways to convince your employer to send you, sometimes travel is just not in the cards, due to a busy schedule or daunting costs.

When you skip a conference, you miss the chance to hear talks from thought leaders, learn new practices, network and even discover upcoming technological advents. Here are four comparable ways to attain the same benefits from software conferences in the comfort of your office chair.

1. Hear from thought leaders

Follow interesting conference speakers online to stay privy to new ideas — whether it’s on their blogs or social media. It can be difficult to find entities that share genuinely informative content — versus strictly promotional info — but there are definitely those who are worthwhile to follow. Seek out opportunities to engage with, ask questions or network online with these teams or individuals.

2. Tune in to conferences remotely

Nearly every software conference, summit or large-scale event streams a number of its sessions live. While there is no opportunity to chat with like-minded listeners or ask speakers follow-up questions, live streams give you the same information as conference attendees, without missed days at the office.

This approach may also allow you greater flexibility to pick and choose which sessions or speakers to tune into. However, be mindful that smaller events within a conference — including specialized sessions relevant to your particular interests — might not air online.

3. Read about these events afterward

Look for coverage that recaps and analyzes software conference sessions and news. Many of our contributors regularly attend these events and share information from several of the speakers. If you missed a conference this year, we have stories from it — including events like IBM Think, Red Hat Summit and OpenStack Summit. Furthermore, look forward to news from upcoming conferences like Cloud Expo.

4. Check back often

If you are looking for more analysis and insight written by industry professionals, our contributors have experience in a variety of software development capacities, including DevOps, software testing, APIs and microservices — to name just a few topics. From these writers you can find breaking stories, problem-solving tips, guides for beginners, video tutorials and more.


May 25, 2018  7:19 PM

Does Microsoft’s message to DevOps pros oversimplify?

Darryl Taft Profile: Darryl Taft
DevOps

Let’s be clear: Microsoft is dead serious about DevOps and wants to help DevOps pros. With its Visual Studio Team Services (VSTS) and Azure DevOps Project offerings, the company has delivered some of the most comprehensive DevOps tooling that you can get from one vendor.

Competitors such as IBM, CA and others also provide comprehensive DevOps tooling to help enterprise shops adopt DevOps to improve productivity of their developers, build products faster and enhance the quality of the software they deliver. But Microsoft is fresh in my mind because I attended the company’s Build 2018 developer conference recently in Seattle.

Rub some DevOps on it

It’s also fresh because I got some grief when I paid homage to one of Microsoft’s emerging star speaker’s use of the slogan “rub some DevOps on it,” which has become his tagline. The guy is Donovan Brown, principal DevOps program manager at Microsoft. Some observers questioned it, even calling it trite, dismissive and possibly even condescending to DevOps pros.

Brown has emerged as one of Microsoft’s top speakers and product demonstrators. He lives and breathes DevOps, and loves to do live demos of Microsoft’s DevOps technology to show the capabilities and openness of the platform. According to one published profile of Brown, he once pulled an all-nighter to rework a demo when someone pointed out an omission. With one hour of sleep, he got back onstage to present his new demo.

As a developer of 20 years, an Agilist and a former process consultant, Brown knows that the adoption of DevOps is no small feat. He knows the cultural and technical transformations that must occur for an organization to move to DevOps.

He explained that the phrase emerged while he and a small team from Microsoft visited a customer that had trouble implementing VSTS.

“While we were working through their process and identifying all the pain points they had, I made the comment that we were going to ‘rub a little DevOps on it and make it better,'” Brown said in a blog post on the slogan. “Everyone in the room started laughing at the thought of DevOps being a pain reliever. But when you think about it, it really is.”

He used the phrase during his DevOps demo at Microsoft’s Build 2016 event and it caught on. He said that when he got offstage, Twitter “was having a field day” with the phrase so he turned it into a hashtag: #RubDevOpsOnIt. That hashtag trends every time Brown presents. Folks familiar with Microsoft’s DevOps story know and enjoy Brown’s shtick.

Cringe worthy?

But obviously, not everybody.

“Honestly I’m not a huge fan of the catchphrase. It’s pithy, it’s catchy, but all it makes me think about is Silence of the Lambs: ‘It puts the DevOps on its skin or it gets the hose again,’ ” said Ted Neward, director of developer relations at SmartSheet, Bellevue, WA.

Rather than Silence of the Lambs, when I hear Brown’s catchphrase, I think of the old Chris Rock joke from his “Bigger and Blacker” HBO stand-up special, where he says when he was young his parents viewed Robitussin as a cure-all. He said if he had broken his leg, his dad would’ve said pour some ‘tussin on it! But I know that as a joke and I know Microsoft’s approach to DevOps and appeal to DevOps pros is for real.

Brown’s intent with the catchphrase is to connect with the audience as he demonstrates how to use Microsoft’s tools to set up an end-to-end DevOps pipeline, he said.

“To talk down to the audience would be putting myself down as well; I have DevOps in my title,” Brown told me. “Why would I dismiss or talk down about myself?”

Perhaps, you just had to be there, as folks often say about things that don’t translate well from an event to the telling of it.

Works for me

In any event, I get it and it works for me. In this age of rapid app development and deployment to meet increasing demand for applications to power digital transformation efforts, DevOps is a must-have, Brown says. And like rubbing an ointment on a burn or some dry rub on a rack of ribs, it’s going to make it better.

I also must admit that I like that Brown is an African-American that excels in a field where greater diversity is sorely needed. He may come in with a light-hearted catch phrase, but watching him present, even the uninitiated quickly learn that they are watching a well-prepared DevOps master at work. He puts in the work, rehearsing relentlessly.

Still, “I’d steer clear of that catch phrase, personally, simply because I think there are better ways to express the ideal of DevOps being something that you can apply in a number of scenarios and in a number of incremental ways,” Neward said.

What is DevOps really?

Meanwhile, although Microsoft customers love Brown because he’s a great speaker, the premise of DevOps itself has yet to be clearly defined, said Theresa Lanowitz, an analyst at Voke.

Brown authored Microsoft’s definition of DevOps: “The union of people, process, and products to enable continuous delivery of value to our end users.” Yet, Voke’s research indicates that there is no standard definition for DevOps. In a survey they received more than 80 unique definitions.

Moreover, if DevOps is supposed to encourage collaboration between the dev side of the house and the ops side of the house, “Microsoft never addressed the ops side,” Lanowitz argues.


November 28, 2017  5:53 PM

Why a former veteran is now offering pro Scrum Master training

Valerie Silverthorne Profile: Valerie Silverthorne

Greg Gomel is an Agile consultant and a veteran of the Coast Guard Reserve. So when he and fellow Agile consultant Ravi Verma were brainstorming earlier this year about what they could do to help military veterans it wasn’t surprising their minds turned to Agile software development.

“We wanted to do something that would improve their employment opportunities,” Gomel explained. The result was Agile for Patriots, a not for profit organization based in the Dallas/Fort Worth area that gives veterans free intensive prep so they can sit for Scrum.org’s Professional Scrum Master training test.

Although the duo were inspired by coding boot camps, they decided to take a different tack. “The biggest obstacle in dealing with companies that need to hire a Scrum Master is they want multiple years of experience,” Gomel explained. “We really wanted to provide some shadowing opportunities to help veterans get more experience under their belt to overcome that obstacle.”

So they decided to offer two days of intensive Scrum Master training, followed by two one week practice sprints and ending with presentations in front of actual hiring managers. Gomel reached out to another Dallas area veteran’s opportunity group, Allies in Service, and had them actually “vet” the veterans for the Scrum Master training program. Honorably discharged veterans with some kind of IT experience in their background were approached and in the end around 55 sat through a one-day orientation. Sixteen veterans went through the professional Scrum Master training and 10 received their certificates and went on to the two one-week sprints and presentation time in front of actual hiring managers.“That really matched our initial expectations,” Gomel said. “We were really pleased.”

But he’s also realistic that those few weeks aren’t going to be enough, by themselves, to make a substantial career change. “The certificate is going to get you in the door but it’s not going to get you the job,” he said. Instead the emphasis was on looking for “shadowing” and volunteer opportunities to give veterans as much hands on experience as possible so they have a good story to tell when interviewing.

Agile for Patriots is planning to offer another session in February 2018, again in the Dallas area. “We’re going to continue to help them try to align themselves for the highest probability of success.”


October 25, 2017  2:44 PM

Is your software automation testing framework working?

Valerie Silverthorne Profile: Valerie Silverthorne

When it comes to software testing automation, it seems we all still have a long way to go. A look at a new survey from Logigear looks at the state of your software automation testing framework, and all that surrounds it, and it’s easy to understand why everyone struggles.

First, just 56% said their organization had all the skills to automate, and 34% said their teams only had some of the skills. In fact that same percentage (34%) said lack of skills was the number one reason preventing them from implementing a successful software automation testing framework. Other barriers include overall cost (32%), management doesn’t understand (31%), and the high price of tools (also 31%).

Interestingly, 38% of the survey respondents rolled out a software automation testing framework that failed, but they moved past that and now have an ongoing automation program. On the other hand 25% tried, failed, tried again and still did not succeed. An impressive 19% said they were able to initiate a software automation testing framework that worked the first time.

When asked to describe automated testing efforts, the most popular answer, at 19%, was that it eliminates repetitive tasks so time can be spent doing more interesting/important exploratory testing. And at least some companies are starting to appreciate how a software automation testing framework can improve things: 14% said it was a “very effective” part of the test process.

Logigear also asked companies how they measure whether testing works. A hefty 67% said it was by time saved, followed by number of functions automated (38%) and bugs found (34%).

To improve automation efforts going forward, 53% said they needed to make them more maintainable, while 38% wanted to add new functions or tests more quickly and 35% simply wanted to run automated tests more quickly.

How do these stats compare to your own software automation testing framework? Let us know.


September 14, 2017  1:05 PM

10 tech terms the business side needs to know

Valerie Silverthorne Profile: Valerie Silverthorne

Scott McCarty, head of technical product marketing for containers at Red Hat, thinks we all just need to get along, and for that to happen we need to understand each other better.

With that in mind he’s pulled together a list of 10 tech terms the business side needs to understand. Perhaps you’ll want to print this out and hand it to your product manager or line of business person.

  1. DevOps: “At the end of the day it’s about devs and ops getting along better and having Ops architecture embedded in the dev process so that what devs put in to production already works right,” McCarty explained. It should be flexible, but it should also be sure to reward the ops people — the maintainers — as much as the developers — the creators — are rewarded.
  2. DevSecOps: All of the above plus security people actually working with developers and operations people. “They’re not there to say no, they are there to help the business,” McCarty said.
  3. BizDevOps: “This is the next logical step, bringing the business in with dev and ops and fine-tuning it all.” The bottom line: dev and ops need to be doing what the business needs so they all need to work together. And that’s BizDevOps.
  4. Linux containers: “These are my babies,” McCarty joked. But he’s serious about the need for business to understand the benefits of containers. “Containers make it easy to move the code and provision or update it in different places and that allows the business flexibility. But what they need to understand is it does take some investment to make it happen.”
  5. Microservices: “This is completely driven by the developers,” McCarty said. “This does nothing for the ops side.” Basically microservices break an app in to pieces making it easier to divide up the work and/or bring a new hire up to speed more quickly. “This is something that enables BizDevOps.”
  6. Automation: “This is a confusing one sometimes,” McCarty admitted. “This really enables business flexibility, like BizDevOps.” But it can be a two-edged sword. “Automation doesn’t necessarily make a project happen faster and it can throw a monkey wrench in to the works.”
  7. Orchestration: “Orchestration is to help ops teams in production manage their resources efficiently,” McCarty said. “It’s not about scaling headcount but scaling the business.”
  8. CI/CD: Continuous integration/continuous delivery builds on everything else that’s going on and brings in testing to the process, McCarty said. “Most companies are doing CI, but not many are truly doing CD. CI makes it a simple decision to put something in to production vs. waiting 10 hours, and that gives the business flexibility.”
  9. Agile everything: “I see business people abuse the word ‘Agile’ all the time,” McCarty complained. “Most business people aren’t Agile. Don’t call a process Agile without understanding what it really means.” In other words, if there aren’t standups, sprints and reviews, it’s probably not Agile.
  10. Infrastructure as Code: “This is another piece of DevOps,” McCarty said. The ability for programmers to manage data center provisioning through high level coding gives an organization a big leg up. “From the business side infrastructure as code costs a bit more in time and money to do but the benefits are massive.”


August 4, 2017  2:41 PM

Is Agile stuck? Looking for answers at Agile2017

Valerie Silverthorne Profile: Valerie Silverthorne

It’s hard not to ask the “Is Agile still relevant?” question today. And it’s harder to still to hear some of the answers, ranging from straight up “No” to “too much focus on process” to “they’re their own worst enemies.”

That’s why, in advance of Agile2017 next week, I reached out to Ronica Roth, adviser and team lead for agility services excellence at CA.

Roth says the negativity is inevitable (though she’s quick to add she’s eternally optimistic). “There are too many people who’ve hung out their shingles as consultants and focused too much on the process and gotten stuck there,” she said.

Her solution is simple: get back to basics, which in this case means have a clear idea of what your goal is before you start anything. “Our message to customers lately: go in knowing what outcome you have in mind. Have a clear hypothesis why you want to be ‘Agile.’ You need to apply some lean principles to it and be clear about what aspects of Agile you need to leverage to get better results.”

And no matter what, don’t listen to the naysayers and particularly to those who hold your feet to the fire because your “process” isn’t sufficiently Agile.

“If a consultant or coach says you’re not doing Agile right I don’t want them to work for us,” Roth said flatly.”Agile is all about being learning driven and not plan driven. It’s about paying attention to what’s working and to customers.”

In fact, Roth says she sees a time when we won’t be calling anything Agile, or Lean, but rather just “modern software development.”

Her advice for what to attend at Agile2017, besides her own session of course? “You want to go to anything related to culture and leadership because that’s going to transcend whatever process you’re focused on.”


July 12, 2017  1:59 PM

Is the future of Agile actually BizDevOps?

Valerie Silverthorne Profile: Valerie Silverthorne

It’s easy to think every organization has DevOps on the corporate brain but in reality, interest in — and commitment to — Agile remains high, particularly in the enterprise space. Of course, that doesn’t necessarily make it easy to do. And it doesn’t mean DevOps isn’t having an impact.

With Agile2017 less than a month away I interviewed AgileCraft CEO Steve Elliott about the company’s 10X product release and the ongoing efforts enterprises are making to be more Agile/agile, in all senses of the word. Elliott’s seeing strong demand for a way to tie Agile efforts in to the business side, something the new 10X is designed to help with. But here’s what struck me as really interesting: in a weird way, what large enterprises are looking for sounds a lot like what some would call BizDevOps, or DevOps 2.0. It’s the idea that the business side, developers and operations are all working together with biz integrally involved in every step of the process up to and including setting the agenda.

Here’s how Elliott explains it: The key is to get developers to understand why they’re building the software they’re building (i.e., understand the business case) and to let the business side know, in a granular way, exactly what works about the software in design and production and what doesn’t. And then replicate that across 20 (or more) Agile teams. AgileCraft’s 10X is designed to tackle that problem from a technology side, but of course there’s the culture shift implied in all of this as well. “I still think the hardest thing for us to build and deliver on is the business agility piece,” he said. “The developers need to know the why, the context is important, and the business side needs to understand everything that’s going on with the technology. The companies that can bring those two sides together are the ones that are going to win.”

Elliott sees his product as a way to marry the speed of DevOps with Agile processes and ensure a communication flow from all sides. So whether it’s SAFe Agile, or BizDevOps, or digital transformation it’s another sign that enterprises are realizing things have to change.


April 30, 2017  3:01 PM

We’re not as automated as we think we are

Valerie Silverthorne Profile: Valerie Silverthorne

Test automation is not as far along as we’d thought, Agile and DevOps aren’t making software development easier and management is still everyone’s biggest problem.

Those are just some of the results of a survey done by software test company LogiGear. And this wasn’t just any survey — 10 years ago the company did exactly the same survey asking the same questions. So today’s results can be compared point by point with how testers were feeling 10 years. That is where things start to get really interesting.

“What was really surprising was that in general most things were the same,” said Michael Hackett, a senior vice president and co-founder of LogiGear. Case in point: the number one problem with testing automation today — and ten years ago — is that management doesn’t understand how it works. And then there’s the “have things gotten better since you started doing Agile?” question of ten years ago (where the answer was largely “no”) was updated to include DevOps this year and the answer was still largely “no,” Hackett said. Just 20% of testers said things were better. Automation’s not really moving forward either. A full 75% of testers said just 25% of their testing is automated; 20% said their company had no automated testing in place at all. “One in five said they had zero automation in 2017,” Hackett said. “It’s not going to be good when they finally wake up and want to make a digital transformation.”

So what’s the problem? Hackett’s explanation — that not enough attention is paid to all the important details — was interesting. “I think a lot of people have a bad definition of done,” he said. “They build up technical debt and that is turning in to a bigger problem then people thought. The concept of ‘release and fix it later’ really has a ripple effect with testers that really impacts their schedule.”

There is one bright spot though. Over the last ten years, companies have started to use ALM tools, and now everyone has access to test cases. No more using spreadsheets or word docs thanks to ALM.

But as for the rest…there is work to be done.


Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: