Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss:

• Simplicity

Transcript

[laughter]

Clayton Lengel‑Zigich:  It is hard doing that every week.

[laughter]

Derek Neighbors:  You don’t do it quite as good as Jade does.

Jade Meskill:  All right, go Roy.

Roy van de Water:  Hello and welcome to another episode of the Agile Weekly Monthly Podcast. I’m Roy van de Water.

Jade:  I’m Jade Meskill.

Clayton:  I’m Clayton Lengel‑Zigich.

Derek:  I’m Derek Neighbors and joining us today is the improv group.

Roy:  In the room next door.

[laughter]

Jade:  Yelling very loudly.

Roy:  Today we are talking about thinking simply, instead of thinking complexly. Jade, you and I have been…

Jade:  Accused of being simple?

Roy:  Accused of being simple.

[laughter]

Roy:  Can you tell me a little about what that idea means?

Jade:  Sure. We’ve been trying to…

[shouting in background]

Jade:  These guys are really… [laughs] yelling in there.

[laughter]

Roy:  I’d like to denote that they were entirely quite for the last 45 minutes before we walked into this studio.

Derek:  It’s like they’re Chicago trading for [indecipherable 1:10] .

[laughter]

Jade:  Buy! Buy! Sell! Sell! [laughs]

Derek:  You do the savings, I’ll do it.

[laughter]

Jade:  We’ve been working on some concepts of trying to write very, very small, simple applications, taking the UNIX philosophy and applying it to web applications to avoid the over‑complication that tends to arise in larger systems.

Roy:  What does an over‑complication look like?

Jade:  Usually a system where the responsibility is not very well delineated between either modules or different parts of the application. It tends to be very messy and sloppy, where it’s hard to tell where something…There’s no discrete functionality, I guess is the best way to say it.

Derek:  The way that I think about it is, if you had a web application where the code that displays the page where you enter in the details about a job is in the same place as the code that makes the…Say the job in a database in the same place in the code that schedules the job, in the same place in the code that runs the schedule of job, in the same place in the code that…They’re all in the same place.

Roy:  It sounds like everything is in the same place, it sounds pretty simple to me.

[laughter]

Derek:  Right, until you get everything in the same place, and then something goes wrong, or you want to change something. We have this problem with the Agile Weekly podcast or Agile Weekly website, where we had a bunch of things that were all clinched together.

If I took the approach of a normal, say, Rails application, like the standard Rails way of doing things. When certain pieces of the system got a little too big, or too unwieldy, it was hard to…it seemed like it was simple because it was all in the same place, but the real simplicity came when we broke those out into little pieces.

Then you have these…you’re going back to [indecipherable 3:08] sampler, mentioning the UNIX philosophy, with these little teeny pieces that all did their one little thing really well. They all just worked together.

Roy:  So why wasn’t it obvious to be that way in the first place?

Jade:  Because in the beginning that would have actually been more complex.

Roy:  So how do you know when you are doing something complexly instead of simply?

Jade:  I think when it becomes hard to explain, it’s probably too complicated.

Roy:  Is that like the metaphor ideal, like you should be able to describe whatever you’re building as a metaphor, and as soon as your metaphor circuit is breaking down that means that you’re putting too much in there? Is that…

Jade:  I think that’s a good way of putting it. If it’s not something that you can explain in a simple, conceptual way, it’s probably gotten a little bit out of control.

Roy:  Is this idea of complexity versus simplicity something that is on the overall project, or is it something that you see replicating down to the individual components of a method, or a class, or something like that?

Jade:  It’s an important recursive idea that happens. If you are being simple with the very small parts of your system, it’s easier to be simple at the larger scale as well.

Derek:  I think developers in general…they find it easier to think in these terms when they’re maybe down in the class with the [indecipherable 4:31] methods. I think that’s where they live, and all that stuff. Then you go up a few levels and even talking about what features you’re delivering.

I think a lot of developers might understand that concept at that level, but then it gets in the features and it’s like, “Well, the product guy said just build this stuff, and like well, OK, whatever, I don’t care.” Where I think that’s the even more important part, that’s an equally important part to be having this discussion about simple…

The planning meetings that we’ve been involved in lately for sure. I think we’re constantly driving towards trying to find something that’s simple, but not too simple, or not too simplistic. That’s a really hard thing to do.

Jade:  Yeah, I think being simple is hard.

Roy:  So this is the type of thing that I might solve using design patterns, like, “Can I just throw those at this problem?”

[laughter]

Jade:  We have an observer. Let’s find out…

[crosstalk]

Clayton:  I think the interesting thing to me, it’s always easier to add complexity that it is to remove complexity. When you start to get that Zen peace, it’s way easier to say, “Let’s start super simple and we can add what we need to add,” which is a very hard discipline to build.

Even if you’re talking product. That struck it for me. Can’t say how many times you’re talking about a feature and you’re up there at a whiteboard drawing it out, and somebody’s like, “Well that’s just too simple.”

At the end of the day, if you give this to the developers, it might turn into a two‑week feature request even though it sounds so simple right now, on the surface. As human beings we like to overcomplicate everything all the time.

Roy:  What drives that, though? Why do we want to overcomplicate things?

Clayton:  Some of it is uncertainty, or, we have this need for completeness. If we only say we’re going to show X, it’s like, “Yeah, but Y and Z and A and B are all available to us, too. We have to show them.”

“Why? What if we just showed X? What if X is enough? That is all that feature needs, why do we need the…”

“Because those other things exist, so we have to show them.” There’s very much this, because we can, we should, mentality.

Derek:  Another thing we see in our work is that people have an aversion or misunderstanding of iterative development. It’s like, if we don’t do this now, we’re…

Jade:  You mean incremental development?

Derek:  Yeah. If we don’t do this now, we’re never going to do it. If you guys don’t plan every single thing that we think we know, then we’re totally screwed. You guys are going to forget it.

To be fair, I bet you there’s a lot of product people out there who have teams that maybe aren’t the most reliable and don’t deliver what they say they’re going to deliver, and all those things.

When someone were to come in and say, “Hey, we’re going to do some really simple thing and ship it real soon,” it’s like, “Yeah…I don’t believe you.” Like, I’m not going to take that risk.

Clayton:  To me, it sounds like there’s a little bit of the 85‑15 rule, where you can deliver 85 percent of the value with 15 percent of the effort. Then you spend the other 85 percent of your time delivering the last 15 percent of the value.

I have worked with different product people, designers and architects in the past, where they want to get all 100 percent, because they know that if you spend 15 percent of the effort now to deliver 85 percent of the value, you’re never going to spend the other 85 percent to deliver the last 15 percent.

Which may be a really awesome business decision, but you’ll never be 100 percent as good as it could be.

Roy:  Some of it is, building off Clayton’s response there, is, there are a lot of teams where if you say, “OK, fine, let’s just do X.”

You say, “OK, let’s do Y.” “OK, let’s do Z.” Then you say, “OK, let’s do A.”

Then they’re like, “We’re going to have to re‑evaluate the whole thing. If you would have told us up front that we had to do A, we would have totally built this in a different way. Now that you want A, we just have to throw away the last six months’ worth of work, and start all over, and if only you would’ve told us.”

Once they get trained for that it becomes, if I know anything I must disclose it now and tell you that you have to build it into the app, because if I disclose it later you may come back and tell me, “Oh man, we have to throw everything out and start again.”

Clayton:  By disclosing everything up front and insisting that it all gets done, the product owner is really trying to maximize his choice later on down the road. His ability to choose later on.

Roy:  They’re trying to mitigate their risk, I believe. If they disclose all that and say we need to do all of that, then they think they’re mitigating the risk of somebody coming back later and saying, “Oh, we can’t do that because you didn’t tell us.”

In reality, what they do is increase their risk exponentially, because they make it so it becomes almost impossible to deliver what they’re asking for.

Jade:  The cognitive load becomes much more to deal with and “grok” all of those additional features when they’re not needed.

Derek:  It sounds to me like then you’re going to try to build a system that’s overly architected just in case you have to build any of the number of features you’re told you have to support.

Roy:  One thing recently that clarified this a bit more for me was that we had a situation where we wanted to deliver some features that would have been nice to have a database.

Having a database was a non‑trivial thing, so we used the file‑system. We had a table with a row and a column in it. That’s all there was.

Derek:  A folder with files in it?

Roy:  Yeah. We had a folder with files. That was sufficiently complex for what we wanted to do. I think some people hear that, and they think, “What are you, f‑ing crazy? You can’t use the file‑system…”

[laughter]

Roy:  “…Use a database, that’s crazy.” What we understood was, right now, for what we’re trying to do, for this little slice, that’s what we need right now. We acknowledged that that is not a long‑term solution, but it’s going to be as long‑term as it needs to be for what we want to do with it.

Jade:  It was very simple to replace.

Roy:  Exactly.

Derek:  I think where this started to come and play for me was when we started to cross the chasm, so to speak, in doing a lot more mobile development.

So things that we thought were pretty trick and pretty sleek and pretty simple and pretty small started to fall down really quick when a customer would say, “hey by the way, I need an android version or an iPhone version of this.” and I was like, “oh shit, like dude like how in the, man!”

And so when it got to the point like “OK, let’s make everything like API and we’ll have the front end consumed of the web version consume that API and hey now we can have the iPhone version.”

Jade:  Anything can use this API

Derek:  API right like it started to like I think click a little bit more just even in that that you could kind of separate this concerns a little bit better.

Then you can start to say “OK how about make perhaps even smaller and smaller,” and keep slicing those so that they are easier and easier to replace, so when you do find something new you might not have to rewrite the whole system to do something. You might be able to rewrite a little piece of the system to do something which is a lot less risk and a lot easier to do.

Jade:  That’s kind of where [indecipherable 11:27] and I got into writing these micro‑applications that had very discreet functionality.

We were having trouble, even with that simplified view of things of just having an API and a web service that was still wasn’t good enough. There was still too much co‑mingling of functionality between different classes and you know, the abstractions were good enough.

We took a crazy stance and tried to work on like how can we build the smallest possible thing to do this one job, and then chain all of those things together as needed?

Roy:  I felt like that worked for those instances I am curious to try more places and see how well it runs across the board.

In that case it was a project that only ended up being a collection of five or six of these smaller apps, but when you start to build a more complex user experience where you have a whole store form or something where the user [indecipherable 12:24] component you try to keep all of those pieces separate. I wonder how well that’s going to play together.

Clayton:  I feel pretty confident in it from the next example like; pick any five UNIX commands. It could probably do a bunch of stuff. If you chose wisely.

Derek:  Yeah, It does fall down at certain point though. What I mean by that is, there’s a whole lot of things people do, they don’t do with Unix commands any more. You could use “set OK” and “grip” to do a whole lot of things.

Jade:  Everything

Derrck:  But you probably open up “vi” or “sublime” to do it instead because the interface is easier even though its [indecipherable 13:00] all mashed into an application than a whole lot more than those simple things.

I think there are this kind of. It is nice to assemble them small‑ly. Into small little apps that interact but when you have to chain too many interactions together, the complexity of remembering what and how to chain things starts to become cumbersome.

Clayton:  That and when there’s like a whole bunch of apps that you don’t even know existed.

Roy:  Yeah

Clayton:  So you start rewriting them yourself

Derek:  Yeah. What tends to happen is when you have things that have common things you start to see those assembled into other apps.

I would say that OK and grip get used within most editors the developers use today. Because they make sense to kind of bundle natively into an editor rather than a drop out to a shell and do them. I think the work that those things did and put in place are straight up stolen and re‑used inside of those editors.

Jade:  It’s like when we talked about, we built a simple app but at some point it became too complicated. It was simpler to take a different approach of writing smaller, more complicated apps. Think this is the contrary example of at some point that becomes absurd. The interactions are too complicated.

Derek:  Right.

Jade:  Now you find a simpler way to merge those things together.

Derek:  It goes back to; it’s always easier to get more complex.

If we’ve got the set the OK, the grip, and we need to put them all together like we know those things really well now and so we know how to assemble them into an interface or into certain things a lot better than if we would have tried to build those things as part of the bigger complicated thing to start with.

Jade:  I think that’s where some of the ideas around, like hexagonal design can come into play. Where you’re composing complex systems out of simpler modules and simpler pieces.

Clayton:  We’ve been talking a lot about in terms of software, but this same stuff applies to process things.

You can take the components and do them very well and you can build some sort of process that works and maybe it gets too big sometimes or maybe you decompose or whatever, but it’s not just whole scale, you know.

From a coding example, jumping straight into some massive java architecture thing and that’s the same thing as like what you’re going to get on the juror train and see if this mother app…

[laughter]

Clayton:  …Or it’s like trying to get a good user story. I am like “let’s try and get good at talking to each other as a team first.”

Derek:  Let’s get good at working together.

Jade:  Yeah, let’s try those things first and then you know, you can juror me to death.

Roy:  Hey I will see you next month

[music]

Presenter 1:  Is there something you would like to hear in the future episodes, head over to inagram.com/podcasts or you can suggest a topic or guest.

Presenter 2:  Looking for an easy way to stay up to date with the latest news, techniques and events in the agile community? Sign up today at agileweekly.com. It’s the best agile‑content delivered weekly for free.

The agile weekly podcast is brought to you by inagram technologies and recorded in gangplank studios in Chandler, Arizona.

For old episodes check out inagramtech.com or subscribe on iTunes.

Presenter 3:  Need help with your agile transition? Have a question and need to phone a friend? Try calling the agile hotline. It’s free, call 866‑2448656.