Application Architectures and Software Development – Adam Sandman, Inflectra

This is Textron tv. Hey guys, thanks for the throw. We're here with Adam Sandman, a c e O for Inflectra, and we're talking about the modernization of software development.

They, of course, provide tools for testing software and project management software and things to help you manage the whole process. But Adam, first off, welcome Michelle. Thank you very much for having me here, Mike.

Second off, we've been talking about best practices for software development for decades, and yet it seems that every time we turn around we need to relearn, rethink, reevaluate. So is this just a continuous journey and where are we? Well, it's a, it's a great que it's a great question because, uh, in the news this, the last couple of weeks, uh, in on the aviation sector, you've had, uh, the air traffic control system in the UK go down 'cause of a bad data file that was loaded and the United Airlines had a, you know, grand stop and other IT systems around the world are just suffering from the same problems that we saw 10, 20 years ago.

And I think what's interesting is that we seem to have a lot of the same ideas of best practices, but we don't seem to be implementing them with rigor. Or we may or we, we move to the left or to the right and we lose the, the other direction. So what I mean by that is in the move to be agile, we decided that, you know, requirements go away.

We're gonna be very much user story focused. We're gonna do things very quickly. Then we realized that we quality might suffer.

So we now put place more automation, more automated quality. Me, me methods, automated testing. We try and automate some of the things that we couldn't get done before.

'cause there wasn't time manually. And then we find that the requirements themselves have issues. And so we seem to have this oscillation between sort of speed and quality.

And, and I think we've talked about this before, it's historically quite difficult to get that just right, like the Goldilocks, uh, it's either too much quality and it takes too long and it gets canceled or it's not enough quality and we deliver something on time and in budget, but then it suffers from rollout issues. Mm-hmm. Um, so I think we're often fighting the last war, as they say.

So we seem to be having that classic Goldilocks problem. And part of the issue you hear from folks too is that they're conflicted. Some part of the organization likes the old fashioned waterfall method because it's stable, consistent, and they can deliver at scale.

Other folks wanna go fast and they're more, uh, subscribers to the Agile manifesto and they tend to embrace more, uh, DevOps more aggressively, shall we say. Mm-hmm. I feel though the bulk of people are stuck somewhere between the two and they seem to be trying to stitch both together in a way that might be, um, I guess what the industry might call an anti-pattern.

But is that where we are? Uh, definitely in some organizations I think you look, when you look at, uh, just pick to pick Agile, I mean, I remember when the Agile, the extreme programming and manifesto came out, but a lot of engineering practices baked into it. And the, and the theory was that if you can do things these small amounts and you have less formal documentation, you have to balance that with, you know, pair programming with automation, continuous integration and code reviews continually.

And a lot of those engineering practices take time and are expensive. So people sort of heard what they wanted to hear, which was, oh, oh, less time writing requirements, less time during testing, let's get it out quicker. And they end, they didn't learn the other half of the manifesto, which is all about quality.

If testing is good, let's test all the time. I mean, so I think oftentimes managers hear the bits they wanna hear that lets them cut costs, um, and not the parts that improve quality. So, so you're right, they, they create an anti-patent.

Uh, another example that's interesting is the Agile Manifesto when it came out was all about co-located teams working in a very contained environment with an onsite client. Obviously we, since the pandemic, everyone's remote, most people are remote, working teams are highly distributed both by geography and by time zone. So there's a lot more asynchronous communication and that's a huge challenge 'cause Agile wasn't really designed for that.

But yet teams don't want to necessarily document things in a more formal way that maybe is better with asynchronous communication because that takes time. So I think you have to look at behind every good practice, look at what was the intent, what were we trying to solve, why do we have user stories, 'cause requirements, docs were large and out of date and never met the requirements. Why do we want people in the same room?

Because you recognize that real time communication and real time feedback was the best way to hammer out a particular feature. Now if you can't have those, you have to find new ways to do that. But I think the key is to look at what was the intent behind any practice and understand what are the other ways we can do it, rather than us adopting a bunch of practices and saying, we're gonna do Agile, so we'll do this, or we'll do waterfall as you said.

So we'll do that. But look at what is the why behind it. Um, another really good interesting example, if it's okay to mention is like requirements on our side and code AI is coming and people now want to use things like copilot to write code, which is great, can write, you know, decent dish code that you can then have a human review and find errors in and improve.

People are coming to us and saying, well, could you automate the generation of requirements, automate the generation of test cases, just put in a project description and does it all for you? Well, at some point, um, you're just creating, not, you're just creating a lot of, um, unfinished information, bad requirements and bad test cases and bad code no's looking at any of it. So you have to figure out where is the quality, where, what does the human value add into these practices?

Rather letting a bunch of machines churn out a bunch of auto complete, which is effectively what we're starting to see. So does each organization need to figure out for themselves what is the right mix of best practices? Because I feel like sometimes we do worship at the Church of the dogma and everybody says, you know, this is my one and only true way of doing things, but maybe each organization needs to just, you know, embrace things as they're needed.

A hundred percent. I mean, and, and I think that is what what good teams, teams that are are experienced and have the confidence to really explore and experiment will do that. It's often the teams that don't have the time or aren't given the time maybe to do that, where they're told, well we bought this agile, you know, this agile, uh, coach, they've come in, they've told us how to do everything and now we're gonna follow up what they said as opposed to taking maybe some advice from a coach, which is a great thing to have, but then letting it percolate and then thinking about, well the coach had these really good ideas.

Some of these things can improve what we're doing. Some of these things don't make sense for us 'cause our particular environment, our particular deployment or technology stack, um, and these, so these things will keep, but I think there, there's always this risk, a risk that you'll just adopt wholesale something because everyone else is doing it or because we paid for it or because management thinks it's a good idea or it worked in my last company. I mean if it worked in my last company, but it was a, you know, modern, no no JSS native cloud application.

And I'm dealing now with a traditional Java stack J two E that we're maintaining, yes, you can apply some of those same practices to the different stacks, but there may be compromises, there may be differences in how they they're constructed and how they can be tested and how they can be reviewed. And the quality is different, the profile is different, the cybersecurity posture is different. Those differences mean you have to look at it differently, uh, and adopt the ideas, but not necessarily all the practices verbatim.

You mentioned AI and I'm curious what your take is gonna be. 'cause it seems to me there'll be more code than ever moving through our various pipelines and I'm not seeing a whole lot of AI on the DevOps platforms themselves yet to absorb all that code moving through the system. So, um, might we be on the cusp of too much of a good thing in the short term?

Possibly. So if we Yeah, people are using AI to, to craft code snippets or code boilerplate, um, there's not a lot of code of AI yet available. It seems to, to do like the deep learning and the analysis of the code.

And this should exist. I mean, we are looking at it at our company of looking from the testing and quality side of how do we analyze the code commits, how do we analyze the previous test results? How can we find patterns where there's risk, but no one's doing much of that.

Yeah. And when we're still at the infancy, just to be honest, uh, but so if everyone's using generative ai, which is good at creating stuff, people aren't using a lot of the deep learning models, which, you know, we exist in other disciplines to, to pass all that information and find the issue. So the dangers, as you said, you're gonna use a lot of generative AI to create lots of content.

It's 80% good, but the, that 20% is riddled with errors and unknown's got the, the, the, the system to handle the volume of that. And the testers aren't gonna be able to keep up with that. And neither are the code reviewers or the people who are trying to find cyber vulnerabilities.

The static code analysis, I mean, there's a lot of tools that we use that rely on the code to be at a relatively high quality to start with. And if we're generating a lot more boilerplate code at scale, we need to have tools, as you said, that can read it at scale, interpret it at scale and flag things. Even if it doesn't fix it, it can at least flag vulnerabilities, weaknesses, risks in these different areas.

And I don't think we have that yet. So yes, it's a problem possibly. Yeah, it feels like on the one hand, the good news is we're taking a lot of developers who may not be the greatest in making them average developers.

The bad news is we've got a lot more average developers. Yep, exactly. That's exactly right.

Right. Uh, and in automated testing, uh, the problem has been to date that a lot of companies wanna do automated testing, but they can't spare the programmers to do the automated testing because they're too busy developing. So maybe if we have a greater pool of both average automated average or average machines and maybe skilled humans, maybe in aggregate we can, you know, spread that over the testing and development disciplines.

But I don't know, if, I'm not sure I'm c that's gonna happen. Does it matter where the code is written, the quality of it per se? Because not all code is equal.

So I might have some business logic where if I have bad code, there's certainly technical debt that will emerge, but there's a lot of, uh, basic code that gets written for, I don't know, script for DevOps or whatever where maybe I don't really care about the quality. So do we need to kind of, uh, decide when and where we care about quality or do we have to be on our guard all the time? Well, it's interesting when you were saying the generic code, my first thought went to, oh, you know, you think about what's the generic code when you build a new application before you get into the biz log?

It, it's like the logging service, state management, session management. And then I thought, well log four J. So, Um, The problem, I mean I I'd say absent cyber and absent load testing, maybe yes.

I think on the functional side of things, yes, a lot of these generic services don't matter that much in terms of the business logic and the, or the unique application. The danger on the cyber side and probably on the low testing side is it might be very good logging code that works generally, but it might not be highly in performant and it might be highly vulnerable. So the danger will be those percolate over a large number of systems if everyone's using the same algorithms or if the AI is generating a lot of the same, you create these systemic points where everyone's using the same algorithm that no one's checked, uh, and maybe it's not highly profiled.

So that I guess is, is the, the antidote to that is it, it could be a problem, it may not be. And then obviously on the business logic side, that's when you get, you know, cash machines giving ATM's, giving out, you know, the wrong amount of cash and people be giving the wrong refunds and the tax returns we're, we're obviously that's gonna be a much more visible issue to the end user. So will we have AI models for testing that will save us from our AI models?

Is that how this is gonna play out? I think that is gonna be at least part of the solution. Yes.

I, I think that is one of the predictions that I think I mentioned LA uh, uh, last end of last year was we'll have AI models at the right code and do requirements. We'll have other AI models that do testing and validate requirements and validate code and they should be separated. And it should be that one model should not have any internal knowledge of the other model.

Um, it's almost like on the old space shuttle, maybe dating myself, you know, those four computers that all had to check everything and they were independent and if any number of three or less didn't agree that they couldn't, they couldn't complete the mission. So it's almost like we'll have that situation, we'll have multiple ais potentially finding inconsistencies and then they'll flag it for a human to be able to review. I mean, that could be one of the outcomes.

I don't know. Well then ultimately be a better situation than we have today. 'cause I feel like the first thing that gets cut from any project is the testing.

And the second thing that gets cut is the testing. 'cause nobody knows how to create the test in the first place. So they're kind of like, well, somebody else will do it, I hope.

Yeah, that is the, that is definitely the case. And even some of the testing is being pushed with shift left. The theory of shift left in DevOps was you, you move some of the testing into early development to find the risks so you can then spend more time on the right areas later.

What happens is people shift left, do the, develop the testing and development and they cut all the testing to the right. And that's like, no, that wasn't the idea. It was shift test early to find where to test later as opposed to test early and then not test later Or just make the team more efficient.

It seems to me that a lot of the testing teams spend their time chasing down rot stuff that should have been caught earlier anyway, so mm-hmm. They might actually be able to test something that's more interesting or more of an edge case that could have a big impact somewhere down the road. Right?

Definitely. Yeah. I mean that, that should be the, that should be the ideal.

Developers should be writing your automated tests, even doing the basic manual testing. It should all be done before the branch gets, your branch gets merged into the main development branch. That's what should be happening.

Um, cyber's forcing some of that. It's interesting. We, we've gone through a SOC to audit recently and SOC two and some of the other ISO standards, which are more cyber oriented are signed to force people to do more, I think more, more rigorous code reviews and merge reviews.

So I think as a byproduct of some of this, the vulnerabilities, it's making developers and, and a bit more accountable to the testers. Uh, it's as, again, as a byproduct, I think of the cyber, uh, worries that people have had around code libraries and about, uh, having to, you know, follow these audits that are taking, you know, a lot of the SOC two and ISO standards come from a, a quality lens. And so even though they're not necessarily, you know, they're, they're employed just for security, but the reality is it makes the overall code base better because there's practices you need for, for a security audit, tend to force developers and the testers to have more rigorous gates and reviews, even in an agile environment.

At least that's what we've seen. When you kind of put it all together, you can't help but wonder, um, are we gonna be looking at a scenario where ultimately the quality of the code will improve. But also, you know, today we mentioned cybersecurity, it's a separate gate, but, and you have to scratch your head sometimes and wonder, well, why isn't cybersecurity just part of the larger quality conversation?

So will all this kind of just merge together at some point? Um, that's a, that's a big topic, I suppose in theory, yes, if all developers were trained in, in cybersecurity, uh, and you know, and, and everyone's supposed to be aware of the, the top 10 osp, you know, zap vulnerabilities. Uh, people don't always know them in detail.

You know, they sign up for, I'm aware of them when I'm coding. Uh, it doesn't mean they necessarily know them in detail. The other thing is the threat landscape evolves so quickly that I think what you want to do is transition the knowledge of the current threat landscape to the developers, and they should be in charge of the quality.

I agree. But then you need to have this, the cybersecurity folks, uh, learning what the next threats are before they come out. Uh, we send people to DEFCON every year, and if anyone's watching the show, who's aware, not aware of defcon, I would definitely say sending members of your cyber or development team or both to Defcon is a great, great investment because you're gonna learn that the threats of tomorrow, so that even if your, your main development team is working on and it's absorbed the knowledge and is able to do a lot of the threat analysis and the code analysis and vulnerability modeling in the current code base, having people whose job is to look beyond the horizon to the next evolving threats is really important.

I think that will always be separate from the, the development team or the testing team. Um, but they should obviously work really closely together and make sure there's lots of knowledge transfer. All right.

When we started talking about modernizing software development practices, what's that one thing you see organizations doing today that just makes you shake your head and go, folks we're better than that. When they come to me in a, in a meeting and they say, you know, Adam, we don't have any requirements, and I get that a lot, and I'm like, oh no. So basically, if there's no requirements, start heading for the exit because now you Yes, the project will never end, right?

It's just forever in a day. It's crazy, but it's a true story. Many times we don't have requirements.

We have user stories, we don't even have those. We just write tests, we write code and then we check it with the marketing team. Or like, but, but who?

But someone's going to figure out what's right and how do you know? We're like, oh, well we don't like requirements. Okay, Folks, well, you heard it here.

If you're writing code for code's sake, chances are things are gonna go bad. Hey Adam, thanks for being on the show. Thanks so much, Mike.

Pleasure to be here. All Back to you guys in.