Software Quality Insights


February 13, 2017  2:24 PM

Red Hat’s 8 rules of successful Open Source

Valerie Silverthorne Profile: Valerie Silverthorne

Everyone wants to use and participate in an open source software environment but sadly not everyone knows how to do it right. This is the perspective of Matt Hicks, vice president of engineering for Red Hat’s OpenShift. So he reached out with his 8 unwritten rules of Open Source. “These are just really good life rules but they work if you apply them to open source too,” Hicks said in a recent interview.

The rules seem straightforward enough:

*Get to know the community and the people who participate in it
*Put technology before individual business goals
*Also put the community “first” first
*Beware of “pay for play” and unbalanced communities
*Be open
*Think “derivatives,” not “forks”
*Contribute wisely
*No crying

What drove him to come up with these rules is the growing popularity of Open Source, which brings with it numbers of people who really don’t know how it works. “Here’s what makes really good communities thrive and how to have more influence when you work with it all day,” he explained. “People get frustrated. They came in, submitted a patch and no one listened to them. I spent my time and built this thing and Open Source doesn’t want me. I felt the impetus to break down the rules. It’s great that we’re getting contributions in but it takes more than just writing the code and submitting it to GitHub. These are commonsense type rules but it’s surprising how many get missed.”

I asked him about my favorite of the rules — no crying. Hicks explained that the “maintainers,” who have the job of overseeing any and all proposed changes, can be “terse and dismissive” of suggestions that don’t fit or won’t work. And that new contributors simply cannot take that personally. Maintainers are busy, and newbies need to understand it can take time and patience and understanding of the bigger picture for their suggestions to be heard.

Hicks’ favorite rule? Putting the community first. “We see someone who’s done really good work but it breaks a lot of other things,” he said. “Sometimes we just can’t take them because the cost of addressing other edge cases is too high. Don’t just think of the things you want to get in. Think of the other things that might break.”

January 24, 2017  5:16 PM

Development problem solving, the LinkedIn way

Valerie Silverthorne Profile: Valerie Silverthorne

For those wondering what it’s like to be on a 3×3 mobile release schedule, look no further than LinkedIn which has 3 releases a day and a plan to never let code be older than 3 hours before committing to it. Even if your company is the size of LinkedIn, that’s a big enchilada to get through daily and for it to happen everything — including testing — has to move along like clockwork.

But even with these good intentions, the company hit a wall when it came to automating iOS UI testing. Off the shelf solutions weren’t cutting it, and without an easy fix, the idea of 3×3 was not going to be a reality.

The solution? A DIY open source solution — called “Bluepill” (think The Matrix) — has just been released for all to use, and it’s already saved LinkedIn thousands of developer hours.

Bluepill will let you run tests from multiple simulators in parallel and will pack the tests in to similar groups. A junit report is produced afterwards. Find more details about Bluepill, from LinkedIn’s blog, here.

What did it take for the LinkedIn team to pull this off? Oscar Bonilla, one of the LinkedIn engineers working on this project, explained: “The first commit happened on Aug. 12 and we had it working on the LinkedIn Continuous Integration system by Nov. 1.,” he wrote. “From there we continued to polish the project and address a few bugs. So in total it took about 10 weeks to build Bluepill and another 10 to refine it.”

And the goal was always to make this open source. Want to see for yourself? Find it on GitHub.


December 28, 2016  3:17 PM

The promise — and pitfalls — of low code/no code

Valerie Silverthorne Profile: Valerie Silverthorne

Amidst the many changes we saw in 2016, one stands out to me as I look forward to 2017 and that’s the rise of low code/no code platforms. These tools are designed to let pretty much anyone — even a 19th C. English Lit. major like myself — create applications, or tweak existing apps, without actually knowing how to program. On the surface, this sounds like an obvious and inexpensive solution to the worldwide software developer shortage. But is it really?

So far, most low code/no code citizen developers are creating apps for internal customers and that solve problems specific to their businesses. This isn’t a bad thing; conceivably it frees up IT to focus on more pressing issues and more than likely citizen devs can bring their ideas to life far more quickly if they can do it themselves.

But “outward facing” apps built by citizen developers are increasing, according to a survey from QuickBase and the tip over point — where there are more commercially released apps than not — may be approaching in 2017, or maybe not. Forrester Research principal analyst Robert Stroud is certainly bullish on citizen developers, but points to a lack of support from cloud platforms like AWS as one barrier to their further use in organizations.

And there are other challenges. Who oversees these citizen devs? If it’s the business side — which might make sense — then there needs to be a way to ensure that all of those IT “rules” regarding compliance, security, etc., are followed. Those aren’t necessarily areas where a product manager is going to focus his/her attention. And while the existing low code/no code platform solutions are robust enough for the jobs they’re doing, they’re not at the point yet of covering everything from idea generation to development, security and ultimately deployment. That, I think, is where the real promise lays.

It will be interesting to see if those one-stop-shop solutions arrive next year.


December 21, 2016  3:19 PM

Software dev and test in 2017 — what’s next?

Valerie Silverthorne Profile: Valerie Silverthorne

It’s certainly been a year.

I feel as if 2016 started out as the year of Agile maturity, and ended as the year of DevOps. On the test side, 2015 ended with a debate over whether testers should learn to code and it seems like 2016 is ending with a dispute over which skills testers need for the future, only some of which actually involve coding.

Whether it’s elections or technology, it’s simply hard to predict what’s going to happen.

So I asked someone who is actually paid to prognosticate what he sees coming in 2017.

“I think there’s a question we should be asking about DevOps,” said Robert Stroud, a principal analyst at Forrester Research. “Is it really going to be relevant going forward?” Stroud is not the only one who points to BizDevOps as the most logical way forward when it comes to everything software development and deployment. In the future, “business is going to own the execution of these products rather than reporting to the CIO,” he said.

That’s not his only prediction. He thinks citizen developers — empowered by no code/low code platforms — are also going to be in the next big wave of changes. A key part of BizDevOps, citizen developers are going to help push business further in to the development space.

Containers will also continue their march forward in 2017, Stroud says, thanks to ongoing enthusiasm (some would call it pressure) for continuous development and deployment.

Mostly, though, what Stroud sees next year is the continuing push to do more faster. “Developers are not only going to deploy more freqeuently, they are going to change more frequently and will be looking to innovate more frequently,” he said. “Business is going to demand more from them.”

And that, sadly, is unlikely to change.


December 7, 2016  3:09 PM

Gene Kim, DevOps zealot, on BizDevOps

Valerie Silverthorne Profile: Valerie Silverthorne

I was kind of afraid Gene Kim, the man behind the DevOps movement and a very in-demand speaker and consultant, would be offended when I asked him about the idea of BizDevOps, aka DevOps 2.0. But to my very great surprise (and honestly, relief), he agreed with the notion completely during a recent conversation.

“My first response is that I think the premise is right on,” he said, of BizDevOps. “It’s difficult to argue that the tech function needs to be even more integrated with where the business activity is happening.”

But he was also quick to add it’s very, very early days when it comes to DevOps adoption. “I kind of resist personally what’s next in my mind because we’ve barely just begun at DevOps. If we look at the actual adoption it’s just 1 or 2 percent if it’s even that high. A part of me wonders why we’d talk about what’s next when we have not finished this yet.”

Then he quoted David J. Anderson (a well-known Agile author and speaker):”It’s time to stop starting and start finishing.”

But, at least in theory, he would like to see business and tech people working a lot more closely together than they do right now. “In my terminology (I can see) whole value streams working together to solve business problems versus “the feature factory” which is the opposite. That’s consistent with where DevOps is going. But it’s not around the corner.”

Then I asked him the other burning question I’ve had since I attended Agile 2016 in July: What does DevOps mean for Agile? “One of the main reasons DevOps is succeeding is the 11 years of prep Agile has done,” he said. “If it were not for Agile DevOps would have been laughed out of the room.” He stressed that while Agile isn’t an absolute prerequisite for DevOps, it helps loads. And he doesn’t see Agile disappearing any time soon either. “Agile is such a vibrant place of innovation I don’t see them as being in competition with each other,” he said. Instead, he pointed to the fact that DevOps speakers are showing up everywhere — QCon, Agile 2016 — as a sign that the lines are blurring. And that, in his mind, is a very good thing.


November 30, 2016  11:41 PM

Why we all need to take a deep breath

Valerie Silverthorne Profile: Valerie Silverthorne

Dave West, CEO of Scrum.org, is the perfect person to talk with when you feel the sky is falling.

We chatted a few weeks back, when it seemed that everything — in technology and in the world — was upside down. For starters, a just released survey from Harvey Nash showed technology was starting to “eat itself” and that large numbers of testers and even developers feared they might be automated out of a job in the next ten years.

Ok, that’s scary. But West’s take that this is more of a natural evolution than a disaster made sense to me. Skills are evolving and must continue to evolve but he couldn’t see a world without a testing function — even if it’s different than it is today — and his argument made sense. And as far as developers being automated out of work — about 47% of those surveyed by Harvey Nash said they were very worried about that — West pointed out that getting rid of the mundane developer tasks might improve productivity and creativity, something everyone should be happy about.

West remained upbeat, even when asked the “Is DevOps eating Agile/Scrum’s lunch?” question. Look in the original Agile manifesto and it will be clear that the whole idea of DevOps is already in there, and has been in there, West said. So really, no matter what you call DevOps, it’s, from his perspective, continuing the work already done by the Agile believers over the last ten years or so. And don’t count Scrum out, by any means, as it’s created the cultural and process foundation to speed up the entire software development process.

In other words, while things may feel a bit topsy turvy, Scrum, Agile, testers and developers aren’t really going away, at least in Dave West’s view of the world. I’m relaxing a little…what about you?


September 28, 2016  1:19 PM

Why containers aren’t one size fits all

Valerie Silverthorne Profile: Valerie Silverthorne

At a time when it seems containers and microservices are practically all everyone is talking about, it’s easy to think they’re a no-brainer solution to so many development problems.

But it’s not that straightforward. I spoke recently with Scott McCarty, an evangelist and “container thought leader” at Red Hat. Why wouldn’t someone user containers? It turns out there are several compelling reasons. First, not every application is container friendly.”Will my app fit in the container and will it be able to run in a relatively sane way?” McCarty asked. Containers require the operating system to be broken in to two pieces so an application needs to be able to handle that, McCarty explained. “Some apps just weren’t meant to be divided in to two.” And then there are what McCarty calls the “edge cases” which are apps so large and so dependent on, say, an Oracle database, that it’s just not feasible to port them in to containers in any kind of reasonable time frame.

Stay safe

Security is another significant concern, according to McCarty. If you can break the app down in a way that makes it work in a container, you’ll get a good bit of built-in security, he said. But if the application can’t be divided correctly, “you don’t get those security codes for free and the value proposition is really limited.”

Can we do this?

But there’s a third, surprising, reason companies are not choosing to containerize and that’s because they’re afraid they don’t have the internal talent to pull it off, McCarty said. “Do I have the talent to do this? Are we we even prepared to do this? Will I be able to hire the talent to do this?” And apparently this is a real concern, not just because of the worldwide shortage of software developers but because an explosion of tools and choices has meant each developer has the opportunity to do it his or her own way. But will they do it correctly, with so many choices? “That’s really the issue,” McCarty said. “Will they choose the right tools and will they be experienced enough to make it happen?”

What’s holding you back from moving to containers?


September 16, 2016  2:32 PM

An inside look at an enterprise architect’s world

Valerie Silverthorne Profile: Valerie Silverthorne

Is the role of enterprise architect changing? It is, and it isn’t. I know that’s helpful.

I recently spoke with Todd Loeppke, CTO Architect for Sungard Availability Services, a company that is focused on IT production and recovery. He has a broad view of the changing EA role, thanks to his many client contacts.

From his vantage point, the EA job itself really hasn’t changed but the pieces and responsibilities are changing and in some cases, quite dramatically. “If the IT architect’s job is to architect IT solutions that solve business problems under a big umbrella then the role hasn’t changed,” Loeppke said. “But the parts, the experience, well there’s pretty much everything under the umbrella that’s changed.”

Loeppke thinks the tricky part is that the tools an EA is using have changed completely and, of course, there are more tools. Take automation. The idea that so much should be automated in this DevOps world we live in is a huge change and something today’s EA is now forced to deal with. “Automated testing is taking over, and it has to,” he said. An EA today “is going to have a greater sense of automation than ever before. This was not a sexy practice in the past but it is key to success in the future.”

But it doesn’t stop there. Loeppke says an EA today has to have a broad view of open source tools — and if you’ll pardon the pun, be open to using them. It’s ok to reach out to GitHub and see how other people have solved a problem.

And while the nature of an enterprise architect job is to be a generalist, don’t plan on being too general, or you’ll run the risk of missing something, whether it’s security or cloud or networking related.

Sounds a bit like same job title but a different playbook. How do you think the EA role is changing? Let me know.


August 30, 2016  9:53 PM

Making metrics less elusive in DevOps

Valerie Silverthorne Profile: Valerie Silverthorne
DevOps

Andreas Grabner, a “performance enthusiast” who works at Dynatrace, understands that metrics are the holy grail of a DevOps team, but he also knows that the information can be hard to come by on the Devs side of things.

Speaking recently at DevOps Days Boston, he was clear about what developers need: “Metrics should be put in your face.”

In fact, he recommends installing ceiling devices that can go from green to red so that devs can know instantly if a build isn’t working. Spinning red overhead lights can go a long way to drawing attention to a problem, right?

And it’s really not about automation, he said, because automating bad code does nothing for anyone. The key is to find a way to bring data to the developers right where they are.

“A developer is 100 percent responsible for the code,” Grabner said. “The code runs on the framework and if you don’t use the analytics tools you have you won’t know what’s going on. With a metrics-driven pipeline you get better code from the beginning.”

You don’t have tools, you say?

Ah, but there are so many out there, many available free of charge for personal use.

Here are some of Grabner’s suggestions:
Free of charge tools from Dynatrace.
Understanding PurePath (and getting a longer free trial).

Want to tell us what your favorite go-to analytics option is?


July 28, 2016  9:24 PM

Looking for direction at Agile 2016

Valerie Silverthorne Profile: Valerie Silverthorne

“To some extent Agile isn’t a solved problem.”

“Agile needs to freaking grow up.”

“We need to stop calling it Agile.”

“We need to stop saying Agile makes it easy to go faster.”

“Agile got us going, but DevOps is going to take us where we need to go.”

In the conference rooms of Agile 2016 in Atlanta this week, there was a lot of talk about where Agile is today. At 15 years old, Agile, in one sense, is maturing and going strong. But, even among those who preach it – and make a living from it – there is just a hint of unease when it comes to talking about the future.

Nowhere was this more obvious than during the session “2020: The State of Agile.” Moderated by Jann Thomas, a former developer, with three Agile coaches as panelists, this session was standing room only. But, as the session progressed, more and more people started to leave. The issue, it seemed to me, and in discussion with other attendees later, is that people were looking for a practical road map for Agile’s next few years. They wanted to hear, head on, how to tackle the challenges. What about new technology, what about DevOps, what about the fact that this can be so very difficult to get right?

The panelists were clearly frustrated with Agile’s “reputation” but their solutions were cosmetic in nature. One suggested renaming Agile (“it’s tainted” by folks who couldn’t do it correctly), and then offered up a slew of catch phrases including “bring your femininity to the job,” allow “openness and compassion,” “speak from your heart” and “bring your vulnerability.” At this point, a lot of people were leaving and one man raised his hand and suggested his CEO simply wouldn’t want to hear those things. There was nervous laughter at that.

And when the group did try to get a bit more nitty gritty, they suggested de-coupling Agile from speed of delivery. Don’t focus on faster delivery, focus on “sooner.” Is there really a difference here? They insisted there was but I am still not so certain.

This session left me – and many others I spoke with – feeling deflated. Change is coming, whether it’s via the Internet of Things, the cloud, or DevOps. Change doesn’t have to mean the end of Agile – after all, it’s quite diluted already given the thousands of different ways companies “do” Agile. But in order to roll with change, and grow from it, you need to acknowledge it. Agile needs practical and unfortunately for much of this week what we heard were platitudes.

It is, indeed, time for Agile to grow up and take the next steps.


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: