Ask any application-development decision maker or programmer: Emerging technologies force enterprise IT shops to rethink not just which new products and services to adopt, but even more importantly, the very nature of how they do their jobs. For this reason, TechTarget’s expanding its coverage of IT operations with the launch of SearchITOperations.com.
Our long-standing attention to core application development technologies and buying trends — such as development ALM and app containers — will not change on the TechTarget coding and software websites you already read. Rather, through the new SearchITOperations, we recognize the cultural and technological transformation underway as IT operations and application development more closely collaborate to heighten their enterprise’s ability to respond to market changes.
Reaching into 2020
Looking out over the next three to five years, strategic IT shops will need to move beyond cost savings or avoidance, marked by silos and limited collaboration, to thrive. All aim for stable, flexible operations that are custom fitted to the internal landscape, corporate goals and business outcomes of that enterprise.
For many IT shops, the desire to facilitate shorter application release cycles without outages and mistakes means reordering staff, acquiring new skills and choosing from a plethora of new tools to automate tasks.
The new site is dedicated to the news, features, how-to tips and other expert content that enables IT operations pros to manage new application architectures and faster release cycles, along with the feedback loop concept promoted by DevOps. From our view, these tie-ins with AppDev teams are clear and important.
As always, our readers can expect unbiased technical information as they evaluate new tools, learn additional skills and plan tomorrow’s IT operations.
We hope you’ll check out the new resources on SearchITOperations, and we thank you for your continued loyalty to, and readership of, SearchSoftwareQuality.
My recent story on the surprise skills gap — writing, public speaking, communication and most decidedly NOT tech skills — has me wondering what it means to be the ideal employee. The term “well-rounded” is tossed around a lot, but what does that actually mean when it comes to testers and developers?
I went to a liberal arts college and, all right, I’ll admit I was an ENGLISH major. And not just any old English major — my degree was in 19th C. British Lit. Yes, my father was certain I would never get a job with a degree like that. He was a CPA and his view was that college was supposed to give you a marketable skill or, even better, skills. I obviously didn’t get “skills” but I did get an education.
That was a million years ago, and the world has changed a lot. Just this week I had a reader mention that he literally keeps his developers “locked in a back room” because they are completely unable to communicate — orally, or by email — with his customers in any way that resembles “standard” English. I did not get the sense that his developers were non-native English speakers; instead, it seems they just don’t have good communication skills, which of course brings me back to that skills gap.
So, to be an ideal developer or tester today you need: tech skills, of course, but you need to be able to write, speak and interact comfortably with customers and business people, and then you may need that “extra” something that involves, say, industry experience. That’s what Matt Sigelman, CEO of research firm Burning Glass, refers to as “hybrid skills.”
In other words, I think the bar is getting set at a higher and higher level as time goes on. There are straightforward solutions if you have an employee with insufficient tech skills; but Dale Carnegie and The Toastmasters aren’t exactly household names any more (click on the links if you actually don’t know who/what they are!) and as far as hybrid skills go, a hybrid developer creates him/herself by choice. The employer doesn’t have much to say about that.
So how do we solve that skills gap? Does your company have a strategy that’s worked? Or do you think the problem is overblown? I’d like to hear what you think.
Suddenly, in mid April 2016, everyone, and I do mean everyone, is talking about DevOps. They’re talking about Agile, too, of course, but unless I’m imagining things, it’s DevOps that seems to have captured everyone’s attention.
Last I looked, DevOps adoption was hovering at a (more than likely optimistic) 20% or so in mostly companies that self-identified as digital disrupters (in a survey of 1442). But now…it’s ALM and DevOps, it’s DevOps and security, it’s DevOps DevOps, Devops, oh, and Agile too.
So when did Agile become so last week? SearchSoftwareQuality columnist Jenn Lent, in her end of 2015 column, predicted this might be the year when Agile actually grows up. Seems it might have grown up so quickly that’s it’s morphing in to that next thing.
Is this bandwagon jumping, or is this real? I asked the last CEO I interviewed, who is rolling out a new product aimed at the DevOps market, just what kinds of companies he thought were going whole hog for DevOps. His answer: large companies and startups. Hmmm…those are the same kinds of companies still doing — and working on — Agile.
Another source I talked to a few months back was actually laughing about DevOps. To paraphrase, he said he felt Agile had already upset the apple cart for testers and developers and asking them now to take the HUGE step and embrace DevOps? Crazy talk.
And then there’s the CEO of Shippable who didn’t hold back…he straight up hated developers. Until he was one. And he still thinks the way DevOps is implemented is ridiculous. He calls it a whole “Kumbayah” thing.
But, he’s also got a product focused on making DevOps easier to implement, so he obviously believes in the concept.
So let me ask you — is the DevOps train coming by your town? And what’s happening with Agile while that happens?
It feels like change is coming. What do you think?
According to a new survey from NGINX, our apps are performing very badly indeed. And perhaps what’s worse news is that a whole lot of companies really aren’t doing anything about it.
NGINX did an in-depth survey of 1800 IT professionals on a variety of topics and it turned out there were several surprises, according to Peter Guagenti, chief marketing officer of the company. He said he was very surprised to see how widespread use of containers and microservices were (close to 2/3 surveyed were either already using or seriously exploring containers and nearly the same percentage was true for microservices).
But what absolutely shocked him and his team was the data on performance. According to the survey, app performance was a significant issue for 75% of respondents — they reported their app was either somewhat or extremely slow. Ok, that’s not good. But what’s worse was the fact that one-third of survey takers said their companies were doing absolutely nothing about it. Wow, nothing? (If you don’t want to be one of those ignoring performance, here are 19 ways to make your pages load faster.)
We know that slow applications cost companies tens of thousands of dollars, at least, in lost revenue as users get fed up and head to a competitor or just give up in general. “Not paying attention to this is the modern day equivalent of not paying attention to customer service,” Guagenti said.
On one hand, Guagenti said he can empathize. “What’s really going on here is the constant push-pull. Most organizations are understaffed. They need to build new features and the entire process is targeted at creating new features and not maintenance or performance tuning.” What ends up happening, he explained, is that companies become unwilling to go backwards.
And that’s how apps end up performing badly. What do you think companies need to do to fix this?
The senior site reliability engineer certainly has his work cut out for him. Uber is in 400 cities around the world, with more than 1 million drivers and just recently has gotten in to food delivery in addition to its normal ride service.
I was paying even more attention than usual because, as an attendee at the Fluent Conference in San Francisco, I wasn’t just a journalist. I was an Uber customer.
So while Hughes-Croucher talked, I was thinking about my first Uber ride, which, honestly, went off without a hitch. The pleasant driver arrived two minutes after I placed the request, and it was a restful few moments during a busy business trip.
Hughes-Croucher would certainly have approved because that’s the goal, of course, despite how fast the company is growing. “When everything’s exponential there’s no opportunity to be wasteful,” he said. “You have to find things that are going to make an impact. Reliability and performance are critical. If our systems are down those people can’t work and you can’t get a ride.”
Hmm….I really was going to need another ride soon. Hopefully Hughes-Croucher had me covered. He focused his talk on the importance of detecting bad releases, having fast and efficient rollback and mitigation and making sure there is always performance reliability.
I thought about that later in the day, as I requested another Uber, only to get a “network unavailable” message. Uh-oh. Another try hooked me up with a driver, but he had to cancel the trip because he was pulled over by a cop on the way to picking me up.
That’s not something I can blame on Hughes-Croucher, whose attention to detail is impressive but even he can’t control traffic cops. What he is trying to control, though, is time. His strategy, though complex to implement perhaps, is beautiful in its simplicity. He advocates only rolling out a 5% change and then watching that rollout like a hawk. If there’s an issue, it’s instantly rolled-back and the only “hit” to performance is really to the developer’s productivity and not the customer’s. At least in theory, this makes a lot of sense to me.
During my last Uber ride, I did what I always do and asked how the driver liked his job. He does, very much, but he’s about to radically reduce his hours. Why? He’s decided to go to school to become a software tester.
I let him know Hughes-Croucher (email@example.com) is hiring.
There were plenty of wow moments as IT leaders revealed new software, space and robotics technologies at the 2016 Lesbians Who Tech (LWT) Summit. The biggest surprise, however, was a speaker’s revelation about 1950s’ tech culture. During the main keynote, former IBM Senior Systems Programmer Edie Windsor corrected the widely-held assumption that she was one of the few women computer pros at IBM in the 1950s and 1960s. Indeed, “about a third” of her programmer colleagues were women, she said.
I was certainly surprised. In this post, I’ll share more of this LWT Summit’s revelatory and funny moments, as well as what I learned about software and hardware engineers’ efforts to close the gender and minority gap in IT hiring.
Seeing women and minorities in technical positions was rare in late 1980s, when I became a tech journalist. For a couple of decades, I often was the only woman or one of a handful of women at tech meetups and in session rooms at IT conferences. So, I haven’t been surprised by reports that the number of women in the U.S. IT workforce dropped from 35% percent in 1990 to 26% in 2013. In the past couple of years, I’ve seen the ratio improve … but not a lot.
Thanks to these reports, bad press and diversity activism, many tech companies are making an effort to give more positions to women and minorities, said LWT founder Leanne Pittsford. So far, their follow-through hasn’t been impressive. She urged Summit attendees to increase their diversity activism in her presentation, titled “Take a F@!#NG Risk.”
“We need to take big risks. Without risk there is no progress,” Pittsford said. “There will always be more white, straight, CIS men in power until there is not.”
The opportunities in diversity activism are very, well, diverse. For example, the victory of Edie Windsor’s Supreme Court case against DOMA (U.S. Defense of Marriage Act) led to advances in gay marriage rights. Many 2016 LWT Summit-San Francisco speakers, including Hackathon session leader Kate Jefferson, work with Women in STEM groups, providing tech education. Apple VP Tara Bunch – who spoke about personal communication – is active in the workplace equality group, Out and Equal. Speaker Caitlin E Kalinowski, Oculus Head of Product Design Engineering, is on the board of wogrammer, which spotlights the careers of successful women engineers.
Diversity activism must also fight workplace and societal hostility toward women, minorities and LGBT people, Pittsford said. Join in working toward a world, she said, “where no one can lose their job because of their sexual or gender identity.” That discrimination still exists. In most U.S. states, laws allow employers to fire or not hire LGBT employees, in spite of the protections legislated by the U.S. Civil Rights Law of 1964.
At the Summit, Windsor confided that she had to remain closeted during all of her tech career, though she was out in her social life. “I lied a lot,” she said. In 1975, she retired from IBM to devote herself to LGBT activism.
While there was plenty of straight talk about the lousy state of diversity in tech, there was no male-bashing. TechCrunch reporter Megan Rose Dickey’s presentation, “The Kinsey Scale for Diversity,” is an example of the good-humored attitude prevalent there.
Dickey talked about the media brouhaha that followed Twitter hiring a white male diversity chief. That was Jeremy Siminoff, who held a similar role at Apple. Dickey wrote a pro-Siminoff article about the hire, noting that he is gay. On Dickey’s Kinsey Scale for Diversity, Siminoff gets a point for being gay. So, he’s not at the bottom of the diversity scale. Pittsford, who is white, only got two points for being a woman and a lesbian. Dickey ranked herself higher, because she’s African-American, lesbian and a woman. And so she continued to the point of near-absurdity.
Dickey’s smart, tongue-in-cheek presentation was typical of the day’s presentations. I’ve never laughed so much at a tech conference.
What matters most to you? A big paycheck? A job that is going to make the world better? Or an environment that’s not particularly stressful?
Apparently you do have a choice. According to a brand new survey of 18 large high tech companies from PayScale Human Capital, tech workers today are mostly young, white and male, none of which is surprising. But what might surprise you is that working at Facebook isn’t particularly stressful – just 44% say they’re tense while on the job – while 92% of employees at SpaceX report their jobs make the world a better place.
But of course there are trade-offs. SpaceX employees also say their jobs are the most stressful, and at $78,500, their paychecks are among the lowest in the early career stage. Facebook, on the other hand, is apparently the most satisfying place to work – 96% percent of those surveyed rated it as gratifying. Of course, Facebook is also filled with young people and perhaps they’re happier? The median age of a FB employee is 29.
At more established Hewlett-Packard, the median employee age is 38 (the highest in the survey). Interestingly, HP also has the lowest early career salary, at $65,400. But that doesn’t seem to deter people; HP employees are some of the most experienced and tend to stay around (the median number of years with the company is six.)
Wondering where the women are? eBay has the highest percentage of female employees at 43%, followed by LinkedIn, Samsung and Facebook. Least likely to employ a woman is SpaceX where only 14% of workers are female.
Of course, if it does come down to a paycheck for you, you’ll want to choose LinkedIn, where mid-career median pay was $159,600, or Salesforce or Google, where those paychecks were still over the $150k mark.
Want to know even more about how your job and salary compare the rest of the world? Take the PayScale Salary Survey.
Rapid changes in the energy industry — such as increased regulation, political pressures and emergence of alternative energy markets — have made stellar application performance a must-have for RWE Supply and Trading, a division of a leading European integrated energy company, RWE Group. Unfortunately, the business’s custom-built performance management software couldn’t deliver the wide-angle view needed to identify and fix performance imperfections.
“The consequences of these problems [could be] lost opportunities in the energy trading market or even fines for not being able to confirm positions quickly enough,” said Marcel Lichter in our recent interview about his team’s application performance management modernization project.
As Team Lead of Data Centre Management, Lichter is in charge of infrastructure capacity management and operations monitoring. RWE S&T’s data center contains 1,300 servers — 80% running on Windows, 20% on Linux and Solaris — and about 150-server-based apps. There are six internal managers, but most DevOps personnel are outsourced.
RWE Supply’s legacy performance management tools covered infrastructure monitoring mostly. “This only gave limited visibility within our application stack,” he said. The result was that during incidents, it was hard to identify, isolate and remediate root causes. So, fixes of performance losses or slowdowns didn’t happen quickly.
Lichter’s team evaluated current and near-future app performance requirements and identified the need for run-time application modeling and display, user-defined transaction profiling, deep application monitoring, cross-platform functionality and, most importantly, a shared view of all application activities.
“Being able to have a one-window overview [would] allow the different support teams to work together,” Lichter said. A new solution also had to support Java and .Net, including Oracle and SQL databases.”
Lichter found all of those features in the AppDynamics APM software suite, which needed little customization to fit RWE’s needs. “Eight out of 10 times it worked straight out of the box,” he said.
The project team identified staff members who historically were early adopters and positioned them as champions for the application teams. These leaders helped the project team implement the AppDynamics platform and acted as ambassadors during training and onboarding users.
After the implementation, “the largest measurable result we’ve seen is faster identification of problem sources,” said Lichter. “The intangible benefits include better collaboration between the different teams.”
Lichter’s next step for using AppDynamics’ APM suite is monitoring and comparing baseline performance whilst transitioning some RWE Supply and Trading applications to the cloud.
Woody Zuill is careful to say he did not “invent” mob programming. But the career programmer turned consultant certainly played a big role in at least codifying the ideas behind mob programming.
And spell out the details he did recently during a free mob programming seminar in the Boston area recently. Zuill starts on the right note, pointing out that he’s used this technique — successfully — with fourth graders. Ahem.
If that doesn’t get you interested, how about the fact that it is completely focused on the positive? “Instead of looking at what’s wrong or always trying to fix things (that) leads to having a sad failure moment,” he explains. Instead, Zuill suggests handing the power back to the people. “The people doing the work can best determine how to do the work.”
It’s like a revolution in the workplace, isn’t it? And it’s the best kind of revolution where everyone gets to drive — i.e., spend time at the keyboard — and everyone also gets time to navigate (i.e., make suggestions). Plus you can break off and do your own thing, you get to move around as much as you like and there’s enough hand sanatizer to go around. Oh, and everyone has their own comfy chair.
Those are all sort of small, almost silly things, but at the end of the day the idea of mob programming is to give the team the power, the space, the time and the rituals to make breakthroughs happen. So the focus on little things gives the chance to let the big things thrive.
The teams should decide what they want to study, and study it together, and by studying, learning will happen and problems will be solved, Zuill stresses.”This is an amplified learning environment where people are more engaged,” he says.”They’re moving around, it’s less fatiguing and the knowledge is more evenly spread when working with others. If you know that what you’re doing is important it’s more likely you’re going to be available mentally.”
This may not be for every employee, or company, and it’s probably not an everyday thing. But there’s no denying it brings a lot of brains and talents to bear on one area. And in a time where it’s easy to fall back on criticism, this is an easy-to-try antidote. “You want to turn up the good,” Zuill explains. “Look for what’s good and turn it up.”
In the midst of all the IoT hype, Claire Rowland is a well-timed reality check. A London-based UX consultant specializing in the IoT space, Rowland is enthusiastic about the opportunities. But she’s also very, very realistic, particularly when it comes to exactly how interconnected these devices are going to have to be, how it’s all going to work, and of course, the $64,000 question: how the heck do you test it all?
Right after we had this conversation, the New York Times did a story on how IoT home thermostat provider Nest did a software upgrade in December that ended up actually causing a whole lot of their thermostats to lose battery power and disconnect from the net, just at the time when temps were plunging around the country. Suffice it to say this glitch left a bunch of users cold, in every sense of the word.
The Nest scenario is exactly what Rowland was talking about. “Testing is not something I have much experience of but I can see that very quickly we are going to get to the point where it’s not possible to test all the devices out there,” she said in an interview this month. “The idea that you could release something and be confident that it is going to cooperate with lots of other products is not going to happen,” she said flatly. “I don’t know what the current thinking is in the software testing mode but there needs to be some way to figure out how we deal with this try and prevent horrible things from happening. Getting your head around this kind of system as a user is extraordinarily complicated and it’s going to be even more extraordinarily complicated as a tester.”
Rowland’s not the only one worried about this. Our expert Gerie Owen explained just how hard IoT testing at home is likely to be and suggested, in a separate article, that the sooner software testers and UX testers get closer together, the better.
But more has to happen. So I’m throwing it out there — how can testers take their strong problem-solving skills to tackle this potentially mighty challenge? I can’t wait to hear your thoughts.