Keep It Simple, Silly!

August 15, 2019

Joshua and Kel talk about keeping it simple and the balance of functionality, intuitiveness, maintainability and simplicity.

Be sure to check out our new Slack community to meet others who are facing the same things you are and share your journeys!

• 00:05 Joshua

  Hey folks, welcome to Getting Apps Done. A mostly non technical podcast about building software. Uh, today we want to talk about keeping it simple. I'm just going to end with that because...

• 00:19 Kel

  Because that's simple. It's nice and straightforward. It's simple. Keep it simple silly. I like that. It's always as the end of like kind of thwacking you with a newspaper to remind you to keep it simple because you're just making it complex on yourself. You're making it too hard. Um, so yeah.

• 00:35 Joshua

  Yeah. Um, software development in general, and it's not the only discipline I also find in design, simplicity actually makes things better in almost all cases full-stop. There's not much argument to that, but yeah, absolutely. Because people don't like complex things. We like things to be simple. We like them to do amazing things. We like them to be amazing, but we like them to be simple. I certainly do. And sometimes we get so lost in trying to build amazing that we forget that concept and we just build too much. And we've seen ups and downs with this in design and particularly the user experience design. I certainly remember when I started out, we were working with a lot of mainframe designs and things like that. And the thing about mainframe designs is they looked very complex, but actually they were really simple and they were really well thought out and it was the simple small things that they did that made them work really well because they spent a lot of time making sure the tabs went to where they were supposed to go and didn't worry a whole lot about everything else or making anything whizzy. It was about making it simple for somebody to key things in. That was all they were looking to do was keep it simple and make it easy to key things in.

• 01:49 Kel

  That's a great example cause like that is, there was like a big learning curve with the, the old mainframe and like terminal apps like that because there weren't, there wasn't anything intuitive to build off of. We talked about intuitive in the previous episode. So there's a bit of a learning curve of having to learn this system that's keystrokes, how its tabs were set up and whatnot. But once you learned that there wasn't really anything else like it was a very simplistic concept to hold, so once you learned that core, you know, whatever pattern it was to move about this interface of this text only interface. Once you had that, everything else was simple on top of that, so it was really easy to kind of hold in your head to keep that simplistic concept in your head and make the rest of it a lot easier to work with for your end users and it as an added bonus. It was also very simple to maintain.

• 02:38 Joshua

  Yeah, absolutely. I remember when I was working at IBM, they were transitioning between a mainframe system and a Windows system and there was a huge uproar about that and I found it very, very hard to argue with people because they're showing me on their mainframe screen how they could key these things. They're not even looking at the screen. They just key these things in over and over, over and over again, going through a hundred a minute, just crazy fast. And then they go into windows and click, click open this click move there. Go over here. Type type type like click, click, click, click, click, click, click, click, click, click, click, click. Oh, where's this? Oh there it is. Click, click, click, click. Type type. And then they finished one at the time, they just did 10 on the main frame. Right?

• 03:19 Kel

  And know that they're moving their hands back and forth between the mouse and keyboard and they're doing all these things. And then they've got to find the menus. And then not all the menus depending on who actually built them, even have keyboard shortcuts. So like there might've been a fast shortcut for the people who were in there, all the, all the, all the time, but there wasn't, um, yeah, so I went through a bunch of hospital, you know, I was big in healthcare for a while. So that was a really common thing was that these old systems were getting switched out with their new GUI versions. And there were atrocious. Um, hospitals were really good at measuring, um, like admission time, like time when they, to the desk to actually doing something. Like they measure, they have a lot of metrics on those kinds of things.

• 03:59 Kel

  I don't know that there, there's other problems there. Um, but actually measuring those metrics exists and so it was really obvious that when they switched them out that there was a huge time lag. Um, the thing that did get better was new people, somebody who did not use the system regularly could sit down and play with it and get it better. Um, but people who were used to it, people who are in there all the time, were drastically like, had this huge impact on like their actual speed because the system was more complex, more amorphous in it's designed rather than this like really simplistic thing that once learned you could run with. And so that trade off was not a great trade off. Simple was in a lot of ways, considerably better.

• 04:43 Joshua

  Yeah. And I think as developers and designers, we have started to grow. It was a huge learning curve for us as well at the time because we were still itching from, you know, something that we knew how to do. We knew how to make these mainframe screens and make them flow nicely and then suddenly we have, this was legitimately a very good idea to go build these GUI systems that are intuitive for people to pick up. It's very visual, people can understand it, but there was a huge learning curve for us to figure out, okay, so how do we build simple intuitive interfaces?

• 05:17 Kel

  Where do the buttons go? Okay and cancel? Which one's on the right and which ones on the left? We still haven't agreed on any of these things.

• 05:25 Joshua

  But I certainly remember particularly in the late nineties they had GUI interfaces that looked a lot like the mainframe interfaces, but they were completely un-intuitive because they spend so much time figuring out how to do all the clicks that they forgot all the tabbing pieces and there was just this huge step. And that was very difficult for people to grasp and pick up and learn how to make it simple again. But I think there's a huge amount of merit in taking the time to figure out how do I take something complex and make it simple.

• 05:55 Kel

  So yeah, I'll actually wanted to take that and kind of lead into how we think about like what does simple verse the Wiz, right? Like you want both. Like we want, we want art, we want the cool stuff, we want the neats and the shiny's. And like that's a very iterative process. It's very much like writing is a great example. We've used this a million times of you write something, you write your rough draft and then you simplify it and then you expand on it and then you simplify it and then you expand on it and you simplify it and you keep repeating these things you refactored into a simpler and simpler form until it's simple. Is kind of the goal, um, in development that the two kind of competing pressures generally are features and maintainability are the version of that? The simpler it is in the like more straight forward it is, the easier it is to maintain. But the more features you want, the more difficult it is to maintain that simplicity. And so that's the balance and the trade off that you see a lot of, but it's usually a better idea to start with simple.

• 06:52 Joshua

  Absolutely. And just doing a little bit of research, you will find that there are 154 million different things we're trying to do to make these big things simple so we can have lots of features and still keep it simple. And there are all kinds of modular systems and microservices and everything under the sun attempting to take this divide between wanting fully featured and fantastic and wonderful things that do all kinds of magic, but also then keeping them simple, simple to use, simple to maintain, simple to build. And it's a very difficult concept.

• 07:26 Kel

  Yeah, exactly. That's the main driver between behind every framework that you see is the constant pressure between maintainability and features and how can we keep things simple while also being able to give things like accessibility and intuitive interfaces and the thing that makes it animate across the screen and explode into sparkles and stuff. So like simplicity is like a really like competing pressure, but it's also a really important one.

• 07:51 Joshua

  Now you mentioned the sparkles and that is something that comes up that I do like a lot. We went for awhile where websites and apps and everything all looked like geo cities. It was horrible. It was actual sparkles. Sparkles were exploding all over the screen and it was just this massive mess of wow.

• 08:13 Kel

  It wasn't not friendly at all, but hey you had cool things appearing when you moved your mouse.

• 08:19 Joshua

  Yeah, absolutely. But lately that has come back. We've got sparkles again, but the way it's come back in is to take a very minimal interface and then apply what they call micro interactions to it. And I really like this concept. You know when you click on, I think it's medium has the applause button. Then when you click on it, it sparkles come out of it or something like that. And these aren't things that feel nice. There's a nice little bells and whistles, they're nice little touches and flourishes. But the overall system itself is still very simple. There's not actually a lot there and they kept everything simple and then added these small touches to it. So it's not this wildly complex system. And I think you can do the same with a lot of different things. You can take very complex concepts, simplify them and then put just a little bit of flourish on top of them. And it's a very good way to get a little bit of both worlds.

• 09:10 Kel

  Your example right there, it's kind of similar like the material design concepts of sticking to concepts that pretty much everybody learns. And like with material design, a lot of those things are physics-based. Like the animations will have like a really minimal physics engines to create a realistic-ish bounce effect or a realistic, like what would an actual physical button do? Because those are situations that more people have actually experienced, you know, talking about the intuitive design again. But the larger group of people have actually encountered physical reality, you know, they have been in the world and have seen things fall and know like more or less what acceleration looks like and feels like and what gravity... And so those types of micro interactions are a lot more intuitive, like actually intuitive to most people and more accessible to most folks by keeping them simple but with things that people already know. And there aren't many concepts that we're all, that we all get introduced to that we all encounter in our day to day life. Um, you know, a ball falling is kind of a common one. There aren't many other things like that. And so, but yeah, keeping it very minimal, but then what flairs are there are being things that people are intuitive about as simple as you can get it. And that is very much a challenge. It is hard to trim something down to the basics.

• 10:24 Joshua

  Absolutely. And we've talked a lot about design, but this applies to a lot of different applies to everything really. But for example, architecture keeping your architecture simple. Again, it's a balance. There's these, when it comes down to it, you could just have one very simple monolithic thing and it feels simple, but then you start adding features. Then suddenly it becomes monster, where then things like microservices feel complex at first, but separate some of those things and keeping those sorts of things in mind. Trying to simplify your architecture to be able to cope better is absolutely beneficial. That's the holy grail of architecture is trying to keep it as simple as possible, but allowing for a lot of extra things. It's the same with code. Keeping it simple can be pure functions. It could be just documenting your code, putting any comments.

• 11:16 Kel

  We've talked about a code as art before it's been, oh wow. That was a, uh, an episode a while back with David of um, code is art. And so like for me, how you choose those competing pressures of I have all of these features and these are my goal of simplicity and where I make those trade offs, those decisions that like how I balanced those two choices and which one I picked is kind of the expression of my art in that thing. And the more skilled I get at that, the more my preferences on those balances become, you know, weighed with actual skill and experience and really strong preferences and different routes through experience. And so that's how you can express yourself into these things. It's like where art comes from. So a little meandering philosophical tangent there, but that is more or less how I view, it's why I enjoy doing some things in code because it's why I like refactoring for example, because it's such a fun way of expressing some of these opinions and skills that I have built up over the years.

• 12:18 Joshua

  So yeah, I just thought you'd like to do it because I go crazy and I make lots of ugly code in you just want to make it pretty again.

• 12:24 Kel

  You've got this balance in other locations, so that's fine. But yeah. So yeah, being able to balance those two things though is very much your own expression. And you know, it comes back to when we talk about feedback as you might get an expression from somebody else that you realize is better because their experience in that area is more accurate. They have more experience on that type of decision and can give you a weighting that's way better than what you would've guessed for. And you're like, oh I, you're right, my decision was not great. I should've gone for simpler here or no, this was too simple. This is too basic. It is confusing to, you know, 90% of the, the people actually using the software, and I should've gone with a slightly more complicated example. Like it was worth the expenditure and complexity and that's something you get with feedback.

• 13:11 Joshua

  Which we talked about in our last episode and a lot of these concepts you will find throughout programming and life in general. A lot of concepts keep coming back because they are so important. And feedback is an incredibly important part of keeping things simple because you start to recognize where people find things complex. The GUI interfaces were one of those perfect examples. The feedback from people who went from a mainframe to this new Windows interface gave us a lot of feedback and it was very good feedback explaining why this was failing for them, why it took them longer, why it was less intuitive for them, even though it was meant to be more intuitive.

• 13:49 Kel

  Exactly, and you do have to weigh that, and that's where the AB testing and statistics start coming in is when you start talking about individuals.

• 13:55 Kel

  So, every time any website updates its user interface, regardless of how improved it actually is, regardless of how much better it is, someone will hate it because it changed their workflow. There's an XKCD about that. There's an XKCD for everything. But when you do that and it's, it is worse for them, that is their feedback and they will be very loud about it. But you do have to compare that to everyone, because a lot of the times you are working at kind of like a statistical model does it hit the majority of folks and it's not just the majority but the majority of folks who are using the software the way you want or like the focus. Like it's, you kind of have to filter these feedbacks and look at them and try to determine which bits are the ones that we need to focus on, which ones actually are right. So you can get a lot of like noise in your responses on making things simple or better.

• 14:47 Joshua

  For example, putting in best practices in code. There are quite a few really great tools out there that will read through your code and look for things that you're doing horribly. And anytime any company ever implements one of these, the feedback is just horrible, but again, you have to look at what the end result is. If by putting those best practices in, does it make it easier to onboard new developers or does it make it easier for the existing developers once they get used to it to start to read each other's code because you'll find a lot of time these things are being implemented because people weren't playing nicely together and by simplifying it and putting everybody on the same page, looking at the same sorts of code all throughout it, first off it makes it less error prone because the simpler something is the less that can go wrong, but also it makes it just easier for people to work with because it's simple. We like simple.

• 15:39 Kel

  And we should mention that simple and being easier for other people does not mean easier for you. Like to achieve simplicity is a challenge. It is a difficult thing. That's why it's iterative. That's why it requires feedback. That's why it's code requires refactoring and all of these things like to create something simple is a difficult process, but once you are done it is easier for everyone else. And so when we talk about keeping it simple, a lot of times that might just mean more work for you. You know, the, the old example of over-engineering something or writing a piece of software to do something you probably should have just done manually. More effort for you would have probably been better than creating this thing that is now more effort for literally everyone else. So a lot of the pressure for keep it simple is also a note to yourself of yeah, take on that effort yourself. And so everyone else does not have to. Don't be selfish.

• 16:38 Joshua

  Again, that's part of why a lot of us are developing software in the first place because we want to put in that effort to make things easier for everybody else to make it simpler for them.

• 16:46 Kel

  Yes. For ourselves and others is really the goal is we want it to be easier for both.

• 16:54 Joshua

  Absolutely. And some of the best apps I've ever seen or designed by people who just wanted the app themselves because everything out there is either way too complex or they just wanted to simplify it and make it work better for them. And that's absolutely what we're talking about.

• 17:08 Kel

  I feel like those are some of the best applications because they're curated to a very specific and coherent feedbacks. So instead of designed by committee, you get this very specific designed by one person with a very solid vision, which creates a very simple thing that may or may not be what you want. But if it is what you want, it'll be really good at it.

• 17:31 Joshua

  Yeah, and mobile apps are probably a great example of this, because we had so many different desktop apps for all kinds of different things and they, not all of them are complex, but a lot more. And the concept of a mobile app, it wasn't actually intentional for it to be simple, but because of the interface itself and the fact that they were new at the time, still are relatively, they had to be simple. They couldn't do all these crazy things because they didn't have the CPU power, they didn't have enough memory, they didn't have the interfaces to do it. You didn't have keyboard that you could type into. So they had to start simplifying things and actually that was a really great boost to the development world because we were forced to simplify things and sometimes we really do need to be forced to simplify things. It might be self-imposed

• 18:18 Kel

  It put a really strong constraint on the whole thing for simplicity that was not necessarily there before and that was helpful.

• 18:26 Joshua

  Agreed. And I think constraints are a wonderful thing to make us more creative and to make us better at what we do. And sometimes I think we need to self constrain and just say, I am going to make this simpler. It needs to be easier. It needs to be less stuff like and more better.

• 18:46 Kel

  Defining constraints is a great way of describing those things too because it creates that, that downward pressure for simplicity while also not really describing limits. It's just you can't go here, but you can go anywhere else. And by like being really clear about that, it gives you more freedom to stretch into the odd ways to figure out other solutions around these constraints that might be simpler. Um, so it's kind of the opposite direction pressure, right? Like you can do whatever you want as long as you don't do this and it'll, you know, competing pressures are great. I'm like doing hand emotions here, which is absolutely useless to our audience so you can watch me doing these, like, you know, you can pretend that I am squishing things and like unsquishing thing.

• 19:30 Joshua

  It's quite comical actually from my end.

• 19:33 Kel

  Yeah. Anyway.

• 19:34 Joshua

  It's unfortunate for everybody else because they're missing out.

• 19:37 Kel

  Yeah. This is what happens when we actually use the camera to like help with our general communication. But then I started like trying to use body language, which is not particularly helpful for the audience. Simplicity, simplicity, voice only.

• 19:50 Joshua

  Alright. I will put some transcripts up at https://gettingappsdone.com. Please be sure to check out my website at joshuagraham.info and Kel's website piffner.com. We've been talking about keeping things simple. So keep things simple. Join our slack community at gettingappsdone.com/slack. Simple see? And, tell us your stories about keeping things simple or cases where you have seen things that really, really were not simple because we all have a lot of experiences in those. We'd love to hear about those so we can share them with others. Until next week, we'll see you on Thursday. Thanks for listening.