Jacqueline: Today’s letter is W, and our agile word for today is working software. I’m not going to take the dictionary definition of working software. You can put the two words together, and agile or not, we know what working software is. But, we’re going to take this topic and peel back a layer or two. That said, what is working software? I love this quote off of agile-process.org. It says, “Working software is fully integrated, tested, and ready to be shipped to customers or deployed to production.” That doesn’t mean you tried it a couple of times and it ran without aborting. It means you created unit tests, QA tests and actually looked at output to prove it works. Well, that makes me chuckle, because clearly there’s a defensive posture. Someone has declared something working software without it having been fully tested and integrated.
Well, that’s when I started thinking about peeling back the layers. Truly working software, we have to think about the nonfunctionals and not just the functionals. In my training class in a room full of project managers who were trying to understand more about what business analysts and what requirements were, I wanted to make sure they understood that most people, when they look at requirements, think about the functional, the feature. “I want this screen to do this,” and “I want the report to do that.” That’s all well and good, and product owners aren’t the best source for that information.
By-and-large, they represent the voice of the customer or the end user. They know what they want the system to do, but building a system also consists of protecting the system and the integrity of the data by anticipating when people might go off script and do things that can compromise the integrity of the system. That’s what testers do. They are known for breaking the code or breaking the system. Why? Because a lot of people use systems, and there aren’t rules. You can try a lot of different things, and what software developers have to do is anticipate what you might do. As I mentioned, build software constraints to keep you within the lines.
With that said, working software has to not only focus on what we want to accomplish, but it has to protect the data, the process and the business rules that govern the system. So, when you’re testing, you have to test not just your happy path but your alternate or negative path. You have to also consider nonfunctional requirements. As a matter of fact, there are statistics that say the majority of code in software systems is the nonfunctional and exception handling. The number is somewhere between 60 and 70 percent of code. I’ve said this for years to BA’s, that if you only elicit requirements for the happy path or the most common path, the most common way people are going to be using the system, you’re only doing about 30-40 percent of your job. What it does is we spend more time in testing because they’re going to discover and test and reveal the exception handling that hasn’t been identified.
I put some words out there: functional and nonfunctional testing. Functional is the front end things; the look and feel. Users and product owners are very familiar with these items; they call them out. But your nonfunctional—just take a visit over to wikipedia.org for a very nice list of nonfunctional requirements and testing. They include things like compliance, endurance testing, load testing, performance testing, recovery testing, resilience testing, security, scalability, stress testing, usability, and volume testing. Not all of these will apply to every system, but there is some combination of these that do apply. These things are those things that wrap around or even represent the foundation on which good working software fits.
This introduces the concept of technical debt or technical runway. When you’re building software, even when you’re identifying features and user stories, product owners have to be made well-aware that it takes a combination of functional and nonfunctional or front end and technical user stories. So, you need a blend so that when you produce a release, again, you have true working software and not just the facade or the front end. We used to do this where we just built out the front end and then later on built out the back end. That was prototyping. Prototyping is building just a front end shell to get the user to react. We used to demo these prototypes. They’re not real working software. In agile, we’re not building prototypes. We’re building working software. Think about it, and share this episode with your teammates. See if you all are on the right track and page when it comes to working software.