Today we will be talking all about incremental design: How working on this design using the act of process will help your team build better products, gain effective feedback and how that can help you boost sales at the end of the day. In this episode we are joined by special guest, Conrad Benumb, the Principal Consultant from Stride.
Although there might be some risk and uncertainty involved, we do believe that incremental design can help you, and the company you’re working for, to build products. So in this episode we will be discussing the ways in which you can make the most out of incremental design, using the feedback loop and various other helpful methods. Take a listen!
Key Points From This Episode:
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in teched-out Chelsea New York. I’m your host, Michael Nunez. I have my cohost today.
[0:00:09.8] DA: Dave Anderson.
[0:00:10.8] MN: My producer.
[0:00:12.0] WJ: William Jeffries.
[0:00:12.7] MN: And today we’ll be talking about incremental design but before I continue, we have a special guest, Principal consultant from Stride, Conrad Benham.
Conrad, what’s going on?
[0:00:22.7] CB: Hey, thanks for having me. Looking forward to getting around this topic and
talking about it.
[0:00:28.5] MN: Hey, glad you came down to have a chat. Like I said before, today we’ll be talking about incremental design and how working on this design using the act of process will help your team build better products and more feedback from the users and how that can help you boost sales at the end of today.
[0:00:47.7] DA: Sounds clutch. Conrad, maybe you can tell us a little bit more about why we should be excited about incremental design?
[0:00:54.2] CB: Yeah, incremental design is basically taking your software that you’re building and trying to build it just in time from a design perspective without spending weeks and months.
of effort to design your classes and your architecture and getting all of those things together, you know. In the pre-agile days, it was very common to spend weeks and months, putting together designs – architectural designs, class diagrams.
[0:01:26.8] DA: Yeah, UML.
[0:01:28.1] CB: UML, correct. I mean, UML is still very important, don’t get me wrong. Lightweight UML is what I go for, which is a very small subset. Class interaction diagrams where you’ve got your classes and then you’ve got flows between your classes, taking the methods that are being called. I mean, I remember creating some of those in my first job straight out of university and the best thing they were useful for is to light fires.
[0:01:54.8] MN: Oh yes, and keep the office warm in the winter time. Those are always good things.
[0:02:00.8] DA: Back in the tough Java One days.
[0:02:02.8] CB: Yeah, I think we had got to Java Two by that point but yeah. It was way back then. The idea is about taking your software and well, not so much your software, but your requirements, business requirements, getting your stories and figuring out what it is that you need to develop to be able to meet those requirements without adding more functionality than is needed or more software rather than is needed.
There’s all sorts of reasons that you wouldn’t want to do that. For example, if you add something that isn’t being used, something that the business didn’t ask for. So they’ve taken away from the business’s ability to get something that they actually want. Coupled with that is the fact that you now have to maintain that software, which if it wasn’t in the system to begin with, you wouldn’t have to maintain it.
[0:02:55.6] DA: Right, like kind of over-engineering to have it be the most flexible possible end-point where you can stuff all kinds of fun user data into it. When actually all you need is, like a thumbs off.
[0:03:07.6] CB: Yeah, exactly. You know, I’ve worked on systems where I had an idea as to what the future road map was going to be, what we needed to develop but I didn’t necessarily know what we would develop at any point in time.
You know, that’s because the business could have had the prerogative to be able to change the requirements at any point. So something that was a priority today may not become a priority in a few weeks time so we were very able to respond to the change. So using a combination of design patterns and dependency injection, if in Java or a statically type language, I’ve been able to create software that can change and evolve over time because of the patterns that are in use.
[0:03:55.6] DA: Yeah, I’m curious. As you’re kind of building this design and discovering it, uncovering the design with your stakeholders as you go, how do you make sure that you’re working on the most important thing? I guess, when you’re doing a big upfront design, you can make a big list of things and from that maybe derive something that’s important. How does that work with incremental design?
[0:04:17.6] CB: Yeah, I mean, when you’re doing it incrementally, you’re really trying to take the big features that you have and just focus on the things that are of greatest importance because they’ll derive business value soon and allow the users to give feedback and start using and weigh in on the software that’s being built.
Then as you add more and more, you will hopefully be adding new functionality that adds on the existing functionality over time. Does that make sense?
[0:04:49.2] DA: Yeah, I think so. You’re kind of driving towards like a new feature or like –
something different.
[0:04:56.8] CB: Right, you're not necessarily driving to solve tomorrow’s problems by engineering things that you don’t need today. But you’re really trying to solve today’s business problems by leveraging technology to solve today’s problems.
Keeping in mind that tomorrow may never happen, in terms of the fact that you may never end up doing the stories that you think you’re doing. I’ve seen a lot of time being wasted by trying to build big frameworks that end up not having any relevance because they do everything.
[0:05:28.1] DA: Right, they’re beautiful, code.
[0:05:32.1] CB: Well not even beautiful code, lots of reflections so they’re difficult to understand and maintain.
[0:05:36.3] DA: Yeah, that seems like an interesting balance where you have to kind of strike a cord between having a tight iteration, where like you’re staying close to today’s needs but you don’t want to be too close because you don’t want to just be like moving buttons around on the page or changing the colors.
You want to be making some meaningful progress but you also don’t want to be too speculative and pushing too far out.
[0:06:00.8] CB: Yeah, it requires eventually, only to do some refactoring. But yeah, you don’t want to be doing oodles and oodles of refactoring. Another thing that I – there are few other things that help. Pair programming is one because then you don’t get silos of knowledge, you get a lot of shared knowledge and context and understanding. Test driven development is also very important. Test driven development is not just about testing but also about the design of your software. If it’s easy to test, then it’s generally going to be very easy to maintain and extend as well.
[0:06:32.3] DA: Yeah, definitely. Like much easier to reason about. Because everything is there on the table in front of you.
[0:06:37.4] CB: Right.
[0:06:38.4] MN: I like to look at test to – as like documentation as well, just additional documentation on why this particular function is going to respond this way and testing definitely gives you more insight on the implementation that’s currently deployed. Or the increments that you got to this point will be explained in the test as well as the code itself.
[0:07:00.6] DA: Yeah, foot note: see episode five. Is it five?
[0:07:04.8] MN: I believe it’s one of the early episodes we had on test-driven development. Definitely we always bounce back to it because it’s such an important aspect to the life that we live as developers and as consultants. I have a question though. This seems like incremental design is something that goes beyond the developer’s mindset.
I imagine like, you know, if you’re working on a team where it’s like, “All right, take this 400 page spec and make it happen and I’ll see you in six months.” There is nothing incremental about that and that goes outside the realm of the developer themselves. So I imagine that the team would all have to be in it together where it’s the project manager and the developers, the product owner have to kind of live in building things incrementally.
Is it possible to change a team that has worked on 400 page spec sheets to now think incrementally in their product?
[0:08:02.2] CB: I mean, I’m sure it is if you have enough time and patience and energy. I think that changing a team that is very upfront — the term is “big design upfront” or “big upfront design”. That is a very big challenge because there’s often a lot of cultural issues. You’ve got people who have been used to doing things in big upfront manner. So it can be very hard to break that trend.
I’ve always found it difficult. I think as consultants, I think it would be easier but still not easy if we go in as an orchestrated group as opposed to smaller individuals. But even then, it’s not going to be easy to solve that problem. I don’t have any easy answers for that.
[0:08:49.5] DA: Sometimes, it’s also required by the business that you need to have these deliverables, these documents that say, “This is what went into it and this is our design process and whatnot.”
[0:09:01.8] CB: Absolutely, there are many different businesses like hospitals, finance.
[0:09:05.8] DA: Yeah, I’ve worked in healthcare as well, very regulated.
[0:09:09.7] CB: Exactly, when you have those regulations, that’s when you have to have a lot of these documents. So there’s a contention between trying to do things lightweight and being compliant.
[0:09:20.5] DA: Yeah. Like the way I always thought about was that there’s this spirit of the compliance, which is that you should be thoughtful and mindful of your process and document it but then there’s also the actual practice and the best thing to do to figure out what that design should be is that you should do a little bit of requirements and then start building it and see if you're right. If you can get away with like doing little iterations behind the scenes then I think that’s a good tragedy.
[0:09:49.0] CB: Yeah, exactly. You know, it might be possible to take the ultimate design that you come up with and use that in your documentation.
[0:09:58.1] DA: Retroactively, yeah.
[0:09:59.7] CB: Retroactively, exactly.
[0:10:00.9] DA: Or, just run, a command on your program and like get a UML diagram, “Wow, look at all this work I did.”
[0:10:07.3] CB: My goodness. I’m going back to Rational Rose there.
[0:10:11.1] WJ: Let me play devil’s advocate here. I’m actually a proponent of incremental design, but for the sake of argument, I think this will be a more interesting conversation. If somebody disagrees, I’m happy following that sort.
How can you justify taking so much uncertainty on? Because the business needs to know whether or not it’s worth the investment in order to get the product they want, right? So if I’m a stake holder, if I’m a business guy and I’m going to embark on this quest, I’m going to get in this boat with you and allow you to design software for me, how can I sleep at night, knowing that there’s no plan for what’s going to take me all the way to the full-featured app that I envisioned?
It’s a big leap of faith for me to say, you can just deliver this one tiny piece and there’s no promise that in a reasonable amount of time for an amount of money that I can afford that I’ll actually have the product I’m asking for.
[0:11:13.6] CB: That’s a great question. I think one of the answers or aspects to the answer is when you’re doing things incrementally, you are trying to show value as soon as you possibly can. So while you’re definitely – while you’re showing that value, you’re delivering software, you’re delivering workable software, your stories should be aligned to functionality that the business can use or rather a user can use. If you can do that, generally I’ve been able to find that I can convince the stakeholders and gain trust through showing regular delivery of functionality.
Generally, I’d work in sprints of two weeks or if it’s a particularly contentious project, maybe sprints of one week because then you get a lot of fast feedback. Then over time, if you can continue to show repeated delivery effort, say over three or four iterations and that you haven’t dropped and slowed down, you can start to gain trust but yeah, there is always that trust issue upfront.
Now, there’s even – the idea there is that if you can’t make progress and you can’t go in the trust, well, you’ve only lost what would amount to maybe a month’s worth of effort. Or maybe two months’ worth of effort rather than six to 12 months’ worth of effort. Which you would lose if your big up front project with a big wad of documentation and design and so on, fails.
[0:12:47.3] WJ: What if I’m a totally non-technical business person, I don’t have any savvy here and I’m really unable to tell based off of how much progress you’re making, whether or not you’re going to be able to finish my app in the six months and $300,000 that I have allotted for it?
[0:13:06.4] CB: I mean, that’s a good question. I don’t think you necessarily get to answer that question with agile. What you get to answer is that you have a ballpark estimate of where we think we’ll be in six months with that budget. But the real thing that we can do is, break it down into small increments of time, two week iterations, and show value over that time and as we get closer, really whittle down on the functionality. So there may well be a tradeoff of functionality that’s utmost important versus things that aren’t so important.
[0:13:46.3] WJ: But Bobby over here promised me that he would deliver the entire app on time
and on budget?
[0:13:53.5] MN: Hey, hey wait a second. I’m just happy to be the host of this podcast. What are you talking about?
[0:13:58.3] DA: That’s his super power. On time, on budget.
[0:14:01.7] CB: On time, on budget, without missing the deadline.
[0:14:04.5] MN: I try, ladies and gentleman.
[0:14:06.6] DA: That’s how they do in the Bronx.
[0:14:07.0] CB: Is this the middle of the boroughs?
[0:14:11.5] DA: Yes.
[0:14:12.9] MN: I think one of the things I like to use when an individual who isn’t more business savvy and kind of just wants this thing in a big bang iteration, I try to incorporate a way of doing some form of AB testing to show like, “Hey, look at the progress that we’re getting by adding these features incrementally.”
They could be both good or bad, right? If we’re working on something and we find out early on that it’s not like feasible to the customers or to the users, then imagine if Bobby the business man spent $600,000 on me to build this application and I actually get it done in six months but then, no one wants to use it, right? That is like the worst part.
I imagine it’s like you know, if you see a pool of water, you can either you know, slowly get yourself into the water or are you just like jump straight in. But who is to say that there are piranha’s inside, or who is to say that there’s something more dangerous? You want to make sure that you're safe to build this entire product safely with measurements of data that can translate to both the developers who are invested in wanting to build this awesome product. And for the business who have insight on whether or not that thing that was built is a good product.
[0:15:34.4] DA: Yeah, that’s a good point, especially like having regular feedback. I think that’s been a common theme that we’ve been talking about. If you're doing iteration and you’re not getting feedback then you could still end up in the same place where six months down the line, you could be like, “Okay, now I’m ready to show the world my product,” and then no one likes it. You’ll say, “Oh, I guess I should have asked someone.”
[0:15:55.1] CB: Yeah, that’s why that feedback loop is just uber crucially important for so many reasons. Like you can get feedback, like the users and the business can say, “Yeah, this is great but there’s this thing over here, this button that’s in the wrong place or it doesn’t quite do what I was expecting it to do.” And then you can correct that as you’re going.
Whereas if you spend six months’ worth of effort, you have no way of being able to correct anything at the end of the six months. Add to that, that you will often have a big bang integrationally where you’re trying to integrate and deploy everything at once. There will be API’s or various systems have to line up on and integrate with and you realize that you’re not sending the right field through or there’s some validation is failing. There’s all sorts of things that occur there.
[0:16:45.4] WJ: Yeah, and I bet if you talk to any of the clients that Bobby worked for, they’ll tell
you.
[0:16:51.0] MN: Come on.
[0:16:54.3] WJ: I’m not talking about –
[0:16:55.0] MN: I can –
[0:16:55.7] WJ: I was talking about the generic Bobby.
[0:16:57.8] CB: Well I could actually vouch for Bobby because he and I were working on a project together a few years back. Where we did incremental design and that was highly successful.
[0:17:06.7] DA: I’ve heard that they’re still like designer effects from this, still to this day.
[0:17:12.7] MN: It is important because then they’re like, “Hey, we’re realized, this is not really useful to us.” And we’re like, “Oh snap.” Imagine we spent like three months doing something that wasn’t feasible and then we found out like in the span of the deploy, the day we rolled it out. I was like, after a couple of days, “We can do that at a later time. Cool, boom. We knew, straight up.”
[0:17:38.1] DA: I think spoilers. I’ve heard this story before but I remember when you mentioned that by its name as “The Mona Lisa of Design.”
[0:17:44.8] MN: Yes, it was definitely.
[0:17:46.3] AD: I was like, well, I imagined like big – all at once design because it’s Mona Lisa, you know, it’s a work of art.
[0:17:54.4] WJ: But if you look at Mona Lisa there are all these layers under the paint.
[0:17:58.0] DA: Right. That’s like – that’s the illusion I guess of the work of art.
[0:18:03.9] CB: If you can carbon date a white board marker, you’d have layers.
[0:18:07.0] DA: Exactly. See all the emotions that went into it.
[0:18:13.1] CB: Exactly. The design diagram that we were talking about here was a design diagram that started with just a couple of UML classes and then grew. I think it was like two or three to begin with and then it grew to about 50 or 60 over time.
[0:18:29.0] MN: It was written on a whiteboard so unlike the UMLs Conrad spoke about before, we couldn’t throw them on the fire. I feel like there would be like some toxic hazard for that.
[0:18:39.6] DA: Don’t light up erasable markers, it’s probably not good for you. Don’t do that.
[0:18:45.6] MN: Cool, I imagine the conversation on incremental design is probably something new to a lot of the listeners and maybe something that you’ve been doing for the past couple of months or years in doing. We do believe that incremental design can definitely help you and the company you’re working for to build products where you have a really tight feedback loop to know whether the thing you’re building is feasible to your customers and new users so that you can go and deliver awesome products at a faster time.
Do we have any “teach and learns” that we want to speak about in this particular segment today?
[0:19:22.4] CB: Yeah, so maybe some of the design patterns that I like to use when I’m doing incremental design, if that’s of interest?
[0:19:29.9] MN: Sure. Go right ahead.
[0:19:33.3] CB: The design patterns I like to use. Dependency injection is a big one, especially in a statically type language where you can’t use – where you can’t use open classes to modify the functionality like you can in Ruby with open classes. Although you can still do dependency injection in a dynamically-typed language, it’s just not commonly done. I’ve recently came across a company who is doing dependency injection in Python, which they’re very happy with.
Anyway, so strategy design pattern is one, where you basically take an implementation of a class and that might change based upon the actual implementation. So let’s say, you have some text that you want to send outwards so you might do some text processing and then once you’ve processed the text, you want to send it outwards.
But you don’t want to bake where that text gets sent to in the thing that processes the text. You might have a file repository where the text is written to a disc or to a database or another strategy where it’s sent out to over the web, to some other system for storing or whatever, needs to be done with that text.
Then there’s proxy, where you might wrap an existing object with something like a database transaction. So you might be writing to a database without any transactions and then you could use a proxy to wrap the thing that’s writing to the database with a transactional aspect or transactions, which then mitigate the need to handle the transactions within the thing that’s actually writing to the database. Does that make sense?
[0:21:15.3] MN: More or less. With taking the transaction in the database, you wrap it in this object that can then use that information across the application.
[0:21:25.7] CB: Yeah, exactly. You don’t end up – you’re separating the concern of the database transaction from the actual interaction with the database, right? So you’re creating a separation. Then you can easily test the transactional layer and you can also test the thing that’s reading and writing to the database, the repository.
[0:21:47.6] WJ: So the idea is that there are different strategies for saving text. One is saving it to a file and other is saving it to disc and other is saving in API. You use this strategy object that you pass into whatever it is.
[0:22:00.4] CB: The text process or whatever it is. Yeah, exactly.
[0:22:03.2] WJ: The text process. Then it uses – it calls, some generic method on that strategy for like process text and then it does either the database transaction or the disc write or the API hit.
[0:22:14.2] DA: Basically like implementing the interface.
[0:22:16.2] CB: Exactly. Yeah. Then if you were to like wrap a proxy around that strategy, you would then separate the transaction from the reading and writing of the database. You could also wrap a transactional proxy around the disc writer or the http writer, something could go wrong when writing to disk and you might want to roll the transaction back, at that point too.
[0:22:38.0] DA: These things happen.
[0:22:39.2] CB: They do. Yeah.
[0:22:40.2] MN: You need to roll the transaction back, roll them back.
[0:22:43.2] DA: I think that will be useful. I’ve been thinking about like using a local storage on a project and sometimes the local storage doesn’t work, it’s pretty unreliable.
[0:22:50.6] M: Oh yes, I think it’s Safari.
[0:22:52.6] DA: I think this will be useful.
[0:22:16.2] MN: I think Safari will like act weird I believe. I’m not 100%
sure.
[0:22:59.0] DA: Yeah. Oh really? If you use local storage?
[0:23:03.1] MN: Yeah, I think local storage in Safari has different behavior than in Chrome.
[0:23:06.7] DA: If you go in incognito mode, the local storage will throw in an error. Whereas every other browser, will just separate it into its own store. So, you have to deal with that.
[0:23:19.2] MN: Awesome. Well that wraps up the show. I’d like to thank my cohost, thanks for coming on now. Our producer, always good having you, and our special guest, Conrad, thank you so much for stopping on by.
[0:23:32.4] CB: Thanks for having me guys, it was a pleasure to be on air.
[0:23:36.8] MN: There you go. Feel free to hit us up, twitter.com/radiofreerabbit. This is the Rabbit Hole, we’ll see you next time.
Links and Resources:
