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.
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.
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?
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.
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?
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.
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.
Want to tell us what your favorite go-to analytics option is?
“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.
Developers, slow applications are really not your fault. And I’ve got two examples to prove it.
And in the category of other things you have no control over, it’s time to bring Brexit in to the mix. While obviously the UK leaving the EU isn’t going to slow down your app, it may slow down your app development, particularly if your developers are in the UK. The European Union allows free and easy travel between member nations, something that’s translated in to a lot of software devs from other countries working in London. That’s helped ease the shortage and boost productivity, but things are changing, according to Robert Grimsey, director at UK-based recruitment firm Harvey Nash. “Brexit has created uncertainty,” he said. “We’ve seen it in the lead up to the Referendum, during which demand for recruitment across all roles – including software development – was down. Now that Brexit has been confirmed, our expectation is that demand for permanent software development roles will continue to stay suppressed until there is a greater visibility.”
What could that mean? More contract jobs, for starters, as companies may not want to hire permanent workers. And it could mean a hiccup — or ten — when it comes to development projects.
The bottom line: lots of things are out of your control, like third party apps and political upheaval. At a time when many are tired of hearing how the dev process is at fault, perhaps today we can all take a little (admittedly cold) comfort in the fact that we can actually identify a few of the culprits. It won’t last forever, but for right now we can try to enjoy it.
Yes, you read that title right. Too bad I can’t take credit for the pairing.
Way back when I worked for a daily newspaper, the most exciting times of all were of course the election cycles. The late nights, the meet and greets, the feeling of change in the air…good times.
It’s another election cycle — by all accounts a one of a kind cycle at that — and of course change *is* in the air still. And not just when it comes to politics.
I interviewed Will Evans, chief design officer at Praxis Flow, a couple of weeks ago. He’s a lean development expert, sure, but he’s also a fun and lively interview. I would guess his seminar at QCon was probably a lot of fun.
But Evans will always have a special place in my heart because in this election cycle he brought together two wildly different “things” and actually made it work: DevOps and Bernie Sanders.
“Imagine Bernie Sanders is the DevOps of politics — fresh ideas but fundamentally not changing the entire system,” Evans said. “People are idealists in DevOps. If Bernie can change the platform and shift the Democratic party to the left 5% that is progress but not perfection and DevOps is the same.”
Evans thinks the biggest problem in the software development arena is that people aren’t engaged and are at risk of spending their time doing things that don’t matter. DevOps, he believes, can be that change, but like Sanders, you have to see it as a process and and not an end result. “The promise of DevOps is to move things, to make things 1% better next year. That is meaningful. This is a long haul with a lot of hard work and we’re not going to have change overnight.”
Can we afford to be patient? I hope so.
Tell me how you think software development and the election cycle are linked.