The Agile Manifesto: Simplifying Software Development

This is Building Better Developers, the Develop-a-Noor podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge, and embracing life. Let's dive into the next episode. Well, hello and welcome back. We're continuing our season where we're looking at the Agile Manifesto and how we can take principles that they lay out and apply those to our work and how those will affect us and impact our ability to not only become a better developer, but produce better software to have an end result that is, you know, call it better. Now we are getting there. We are into the 10th principle this time around, and we're going to dive right into it. It states, quote, simplicity, the art of maximizing the amount of work not done is essential, end quote. Now this is interesting because they actually define simplicity in a very, I don't want to say completely non-intuitive, but I don't think it's the way that people normally think of it as a non-standard way. They define it as the art of maximizing the amount of work not done. Now, obviously this is simplicity with the context of doing something, of creating a project, creating a solution. But it focuses on, usually we think of simplicity as just not having a lot to it. Simplicity would be less as more. But this one twists that a little bit and focuses on it being the maximizing the amount of work not done, which is, you know, it's a 180 degrees different point of view from, I think, where most people look at it. Simplicity often is, I have a small amount of stuff and doesn't focus on the very large amount of things that I don't have. Simplicity I think often is, well, here's what I've got, and it's not a lot, or it's simple versus actually there's a lot of stuff that I don't have, which is why this is simple. This point of view, I think is critical or essential as they state in their word, is essential to building software in the most efficient way. I think one of the biggest challenges we face is the open-endedness of software, of requirements. We literally could set up requirements that is everything, that includes everything, that is software that also has to do the dishes and put out the laundry and call the people we need to call and set calendars. I mean, there's all kinds of stuff. You could pile in as requirements or features or nice-to-haves or bells and whistles. You can literally start writing out a solution, start coding, and never stop. Now, it's going to be very difficult after a while to get all of that, cram that stuff in, but you literally could do that. We have to set constraints. I don't think we think of it that way very often because I don't think anybody goes into any project with the stated or even unstated but intention of we're just going to ask for everything, capital E, I guess, everything. But I think there are situations where people will come in and look at a project, at a solution, at a problem and say, well, I've got to... Basically they group a lot of problems together. Well, while I have your attention, I also need you to do this and this and that and this other thing. So while everything is not usually going to be on the table for requirements or for a project more than is needed, often it's going to be part of that. It's going to be on the table. This is actually not focused as much on the requirements, although I use that as an example. This is not really focusing as much on the requirements as it is the work that goes into the solution. The requirements, I think, are a little easier for us to see. I could add a requirement of every method and every property that you include within the software has to include boilerplate that says who wrote it, when they wrote it, what was the start time that they started coding it, when was the end time that they completed it. I could say that something's required. I guess there could be a situation, there may be a situation somewhere where there's a business or regulatory requirement for something like that. There are definitely levels of that required for change control for some places, some organizations and some of the other audit and other things that may show up. That's not necessarily a huge burden, but maybe it is. It is additional work. That would be not simplifying. If you remove that work, then you're simplifying. This is, there's a lot of assumptions within this, which I think we need to make sure we agree with. Not that they're necessarily completely arguable, but that we are cognizant of it, that we are thinking about those. The art of maximizing the amount of work not done assumes that there is some level of work that has to be done. I guess you could maximize the amount of work not done by just doing nothing, but that's not really what this implies. This implies that we've got to do some amount of work to provide the solution. Leading to that level of work is our goal, and that is part of what Agile is. We have touched on this in some of the other principles that we've talked about, where there are things that we have to do. There are things that are either a requirement for the problem itself or a, I will call it a secondary requirement, which is in order to support or complete these, to address these requirements, these other things that are not direct requirements also need to be done. If you think of direct and indirect requirements, there's a certain amount of stuff, there's a certain amount of work that needs to be done on any given project. In most projects, there's also work we do that is not necessary. This goes back to that idea of work that directly supports or points to requirements and both stated and unstated or primary and secondary requirements. Doing this work that is required, that's our bare minimum. There's certain stuff that has to be done, period, to get to a functional product. I'll add with that because this is an ongoing theme, not only to have a working product, but to satisfy the customer. This is where we get in. We've got a lot of gray areas that we're talking about here. What is done? What is really the solution for the problem? What satisfies solving the problem? Then an even more gray area is what addresses the goal of satisfying the customer because that can be a squishy goal to shoot for. This is where the simplicity comes in. It really is, if we're focusing on the simplicity, then it means that when we go into our day and we have work that we're going to do, that part of what we do is look for ways to remove some of that work. Is there work that we're planning on doing that we don't need to do? If so, don't do it. That is simplicity. The more that we can reduce overhead and extra work that does not contribute to satisfying the customer and providing a working solution, then the faster, the more efficient we're going to be. This definitely comes into play when you think about the administrative side of software development. There's some level of this stuff like documentation and things like that that are not directly part of implementing the solution that still are needed. We have to in order to communicate and track and score ourselves and put ourselves on a path to become better. They're just things we need to do. I guess technically you could say that testing is not required because if you wrote it all for 100% correct the first time, then you wouldn't have to test it at all. You just know it works. We know in reality that's not true. We know that there are bugs, that we are not perfect, none of us, so we make mistakes or even if they're not mistakes, in coding there can be mistakes in requirements and things like that. Based on that there's got to be some amount of testing. If you think about that, testers will talk about things like code coverage and things like that. Depending on what the application is, I was going to say it's not possible, but I guess there are some situations where it is possible to test effectively every combination of stuff that can be thrown at the application. Then I don't think it's possible to test all of the potential environments that it may be attempted in. If you listen to QA people, there is an accepted target where they're going to come in and say we'll test this and we're going to do enough testing to be reasonably confident that we have found the main bugs, that we have stumbled across the bugs that people are most likely to hit. Yes, there may be outliers, there may be some additional things out there that we may not get to. That means that there is a give and take with that. There is somewhere built into that a sweet spot of the right amount of testing, testing the right pieces and not doing more than is needed. Running that one extra test that essentially duplicates one that you've already gone through would be extra work. Finding the shortest path of combinations of tests to get you to the level of coverage you want. That's just testing. This same sort of finding the sweet spot occurs in every step of the software development process. We could go from requirements into design and we could overdo our definition, our details about requirements. We could overdo our design. We could over architect our solution. Our implementation can be we maybe write more code than we need to or have the code do more than it needs to do. All of those will cost us in time and general resources to get the project done. It's interesting that this one starts with the one word. It's got a couple hyphens to say, hey, we're going to define this word. It really comes down to simplicity is essential. Now they add the definition there, the art of maximizing the amount of work not done. But if you take that definition out, simplicity is essential. I think that's something that we can get lost with that sometimes. We can get sidetracked by the things that we could do. This is not just when we talked about changing requirements and things like that. This is not just the customer changing requirements. I have been in many development teams where developers will say, hey, we can do this little thing or we could add this little thing. Basically it's couched in the, it wouldn't take much extra effort to do this little thing here. Then we can add this feature and then we can make those customers that much more satisfied. That may be true, but it may also be something where the cost is not equal to the benefit. Or the cost is not one that we really need to add. It doesn't make sense to add it to what we're building. Because sometimes when we change the feature set in order to satisfy the customer more, we also are inadvertently increasing the scope of the requirements. And while yes, we're giving the customer more than they asked for, it may be that that was really not needed. That really we increased scope when we really didn't need to do so. I think an example that hopefully will sort of be direct enough, be obvious enough, may be useful here. I worked on a project a long time ago where the idea was, the short of it is, the original proposal was more than the project lead thought the customer was willing to pay. So instead of just arguing for those features, this is what it's going to cost to do it. He instead said, hey, let's go back and let's add in changing the look and feel as far as just like colors and very surface level stuff. Instead of what we were going to do, we're going to go in and we're also going to change all these background colors and button colors and things like that. Really just colors across the application. And in doing so, that's going to make it look different and we're going to be able to convince them that with that different look, that's some of that extra value that they get for that same amount of money. He effectively said, we're going to increase the work we're doing because we're going to go in and we're going to do all of these color changes and stuff like that. And we're going to essentially provide them the same solution. Yeah, there's really, there's no difference other than the color scheme. So functionally zero difference. Look is a little different. And this is not like based on user experience or anything like that. This isn't moving around stuff. This isn't changing labels or anything. All this is doing is changing colors. So it's really surface level stuff that does not contribute to the bottom line. And I don't think really contributes even to the idea of satisfying the customer because what we've really done in that case is we've expanded their scope where they said, this is what we want solved. We had a solution and we've essentially tacked on, oh, and we're going to change the colors, which would be effectively going back and changing the requirements. They laid out all the requirements. We added the requirement of change the colors. That is in a nutshell, what we're talking about here. Simplicity is essential. We went the opposite direction. Instead of simplifying, we added, we added complexity. We added additional work. And that was work that we really didn't need to do. So if we'd simplified it, we would have maximized the amount of work not done, which means we would have pulled that back out or said that doesn't contribute to what we want to do, so we're not going to do it. It doesn't contribute to the end objective, so we're not going to do that. And while that is a somewhat extreme case, I think we find this stuff all the time. If we're sensitive to it, if we're looking at what we're doing and how we are approaching building software, there are bits of work that we do that we can say, you know, we don't really need to do that. And the better we get at that, particularly not doing the things that are essentially not adding value or not adding the right amount of value or not adding value in the way that we want to, the more that we simplify that, the more efficient we're going to be. And then to some extent, the more likely we are to satisfy the customer. Sometimes when we give them more than we want, all we do is we complicate their experience. And now it goes from maybe something where they could have, I don't know, entered a label and pressed a button to something where they've got this big complex navigational scheme and all this other stuff. And you can see products that have done that. If you look at, go back and look at the history of Microsoft Word, particularly if you look at how it was received, there was a point where they made a huge jump in menu items and options. They added a whole bunch of features. And a lot of people complained because they said they couldn't find the things that they wanted to do. Now, I think over time, those did bake in and they became expected features. But early on, people just wanted a word processor. They just wanted to be able to go in, type documents, change some fonts, and that was it at a very low level of expectations. So in order to get that new version with all of these extra features, that was a lot of non-simplicity thrown at that. And while you may argue that that changed the perspective of the customers and so the ones that, although they weren't satisfied initially, it sort of dragged them or led them to expect more and maybe eventually they were satisfied. But you upsell them. And so while they may be satisfied with the upsell, sometimes that's not required. Sometimes you don't need the Porsche, although you're like, hey, I'm glad I have one. Actually, all you needed was a little Kia or something like that. You just need to get from point A to point B as cheaply and efficiently as possible. While you may appreciate doing it in style or whatever, however you want to look at it that way, that's really not what you needed. And this is the danger that we run into of adding some features and expanding scope as developers, as implementers, as the team that is building this solution that we actually are going in and changing scope and making things more complex when our goal should be keep it simple. It's that old kiss method. Keep it simple, Sam. And if we don't do that, then we are not being agile. We are building on additional stuff. And that concept is easily understood. If you're going to go walk for a mile, you go out and you put your shorts and t-shirt on and go walk. That's very different and it's simple, but very different from if you're going to do that. Now you've got a backpack and you're carrying a couple of things of water. Maybe you've got a couple of books to read along the way, something like that. You can really make it complex if you want to. But when the goal is just I want to walk for a mile, simplify. All those other things don't contribute to going for that mile walk. And I say that because now I think I'm going to go for a walk and wrap this one up and let you guys go out. And whether you go for a walk or you're going for a drive or jumping into another busy day, as always, have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Developer Noir podcast. For more episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon, and other podcast venues, or visit our site at developernoir.com. Just a step forward today is still progress. So let's keep moving forward together. Hi, this is Rob from Building Better Developers, the Developer Noir podcast. We're excited to be on Alexa now. You can enable us by simply saying, Alexa, enable Building Better Developers, and we will be there ready for you every time you want to listen to your now favorite podcast. Whether we are your favorite podcast or not, we would love to hear from you. So please leave a review on Amazon.