What software developers should know about 2021: Low-code, AI code testing, COVID-19’s lasting effect and the skills needed to stay on top

Forrester made 5 predictions for software development in 2021. Bill Detwiler talks with software industry veteran VP and principal analyst Jeffrey Hammond, the report’s lead author, about what developers and IT leaders should expect in 2021.

Image: Forrester

Bill Detwiler: All right. So Jeffrey, you were the Author and Lead Analyst on a set of predictions that Forrester just put out, 2021 Predictions Around Software Development. And I know we’re going to talk about low-code and no-code here. But before we get to that, tell me about how Forrester puts together these predictions, and how you come to the conclusions that you do in this report?

Jeffrey Hammond: Yeah. I think lead author means herder of the cats, because what happens is our team gets together, there’s about eight of us, and we descend into a metaphorical mud pit where we all have opinions. And imagine that, eight analysts with strong opinions. It’s almost like saying it’s an opinion of architects. That’s what we’re talking about.

And so we battle it out. We say, “I’m seeing this, and I think it’s going to be a really big deal next year.” And then John Rymer, recently retired, says, “I see that and I think it’s going to be big.”

Now, the challenge is that we only get to pick our top five. So if you’ve got seven or eight analysts, that’s less than one per analyst. So, we put these together, we really knock them about, and we come up with the things that we think are really set to move the needle in the next year.

This one was particularly fun because there are actually some fairly strong opinions about some of these predictions. And I’m not sure that we’re all 100% on the same page, but that’s what makes the exercise a really valuable one from my perspective.

1. AI and ML will make test automation smarter

Bill Detwiler: So how do you actually decide which prediction to go with when you do have those competing ideas? Or maybe you do, I mean, you don’t duke it out in a boxing ring. Or is it work like the Supreme Court, where you’ve got different justices voting? How do you actually come to a consensus or at least pick a winner?

Jeffery Hammond: Yeah. Maybe there’s the virtual equivalent of firing briefs back and forth. But let me give you an example. So, one of the predictions that we put up there was, at least a third of test professionals would use machine learning to make test automation smarter next year. There’s a bigger conversation in that world. The conversation is really around the role that AI will play in development moving forward.

Now, there are some folks that will basically say, “You know what? In five years we’re going to have AI writing code, and that’ll make developers a lot less in demand, because a lot of the basic infrastructure code that we write today is something that can be automated and written by a machine.”

There are others of us that will say, “You know what? All that’s going to do is end up creating more software that developers have to maintain.” And then, “Yeah, we really can’t see demand for good developers collapsing anytime soon.”

So you put those two extremes and you have a really robust discussion. And what you do is you go back to the research, and you go to the data and you say, “What are we seeing? What are clients doing? What are vendors telling us that is over the horizon?”

And you go from that, “AI is going to make developers obsolete versus AI will never make developers obsolete to well, one of the areas that AI is really beginning to have an impact is in testing.”

A lot of developers don’t particularly love the idea of going out there and writing automated test cases. It’s not what they want to spend their time on. They want to build business functionality, they want to solve problems. They want to drive business value.

But you know what? Those test cases have to be written. So it’s a great example of an area where developers would like for the machines to do more, where the machines are capable of doing more, where we see evidence of tools and techniques that are out there doing more.

You put that together and you say, “Well, if we extrapolate this trend, we see that only growing as we move into the next year.” I don’t know if that helps or not, but…

2. 75% of dev orgs will use low-code platforms

Bill Detwiler: No, that’s a great explanation because it leads me to my next question, and what I really wanted to talk about most which is the low-code, the no-code movement, because that’s another one of those technologies.

Jeffrey Hammond: Oh, the lightning rod of low-code.

Bill Detwiler: That’s right. It’s another one of the technologies feet, like you were talking about with AI, that will have a dramatic effect or could have a dramatic effect, depending on who you ask, on the application development landscape going forward.

You were talking about how AI can be seen as augmenting what developers are already doing and actually taking over something that maybe they don’t like doing. So in that way, it’s complimentary, it’s not adversarial in terms of a zero-sum game. Either we have AI doing this, or we have developers doing it.

And so that leads me to the low-code, and no-code prediction that you’ve got in here. Are developers still going to be as necessary to write code, when you have business end-users or other non-programmer business professionals writing code? Or you’re still just going to have all the code to maintain? So what is the prediction that you all were making for 2021 around low-code, no-code?

Jeffrey Hammond: So the specific prediction is by the end of the year, 75% of development shops will deploy and use low-code solutions. So notice that it’s not 75% of developers. So if anybody at the organization is using low-code, then that counts in that 75%.

In some ways, I feel like for as long as I’ve been a developer, which is almost 30 years now, this idea of forced polarization is something that we’ve had to deal with. And in some ways I feel like low-code has been one of those areas that has been that way.

I came in as a finance major, right in PowerBuilder code at very large organizations. 4GLs back in the early nineties on Windows. How different are those 4GLs from some of the low-code tools today, conceptually?

If we had to drop to see, we had foreign function interfaces that we could call to do things like read blobs. If we needed to get access to databases, we’d go talk to a DBA and say, “I need you to write a stored procedure that takes these arguments and returns this data.”

And a day later, they’d come back and do that. So fast forward 30 years, and today’s Mendix or OutSystems or Power is doing that, except maybe it’s calling a serverless function. It’s calling a Lambda, or it’s accessing an API that is being run by a container on top of a Kubernetes cluster.

To me, the real value here is the idea of what level of abstraction do I want to work at. And that’s where no-code and low-code come in, because from a no-code perspective, there are users that have to work at a certain level of abstraction, because they don’t have the knowledge to go any deeper.

And that would be somebody that might use a no-code required tool. Everybody has to start somewhere, but even professional developers will sometimes choose to work at a higher level of abstraction because of their goals.

Maybe I want to use Lambda, because I don’t want to deal with the autoscaling of clusters in Kubernetes. I just want that to happen so that I can focus on business logic. Maybe I want to use a Mendix or an OutSystems because you know what? I got to get a tracking and tracing application out in three weeks.

Or the business needs to implement curbside pickup, and every day that we don’t have it, we’re losing millions of dollars because our retail establishments are closed. That’s what we saw with low-code in 2020. That they were used in a lot of these situations where speed was the most important thing, and because of that, developers chose a higher level of abstraction, and they got applications out.

To me, I think what we need to do, is we need to look at what we’re seeing here as much more of a spectrum from high levels of abstraction, to low levels of abstraction and understand that a business will engage at multiple points on that spectrum based on what they are trying to accomplish. And I think that there’s a place for low-code in every organization, if you look at it that way.

SEE: 5 developer interview horror stories (free PDF) (TechRepublic)

Bill Detwiler: If you’re someone talking to developers, so frontline developers, coders, who are looking at no-code and low-code and thinking, “How is this going to affect me, and how should I prepare for it?” What do you say?

I get what you’re saying from an enterprise perspective, and even from looking to emphasize speed, but if you’re someone who’s a new developer first year, you’re still in a college or some type of training program that’s learning to code, what do they need to know about low-code and no-code, and how we think it’s going to affect the jobs that they’re doing, looking for next year or doing next year and even five years from now?

Jeffrey Hammond: I think one of the things that it’s going to do is something that we had in one of our other predictions, which it’s potentially going to change the way that we organize the software development teams.

In a classic IT shop, all the developers are in the IT organization and they roll up to the CIO, and maybe they get requirements from the business, or they speak to a business sponsor every couple of weeks or something like that, but there’s a very siloed organization.

As we’ve seen more and more organizations embrace Agile at scale, they’ve started to put product owners on those teams, and those product owners might come from the business, but still they’re fairly technically self-organized.

As you start to see more business developers get involved with development via low-code, I think you’ve got the potential of seeing even more hybrid teams where developers get embedded inside the business organization, either via matrix management or even aligned or assigned to those organizations.

So imagine a world where instead of a business user may be giving you a sketch, or giving you a requirements document, and as a developer, you have to interpret that. Imagine a developer may be actually doing some of the wireframes or a business user, and doing some of the UI.

Because what I tend to find is that the business really cares about the pixels, and they care about how those pixels work, and they care about how those pixels flow. They don’t care about how the APIs are structured. They don’t care about how the Kubernetes clusters are stood up. They don’t care about how the functions autoscale up and down, they just care that that works.

And so I think as a professional developer, one of the things that that means is that, we perhaps start to focus on the technical qualities of the system a little bit more, and we get a little bit more help from the business in terms of the functionality and the value that we have to deliver, and maybe even some of the comps or the wireframes that we’ve had to interpret in the past.

You might even see that from a less low-code world, as we start to see more and more organizations talk about design systems, where they articulate how the system should look and act, and there’s a little bit less of a workload on us from a development perspective from a front-end.

So is it going to completely say, “Well, front-end developers aren’t needed,” absolutely not. Hero, mobile applications, customer facing applications, you’re still going to sweat the details and look for the affordances there. But maybe for some of the employee facing applications, we can do more of the front-end work with these combination hybrid teams. Does that make sense?

3. Cross-functional teams will become the norm and require new management methods and tools

Bill Detwiler: Yeah, it does. And it’s something that flows into one of the other predictions from the report, which is talking about cross-functional teams, and talking about collaborative work management. Talk about that prediction in more detail please.

I’ve seen and I’ve talked to people that are in application development orgs, that are describing the same thing. And I’ve seen that personally on a pendulum move back and forth in my 20 years in technology.

So talk a little bit about that, and it seems to be exactly, like you say, swinging back towards the, “Hey, we’re going to embed developers. We’re going to put them closer to the end users, as opposed to part of these monolithic IT organizations.

But that’s sometimes not an easy transition for some people to make, right? It requires a little different skillset. I mean, I remember going through school and engineering school way back in, and it was much more about, “Okay, you’re an engineer, you’re going to work and…”

I was an engineering mathematics and computer science major way back then. And it was, “You’re going to work on your own. You’re not going to have a really big team. Maybe you’ll get inputs from some other groups, but it’s going to be you, and it’s going…” And that’s-

Jeffrey Hammond: Put them in an office and give him Jolt Cola and slip pizza under the door. That’s all you need, right?

Bill Detwiler: That was it. But that’s completely and utterly…it was different. And that wasn’t the way it was just five years later. And there was this back and forth, this push and pull from professors, who came up in the… I’m dating myself, …the 60s, the 70s and the 80s, and still had those mentalities, and some of the newer people who had come along maybe in the 80s, and now we’re moving to the 90s.

So talk about number one, the prediction around cross-functional teams, and what developers should really be thinking about in terms of how they make the transition, and develop application development leaders, and how they make sure that their staff makes the transition success?

Jeffrey Hammond: Right. I think it’s really important because there are more demands from a cultural perspective that get placed on developers. And for years, we’ve basically said, “Hey, look, tools are great, but if you don’t have the right development culture, you’re not going to be successful with respect to Agile and with respect to increasing velocity, and that’s for the developers as well.”

About 10 years ago, I wrote a piece on the best practices of high-performance development teams, and so much of that is still on point today. It basically picked up on the work that Dan Pink had done in the mid 2000s around intrinsic motivation, and basically made the case that development is a creative profession, and it’s a heuristic profession.

And so you want developers that are capable of expressing creative thought, of taking autonomy for their actions, of working in a culture of mastery and in buying into shared purpose. And if you have those things, then they want to feel empathy for the end user. They want to learn about what the user wants. They want to learn about the new technologies that are going to satisfy, and deliver the value to that user.

And it works all the way up into culture. I’ll give you an example. I have had a conversation with Amazon over the years, and one of the interesting things about Amazon is only about 10% of their service teams actually have a product manager.

And those are the services that are exposed externally to customers. The other 90%, the engineering manager is the core linchpin of the team’s organization. So that engineering managers probably come from a very technical background, but yet that team still gets measured on the amount of reuse for the service that they create in the rest of Amazon.

So if you’re getting measured on reuse, how do you make sure that your reuse is good? You go out there and you understand the needs of others. You figure out what your team needs to do to make sure that other teams can get value from the effort that you’re doing. You’re essentially acting as a defacto product manager.

And so these things, empathy and autonomy are critically important to success. So if you want as a developer to have a career path that goes into that engineering manager type of role, or begins to go up the career chain at some point, it’s not just the technology that matters, it’s also those other softer skills.

So you can put me on that side of the argument that you talked about. And so as these teams start to get more cross-functional, the ability to work with a product manager that may not have a technical background, or may not have a technical degree and be able to translate what they are trying to accomplish.

The ability to work with a business user who can draw what they want, or sketch out a screen design, but not understand that the piece of information that they’re looking for is actually quite difficult to pull together from all those existing systems that you have, that may not even be capable of providing real time data, and have that conversation in a way where they don’t feel belittled, or they don’t feel marginalized, I think is critically important.

And what makes it even more important, gets to one of the other predictions that we had which is, we’re not getting back into the office anytime soon. The idea of physical colocation as a way to smooth over these challenges, and as a way to be able to see what other people are thinking, as a way to have high bandwidth conversations, we’re not going to have that as a luxury.

And so while for years we’ve said, “Culture is critical, organization is critical. Tools, they can help, but they’re not as important as getting these other things right.” We almost have to do a 180 degree turn on that.

And so when we talk about things like collaborative work management tools or a value stream management tools, the reason they become more important now than ever, is because so much of what we have to do now has to be done through digital mechanisms.

I’ll give you an example, Microsoft. Amanda silver, had a presentation about how Microsoft has adapted to a fully remote culture right now. And one of the things that she said is, “We need to be able to ship from anywhere.” That wasn’t something that they had done before.

And so value stream management is one of those things that if it’s implemented right, and the tools support it, developers can ship from anywhere. They can push from anywhere, they can build from anywhere, and so that enables these teams to be even more autonomous than maybe they have beforehand.

Collaborative work management is the same way. It enables high bandwidth communication, so you don’t have this top-down project portfolio model, where everybody is waiting for the project manager or the program manager to make a decision, and then they move forward.

It allows teams to have high bandwidth conversations, even if they’re not in the same pod anymore. So it takes the convenience of physical colocation, and replaces it with what I would call spiritual colocation. The teams, even though they’re not next to each other, can still engage in high bandwidth collaboration, which is critical to Agile success.

SEE:
How to become an effective software development manager and team leader: Tips and advice from Drupal founder Dries Buytaert

(TechRepublic)

Bill Detwiler: How do you do that and not overload people? Because I think with endless meetings or 50 Zoom calls a day, or Teams or Hangouts or WebEx, or whatever your platform of choice is, how do you do that without overwhelming people with too much communication? What’s the right balance?

Jeffrey Hammond: I put a lot of that on the managers to set the right tone. Stack Overflow, recently had a piece that they wrote in the Journal of the ACM, where they wrote about some of the practices that they’ve discovered.

One of those which really stuck out, was leaving an open video conference on all day, even while folks are working. Most of the time they’re muted, but if somebody has a priority interrupt or they have a question or something like that, everybody’s there, so they can just ask it.

And then if somebody has the answer, they can respond very quickly. It’s not that different than the popping your head up over the pod, and saying, “Hey, anybody know what to do about this?”

So it’s not like they’re actually… It’s passive collaboration. Little things like, “Make sure that your status is actually accurate as to whether you’re disturber or not and then respect that status.” So little things.

From a management perspective, I think it’s recognizing that as we go from a sprint into a marathon, that this initial burst of productivity that we got, because people weren’t doing two hour commutes anymore, and they were committing in the evening or on the weekends, when they weren’t being able to go out and have social time, or see their friends is not sustainable.

And that we are going to see impacts, and that we should expect that, and if we’re not seeing those impacts, if we’re still seeing people working at a higher level of productivity than normal, maybe it’s time to step in and say, “Hey, you’re committing on the weekends. You really shouldn’t be doing that.”

“Let’s make the weekends the weekend, and let’s make sure that we’re dealing with this from a long haul perspective.” I think monitoring burnout symptoms is really critical right now for managers in dev teams.

SEE: 10 ways to prevent developer burnout (free PDF) (TechRepublic)

Bill Detwiler: And that’s something that I know, or at least from my experience can be difficult for teams that maybe are highly… And this is a complete overgeneralization. So I’m not saying everyone is like this. It is the sense among folks that I know, especially if you have teams that have members on them, who aren’t very communicative in terms of getting that feedback out.

So as a manager, it’s hard to see those signs until something really bad happens, until you have an incident. And I’m not saying it’s not the manager’s responsibility, it doesn’t take the responsibility off of them to look for those signs, but it can be harder to spot if you have people who number one, aren’t communicating or accustomed to communicating, and then you have the added barrier of no physical proximity, where you don’t see the body language.

And I get what you’re saying about meeting, and you have the added challenge of leaving a Zoom call on, or a video call on all day long. We’re not at the office. We are in people’s private houses, and we’ve seen the horror stories on the news of people yawn accidentally, or having things happen on their open video calls that maybe they didn’t want to happen, so it is a tricky time for managers.

If you’re a development manager or if you’re an individual contributor, a team member, what do you recommend that they do in terms of making sure that type of maybe communication is happening regularly?

Jeffrey Hammond: Mm-hmm (affirmative). Well, I think one of the things is to budget more time for social interaction. I’ll give you an example. Our team meeting has tended to be once every two weeks, classically. My boss moved it to weekly, but it’s not like we’re doing twice as much stuff.

We’re adding more time for just a little bit of socialization. How is everybody doing? What are you doing? How are things going? I know a lot of the startups, historically when everybody was colocated, they would have breakfast and dinner, and they would eat together and that sort of thing.

So we can still have beer together on Friday, if that’s the type of culture. We can still talk about our 10% time projects, if you’ve implemented 10% time. The goal is to make the effort to still drive the level of social interaction that you would get in the office. If you can’t get to the whole way, just make sure that you’re doing as much as you can as a manager.

One of the things that we’re seeing is that more and more organizations are adjusting their measures. So there are measures like engagement. Imagine serving your developers on a regular basis and basically saying, “How are you doing? How satisfied are you?”

And looking at the Net Promoter Scores for the development organization. The fact that managers are even caring about that is a great sign, because it’s an indication that they view talent as a strategic issue that they should be looking at. It’s not Fred Brooks, Mythical Man-Month, get one developer out, throw another one in and put them into the meat grinder, so that’s good.

I think that there are things that you can do by watching Flow Metrics and even time of day commits, if you’re using something like GitHub or using something like GitLab, and get a sense for whether or not the day is extending beyond the range of when it should. And so those would be the kinds of things that I would say are investments that are well worth considering as you go into 2021 from a management perspective.

4. IT modernization done under COVID-19 must continue

Bill Detwiler: So I think because you touched on it earlier, COVID really isn’t going away in the U.S. anytime soon, unfortunately. And that we’re probably going to be under some sort of altered working conditions well into, if not all the way through 2021.

And some of the changes that organizations have put into place now are going to stick around even longer than that. Not because of the pandemic, but because they’ve realized that they make sense for a lot of reasons.

Let’s talk about those last two predictions that you have, that specifically taught to talk to that. One is around modernization, and the other is really around reaching this clarity around mesh technology. Start with modernization. What are you also predicting in 2021 around that?

Jeffrey Hammond: Right. So one of the things that happened at the start of COVID is in industries where revenue just dropped off a cliff. Travel and transport, as an example, retail. We Saw budgets impacted. I mean, you would expect that to be the case, and as a result, a lot of folks put some of their modernization efforts on hold.

It’s like, “Doesn’t matter if we have to transform this stuff, if we’re not going to be around in two to three years.” On the other hand, we saw some organizations basically say, “Look, damn the torpedoes, full speed ahead. If anything, we have to move faster to survive. We have to double down on our E-commerce initiatives. We have to double down on things like in-store pickup or local delivery.”

And so that created a little bifurcation of the haves and the haves nots. Now, as we move into the marathon stage of this, the companies that basically put the brakes on face an existential crisis. They either have to restart these programs, or basically say that the gap between the folks that have pushed the pedal, and them is going to get larger.

Jeffrey Hammond: So as a result, we do expect to see budgets come back, and that’ll especially be the case as it becomes more and more clear how they can modernize. As we see people begin to demonstrate more success with deploying containers at scale, as we see organizations figure out ways to be able to scale service-based architectures, using things like a service mesh, or even some event-driven constructs.

The patterns get clearer, which means that the laggards can start to move after the first movers, by implementing the patterns that those first movers have discussed.

So net net, I think we’re going to see a lot of focus on… Loaded buzzword here, …cloud-native architectures, whether its hybrid cloud or whether it’s public cloud. I think we’re actually going to see quite a bit of experimentation with the hybrid cloud architectures on-prem, especially as organizations start to unlock some of these core workloads that they’re trying to modernize.

That means solutions like OpenShift, like Tonzu, even Anthos, are something that a lot of these organizations are looking to push pretty hard to see exactly how much they can get out of them, as they start to modernize in place.

Getting things into containers is that first step. You declared victory, and then you start with your Strangler Patterns or your facades, and start breaking up those monoliths. Maybe not all the way to microservices, maybe to mini lists as a starting point.

But a lot of that blocking and tackling is just going to have to be part of the implementation efforts for 2021. And that’s where we do think that service meshes will show off some of their capability to provide assistance in that execution of monolith strangling.

Skills software developers will need in 2021 and beyond

Bill Detwiler: So what should developers be looking at for 2021? We’re in November 2020, we’ve got two months left of the year. What should developers really be looking forward to in 2021? I mean, we’ve talked about so much, but if you had to name just a few things. You’re sitting there and you’re wondering like, “Hey, I’m looking at different possibilities for either my own career or where the industry is going.”

We talk about languages to learn, but if you’re thinking a little bigger picture, what are those big trends that you would… One or few two things that you think developers should really look out for, read up on and prepare for next year?

Jeffrey Hammond: If you don’t have a firm grasp on the role that containers play as part of developing and delivering software, I think you need to get there as fast as you can. It doesn’t necessarily mean that you have to go full on Kubernetes and start learning all the intricacies of YAML, and become a networking expert.

You may, I mean, there’s a lot of demand for that, but at a minimum, you need to understand how containers become the default handoff. Whether it’s a Kubernetes world or an ECS world, or even other runtimes.

Also, I think it’s worth understanding how the front-end is evolving. You’ve got lots of interesting things happening right now, whether it’s React Native, and React in View or the Flutter framework, and the role that they play in both mobile and web development.

You’ve got exciting changes in the way that we think about writing front-ends with things like the JAMStack. So there’s lots of opportunity to sharpen your skills, and look at what organizations are doing in that area. I think there’s going to be a real explosion in the idea of taking compute, and storage out to the edge in some of these cloud-native architectures, as we move into 2021.

We’ll be taking a look at that in an upcoming wave, so that’s pretty exciting to me. So I think there’s lots of opportunity as you’re looking to what skills should I be learning in 2021 and beyond, to create differentiation in your skillset and therefore demand for your talents.

More Dynamic Developer episodes and related resources