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.
- 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.
- 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.
- 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.
- 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.”
- 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.”
- 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.”
- 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.”
- 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.”
- 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.
- 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.”
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.”
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.
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.
Job site glassdoor.com just posted its top 25 highest paying jobs in America and 11 of those jobs were in high tech. And more than half of those, 7 actually, were software related.
It’s a really good time to be in development, clearly, with software salaries rising almost as fast as demand. But before you feel too good about your career choice, a quick look at the healthcare profession might bring you down to earth. Salaries for jobs in that field — physician, pharmacist, nurse practitioner, medical science liaison, pharmacy manager — are as high or higher than many software dev jobs and demand for them — based on the number of open positions at the time the report was released — is actually higher.
One lesson we can take from this is that someone with so-called hybrid skills, like a programmer who is also a nurse practitioner, can really name his or her own ticket.
But the picture is still bright even if you don’t have hybrid skills. An application development manager, the 8th highest paying job in the report, can expect a median base salary of $112,045. But a peek at the actual jobs available show potentially much, much higher paychecks, like upwards of $180,000.
What are the other winners? Enterprise architects have a median base salary of $112,560, while software engineering managers can expect $109,350 and software architects, $104,754. UX managers can look forward to a median of $98,353, while a scrum master can ask for at least $95,167.
Interestingly, despite the mad scramble for “DevOps” professionals, no job with the word DevOps in its title was in the list. Software testers and AI engineers didn’t make the list either. Data scientists did.
As is widely know, the White House is considering making sweeping changes to the H-1B visa program. These changes could make it far more difficult for companies to bring foreign workers over to the US, perhaps by making it too costly to do so.
There’s no question about it. The H-1B program is quite controversial. Those opposed to it say it takes American jobs away; those in favor feel it helps deal with a shortage of American workers in particular fields, including software development.
Several weeks ago I wrote a story that suggested any changes to the H-1B program really aren’t the problem but that automation might be the much bigger issue.
Now a new survey is out from Spiceworks showing that a majority are in favor of changes to the H-1B law. A total of 429 IT professionals participated and a sizeable majority — 67% — said they favor changing the H-1B law. Their reasons? The current rules favor large employers, respondents said, and the way the law is written makes it too easy for employers to abuse the rules. And there was certainly a concern that bringing relatively lower-paid workers in had the potential to get in the way of American-born employees seeking those same opportunities.
But this was most interesting…71% of those surveyed said the H-1B visa situation didn’t affect their organizations at all.
So it’s a little hard to know what to think about all of this. Will tightening the rules really help Americans? But what about the very real software developer’s shortage? As our story suggested, it can be hard for many companies to find skilled IT professionals today.
Where do you stand? Let me know.
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
*Think “derivatives,” not “forks”
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.”
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.
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.
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.