Tim Ottinger has four questions that work great in many situations, from doing homework, to cooking, to writing code, to entire software projects.
They are actually awesome questions to ask during a software project.
We discuss the questions, where they came from, and look at some uses in software.
Transcript for episode 155 of the Test & Code Podcast
This transcript starts as an auto generated transcript.
PRs welcome if you want to help fix any errors.
00:00:00 Tim Ottinger has four questions that work great in many situations. From doing homework to cooking to writing code to entire software projects. There are actually awesome questions to ask during a software project. We discuss the questions where they came from and look at some of the uses in software we’re in this episode.
00:00:16 Config Cat is a feature flag service. Easily used flags in your code with Config Cat libraries toggle your feature flags visually on a dashboard. Hide or expose features in your application without redeploying code. Set targeting rules to allow you to control who has access to the new features. It allows you to get features out faster, test in production, and do easy rollbacks. With Config Cat simple API and clear documentation, you’ll have your initial proof of concept up and running in minutes. Whether you’re an individual or a team, you can try it out with their forever free plan or get 25% off any paid plan with the code test and Code 2021 release features faster with less risk with configuration. Check them out today at confett.com.
00:01:15 Welcome to Test and Code.
00:01:26 Welcome to Test and Code. I’m excited today to have Tim Ottinger on the show. On Twitter, he listed itself as Agile auditor Tim. So that’s curiosity to me. But before we jump in, Tim, thanks for coming on the show.
00:01:40 Hey, it’s a good time. I’m happy to be here.
00:01:43 How do you normally introduce yourself?
00:01:45 Pretty much like that. Hi, I’m Tim. How do I usually do it? Ottinger is the correct name, so you’ve got it right. And I am also known as Agile Otter in some circles. So if you are following the Agile crowd about conferences and things, a lot of times people know me that way.
00:02:02 Okay, well, the article we’re talking about is called The Four Questions and you published it in March of this year.
00:02:11 Wow.
00:02:11 It was just a little bit ago. Yeah. Do you want to set this up?
00:02:15 Sure.
00:02:16 So some time ago, many years ago, a young man came to live with us.
00:02:25 He was rather behind in school and it wasn’t really his fault. He was in a just a tough situation. The household problems and where he should have been going into fifth or 6th grade.
00:02:37 He was almost halfway done with first and child didn’t have a learning disability that prevented him from being there. His situation was his disability for various reasons. He didn’t attend regularly and so mostly he just never learned to go to school.
00:02:57 So when he lived with us, he had to learn how to learn and we had to go through everything from regular hours and basic behavioral things to how to study how to do homework. So most of my wife, she’s amazing. She got him to go from first through fourth grade in nine months, which is clearly the child did not have a learning disability. It was just attitudes and circumstances. I mean, that’s an amazing thing for any kid to do four years of school in nine months, and he went on to be a pretty good above average student for many years. I think he’s probably getting close to finishing high school pretty soon by now. So it’s been a long time ago.
00:03:46 That’s great.
00:03:46 Well, one of the things that we had developed was that he had to develop an orderly way of going about his work. So we came up with some questions, so he would sit down to do his math homework, and we would walk through the sequence. Okay. What is it that you’re getting ready to do? What needs to be done? I’ve got to do my math work.
00:04:07 What do you need to know or have in order to do that?
00:04:11 Well, I need some paper. Okay, good. What else?
00:04:20 Pencil. Okay. My book.
00:04:23 Yeah. You should have your book. That’s probably a good idea, too.
00:04:27 What are you doing up chapter four. Have you read chapter four yet? No. Well, then you need to know whatever is in chapter four in order to do the homework. So why don’t you read chapter four? So that was the thing. What do you need to do to start off with and then the second one is what is it that needs done is first. Then what do you need in order to do that? What do you have to collect, acquire?
00:04:50 Where can you get the things you need? If you need your book and paper and a pencil, where are they originally? They’re everywhere on the floor somewhere.
00:05:00 But eventually they’re gathered together at the work desk because you need them all the time.
00:05:06 Right. So where do you get the things you need and how can you tell if you’re doing a good job?
00:05:13 How do you know if you spell the word correct?
00:05:16 How do you know if a math problem is solved? Correct.
00:05:21 And these were the four questions for the young man.
00:05:24 And it turned to me later on to realize that I started using the same questions when I was doing work.
00:05:31 These are great. And the fourth one is a lot of people leave off the last you’re going to put your service in the cloud.
00:05:39 Okay. How will you know if you successfully done that?
00:05:42 Well, hopefully you test out the service in the cloud.
00:05:46 Check it out.
00:05:47 How do you know if it’s really running there? How do you know that it’s connecting to its supporting services? How do you know that it’s using the right database?
00:05:54 Yeah. I was actually one of the things I was drawn to this is because I kind of floored how many times in my career I’ve completely interrupted a meeting by asking this question. We’ll talk about doing something and I’ll say, okay, so if we do this, how do we know if it’s working? And nobody thought about that yet.
00:06:12 And sometimes we have to go back, figure out how do we tell if this is working or not. Because sometimes, especially with computer systems, there’s stuff that’s so hidden that there’s no Accessor functions to figure out if it’s really running or not.
00:06:28 Yeah, there’s often a very indirect effect.
00:06:31 I know that it’s taking the data from the database and putting on the screen. Because when I screen scrape it and find the control, that’s the value that’s in it. And when I change the one control, it changes it here. Okay, then that must be the database.
00:06:52 This episode is brought to you by PyCharm. There are lots of times when I need a decent diff tool and I’ve used many over the years. Lately I’ve been reaching for PyCharm. That’s right, the Python editor and hands down best GUI for pytest is also my go to diff tool. Just the other day I had a corrupt mixed markdown HTML file that was working before I had made some changes. I used PyCharm to compare the current version against the previous version to show me the changes which were all over the file and quickly isolate the problem. And I always use it when committing code. I love that I can see ifs of every file I changed undo changes. I didn’t mean to commit like debug statements and such. And the diffs are editable. See something you misspelled or whatever, you can fix it right there in the diff window. So cool. Saves tons of time. If you go to testandcode.com PyCharm and try out Pycharm, a couple of cool things happen. First, you get to try all of the pro goodies for four months for free. And second, you start saving time right away. Save time, use pie PyCharm.
00:07:57 My favorite example is working with DSB team.
00:08:04 I was writing some control methods and they said, okay, there’s this new widget, that new value that the user interface is going to have. They’re going to pass it to you, you just need to pass it on to the DSP. And I said, okay, how do we tell if this thing is working or not? I said, well, you won’t be able to tell because it would just trust us. I said, okay, well then you can just trust me. I’ve already done it.
00:08:29 Prove that I haven’t.
00:08:33 And yeah, that was another one of like, okay, well, we’ll have to figure out how to test this thing.
00:08:40 With CDB, right?
00:08:42 Yeah, I’m going to repeat them again so that just I can read them out loud myself. What is it that needs to be done? What do we need in order to do it? Where can we get what we need and how can we tell if we’re doing it right? These scales. So. Well, this can be down into the next five minutes of my work, to my entire day, to my week, to an entire project.
00:09:11 Works for function like individual features, plus an entire application. This is great.
00:09:16 It’s ridiculously. Fractal, isn’t it?
00:09:19 Yeah, it seems simple and obvious, but I was just realizing this, too, because I’ve got two daughters and realizing that the learning and getting things done at work, at school and at work is often down to these extra things.
00:09:42 You don’t have somebody watching you and making sure that you’re doing everything you need to be able to do this yourself.
00:09:47 So come up with a process.
00:09:50 But it’s not really taught or it wasn’t for me at least. Maybe they’re teaching it to my kids and I just wasn’t aware of it. But these are just good things for everything.
00:10:04 And I realize these are so broad that I can apply them to my wife and I like to Cook a lot. So before we jump in and start sauteing the onions, do we have everything for the rest of the recipe?
00:10:19 Things like that?
00:10:20 Yeah. Salsa. Do we have cilantro? Do we have onions? Because often we don’t have them.
00:10:27 Yeah.
00:10:31 Because sometimes we’ll just assume we’ve got stuff.
00:10:36 But that’s true for software as well. We just assume, okay, I know that this person is going to do this part and this person is going to do that part. Have you talked to them? Do they know that? Is there room in the schedule?
00:10:52 Can we fit that in in this time frame? Does it make sense?
00:10:58 These are good.
00:10:59 Yeah. All of the intellectual things you have to acquire. Right. Do you know how to launch the app, to launch the Selenium browser? Do you know that all of the software prerequisites are installed in the container?
00:11:14 Is everything that’s in your Pip virtual environment listed in the requirements text?
00:11:21 Yeah. Is there ever resistance to this that you’ve met?
00:11:26 Usually not.
00:11:28 I guess it’s simple enough that everybody kind of rocks the reason for it and why you’d want to work it out first.
00:11:35 Sometimes people feel like it goes against their bias for immediate action.
00:11:43 There’s always the ready fire aim kind of approach to things. And certainly a lot of what we need to do, we will learn by trying to do it. But you just narrow the scope of everything’s obvious. You’re talking about this week. If things are less obvious, you’re talking about today where things are even less obvious. You’re talking about the next quarter hour.
00:12:06 Right. And I guess now that you brought that up, I guess I’m reading into it something different than possibly others might. So what is it that needs to be done and what do we need in order to do it?
00:12:20 Those two first parts could be construed as requirements gathering, and that can get out of hand. You can do excessive requirements gathering.
00:12:31 Right.
00:12:32 So I’m thinking in terms of early on. I’m glad I read this early in my career, but I read Pragmatic programmers like a long time ago, and this idea of a tracer bullet implementation has just stuck with me. So I always try to do that.
00:12:50 What is a very simple implementation that I can test the end to end thing, not just end to end for the application, but in the end with my entire workflow of, like, continuous integration, getting the source control right, getting all the pieces together and getting something like that in place, and then doing this in scale. What needs to be done? What do we need in order to do it but in the smallest implementation and then grow?
00:13:20 That right. We are very much believers in incrementalism. So my context is always walking skeleton first.
00:13:29 Okay. Yeah. You broaden the functionality as you develop it rather than try to build a bridge by hanging bricks in space from here to the other side.
00:13:42 Yeah, very much so. And sometimes I’ve run an entire mini project by changing the first question to what’s the most important thing it doesn’t do yet?
00:13:53 I like that.
00:13:54 So we’ve done that. What’s the most important thing that it doesn’t do yet? Well, it doesn’t exist. Okay. It should exist. What’s the most important thing it doesn’t do now? It doesn’t receive input.
00:14:05 Well, that’s probably pretty important.
00:14:07 What’s the most important thing that doesn’t produce any output? Oh, well, that’s not good. What’s the next thing? Well, it doesn’t run as a service any place. There’s no deployment. Okay, well, let’s get that. What’s the most important thing it doesn’t do now? Well, when I received this message, it should do that with it, and that’s really important. That’s crucial. Okay, well, what’s the narrowest case for that? So, of course, all of these are always in a highly incremental point of view. Everything we do, we do short bursts of work. We do micro commits, we do TDD, we do constant refactoring, we do CD. So just like you, we’re in a stream of, you know, we get a trickle of water going, and then we broaden the stream by adding new features to it.
00:14:57 Yeah. And prioritizing. I like that. What’s the most important thing that it doesn’t do yet? Because I’m used to reading top to bottom and left to right sort of things. And often when you’re brainstorming all the features that your application needs, you don’t get them in priority order. You just get them like you’re thinking about the input stuff. So you’re like, oh, we should be able to pull in CSV files. Oh, we should be able to pull in different types of files. Well, you don’t actually have to implement all those before you move on to the next part of the application. You can put some of those off.
00:15:37 Right. And that’s I think one of the things that people don’t understand about the way we work is, okay, I have four features.
00:15:45 I don’t have to do the entire feature.
00:15:49 It may be that I do 10% of one feature and it no longer is the most important thing. And then the top 7% of another feature is the most important part. But once those two are done, the next feature becomes more important, and maybe two thirds of that really becomes crucial.
00:16:04 Now I do that piece now, maybe the first parts become important again in that stream.
00:16:10 If I try to do entire chunks of work in big batches, I tend to produce less often and less certainly.
00:16:20 Yeah, definitely. Tell me more about the consultancy thing.
00:16:25 Do you write code as a consultant or how does that work?
00:16:31 An awful lot of my work is done as an embedded team member.
00:16:36 I will join the team as a coach and help to teach how to work together, how to collaborate, how to TDD, how to refactor, help people understand code smells and system issues that are often not discussed even in colleges.
00:16:55 Why is it that this method belongs to this class and not that class?
00:16:59 Well, it’s cohesion. Well, they never taught us about cohesion. Okay. This method refers to seven variables from that class and no variables from this class. That means it belongs in that class.
00:17:13 It belongs to the thing it’s bound to by its references.
00:17:17 Oh, well, that totally makes sense. Yeah. And it’s like, why should this code be this way instead of that way? Well, I was taught that this is clean code. I was taught that this is the good way. This is how good people write their code. It’s like, well, that’s nice, but why don’t we just think about signal to noise ratio?
00:17:35 You can take a look at this code. What is it really doing? Really well? It’s got a whole bunch of if statements and loops. Yeah, it does.
00:17:43 What’s? It really doing really well. Over here. It’s populating a table. Okay.
00:17:50 Populating this table in like 20 or 30 lines. But then after it’s done with that, there’s a paragraph marker to tell us what it’s doing to do next.
00:17:57 Yeah, there is, isn’t there? Okay, what’s this function really doing? Really gosh, it’s doing a bunch of things. Okay. Maybe we should break it into individual things that have names. Now we can see. Okay, now what’s this function?
00:18:11 Okay, it’s just configuring a routing table.
00:18:14 Okay. Name the punching configure routing table.
00:18:18 Nice people here, and they want to know how to fix things. They need to know where to look, and we can make that easy.
00:18:24 So as embedded in the team, you probably end up teaching them stuff that they didn’t know they needed to learn. And you didn’t know you needed to teach them until you’re there.
00:18:33 Absolutely.
00:18:34 Oh, that’s cool.
00:18:36 Sometimes we find that the programmers are 5% of the lead time of a project.
00:18:44 So you’ve got ideas that come in on one end and they take weeks and weeks and weeks to go out the other end and be deployed. But the programmers time is two days, right?
00:18:55 Yeah.
00:18:55 And you got an organization where people at the top are saying, we’ve got to go faster. You programmers have to work faster, and we can come back now once we measure that and say if we went twice as fast this four month lead time, it would save you one day if we went twice as fast.
00:19:13 Well, why are we so slow then? Well, let me show you your process.
00:19:17 Every time anyone does anything, it goes into a queue and it waits weeks for somebody to get around to it and give it a day’s worth of service. And it goes into a queue. And it goes into a queue and it goes into a queue and the programmer works on it. It goes into a queue, it gets rejected, it comes back and queues up for the programmer again, that goes through a queue. What you’ve got is a process that’s built to be slow and unpredictable.
00:19:40 Well, I think the programmers need to work harder. Well, that’s one day get rid of the queue and it will save you a week. Which one you want to do.
00:19:48 Yeah. And even if the programs were instantaneous, it only saves two days.
00:19:53 Yes, if they were absurdly impossibly fast, it would save two days.
00:19:59 I’m glad I’m not working in an organization that broken. But how long do you usually spend with a team or does it vary?
00:20:08 It varies. Sometimes I just do workshops. So a week or two here and there, but some of them I may be with for a year.
00:20:17 I don’t usually like those. Usually probably two, three, four months.
00:20:22 Oh, nice.
00:20:24 Because you can kind of really get a sense for what their domain is and what their skills are and stuff like that in that time frame.
00:20:32 Yeah.
00:20:32 And I figure if you can’t make a difference in a month or two, then you’re probably the wrong consultant for that company at that time anyway.
00:20:39 Yeah. Okay. I assume most of your work now is remote through virtual and was it before 2020 or so?
00:20:51 We’ve been trying to sell remote coaching for about seven years.
00:20:55 So here’s Josh and all the rest of industrial large. Well, have you considered remote coaching? We could remote coach. So you don’t have the travel expenses? No, we think you need to be physically here. Alright, well, suddenly COVID hits and everybody’s like, can you do remote coaching? And we’re like, we’ve been trying to sell you on this for seven years.
00:21:17 Why haven’t you? But yeah, sure, we’re happy to do that. So our business has grown like mad over the whole Covet thing.
00:21:25 Covet is not good for anybody, but a massive increase to work from home has been good for our company.
00:21:32 It’s sorry that it came about this way.
00:21:35 We didn’t get around to really talking about modern agile, so I’m going to have to probably bug you to come back and talk about modern agile at some point.
00:21:42 Oh gosh, if I have to.
00:21:44 Sure, I’d be happy to because I’d love to cover that and what makes it modern.
00:21:53 Thanks a lot for your time and thanks for writing this article so I’ll talk to you later.
00:21:59 Yeah. Thanks for the invitation and the chat.
00:22:06 Thank you Tim for sharing the four questions and the story around them. Thank you also to Patreon supporters join them at testandcode.com support. Thank you Config cat for sponsoring release features faster with less risk with config cat. Check them out at configat.com try for free or use code Test And Code 2021 for 25% off. Thank you PyCharm for sponsoring the show save time. Use PyCharm check them out at Test And Code that link is also in the show. Notes@testandcode.com 155 that’s all for now. Now go out and test something.