Dave, Who Stinks!
Marco:
Insert music here.
John:
Oh, you're not going to play it for me?
John:
I want to hear the music.
Casey:
I'm not set up.
Casey:
You'll hear it.
Casey:
Damn it, man.
John:
Boo.
John:
Okay, so the first item in follow-up is when we talked about Final Draft and the Script Notes podcast last week.
John:
And we got a lot of feedback on that, also directly from the two hosts of that podcast.
John:
And...
John:
As it turns out, I definitely and perhaps also Casey misattributed to the two hosts statements which were not theirs.
John:
In particular, discussing their stance on software pricing.
John:
After listening to the podcast, I was under the impression that they thought software...
John:
If not, should be free, should definitely be much lower priced.
John:
And I cited an example on the podcast of them saying, well, Apple's operating system is free.
John:
That was not the host of the podcast that said that.
John:
That was Joe Jarvis.
John:
He was the product manager from Final Draft who was on the podcast.
John:
Now, I know how people feel when they say they can't identify our voices as separate things because if you listen to the podcast for the first time and you're, you know, 15, 20 minutes into it, you lose track of who's speaking.
John:
i didn't lose track so i think casey said that in the last show and i said that and marco tried to correct us and none of us could remember for sure at the time but marco was right i could yes yes well you were you weren't all that insistent i've said i thought that was them and casey said yeah i thought that was them too and you said i thought it wasn't but none of us had the podcast in front of it and speaking of that there is actually a transcript of this podcast which marco will put in the show notes
John:
uh that uh will give you a text version so you don't have to listen to the podcast i know people sometimes don't want to listen to audio and scrub to the parts you can just look at the text version which is much faster to read and find the discussion of this topic so i apologize to both of those guys for making it sound like they thought all software should be free and in fact john august sells some software of his own and so he is not just a observer of the software industry but he's also a participant on the other side of the coin
Casey:
Yeah, yeah, I definitely was part of screwing that up.
Casey:
And I will say that I was completely in love with listening to that particular episode of that particular podcast, because was it is it Mark Madnick?
Casey:
Is that right?
Casey:
Yeah, who is the CEO of and co founder final draft, to my ears was straight out of New York.
John:
I can tell his voice from the others, definitely.
Casey:
And so that's what I was going to say.
Casey:
He was the only one I could, without question, definitely place who was who.
Casey:
Everyone else, I was taking a shot in the dark.
John:
Yeah, we got a lot of feedback from people who are talking about the screenplay format and people who have many alternate apps for screenplays.
John:
And it looks like that ecosystem is actually pretty vibrant and seeing some new life in terms of alternate applications and alternate formats for writing screenplays.
John:
So it's actually much more lively than it might seem if you just listen to this and think everyone is stuck with Final Draft.
John:
Yeah.
John:
the young and upcoming people are seeking out alternatives to file graft and those alternatives exist.
John:
And in fact, there's a format kind of like Markdown that you can use to produce a screenplay and any application like Markdown, any application that can just edit text can edit that format.
John:
And then you can convert from that format to the quote unquote real screenplay format.
John:
So that's really opened up the field to a lot of other editors.
Marco:
which i also mentioned during last week's show yeah but you mentioned it by name but i didn't know what the name was so i didn't know you know if you if you had said it's like markdown for screenplays i would have been like oh maybe you said that this is where you can insert the clip of you saying that i don't think i did but yeah i don't think i talked i think i gave one sentence about mentioning this fountain format but yeah i otherwise uh otherwise the follow-up is i was right good oh we'll get to when that's not so true don't you worry
John:
there has been plenty you were but you were if you had been more insistent like casey and i both got it wrong and who said that and you're like i think it was the other guy you weren't sure it was the other guy either or sure enough to say no it totally wasn't that guy's i think i did but that's okay you can insert that clip there you go i'm just trying to give i'm just trying to give you places where you can insert audio
John:
There were parts in there.
John:
The other part of it is that Craig and John did at various times say things like, and we know the price of software is going down and things that used to cost a lot cost more, but they were saying it as a sort of a offering up of the idea that they understand where the final draft guys are coming from.
John:
Not that these were positions they agreed with.
John:
So if you read the text, it is much more clear that they are...
John:
Yeah.
John:
Trying to provide like trying to say that I empathize with your situation.
John:
I understand that in the software market, software is apparently being devalued.
John:
And then they would say, but and then go on.
John:
I think Craig is still closest to to walking that line and saying that he doesn't think an upgrade just for retina should be worthwhile.
John:
But again, it gets back to the specifics of this one program that they don't like that hasn't been updated for a long time and not a general statement about all software.
Marco:
Yeah, and I think that specific complaint about Retina being the thing that should have been free, I don't agree with them on that.
Marco:
I agree if they want to complain that the updates in general to Final Draft haven't included enough new features to be worth their price, that's a different story.
Marco:
And charging for what is really a bug fix, that is also a different story.
Marco:
But Retina is actually like...
Marco:
supporting new hardware, and that's not necessarily, quote, a bug fix.
Marco:
It's like if you have to support a new version of the OS.
Marco:
You don't give that to everybody for free if they're all running a really old version.
Marco:
I think their problem with this was all tied up in the overall problem of Final Draft being crappy and not really having any kind of development pace for a long time.
Casey:
All right.
Casey:
So the other bit of follow-up that we have is regarding whether or not it's wise to treat warnings as errors in production code.
Casey:
And I believe this came from the go-to-fail conversation.
Casey:
Is that right?
Marco:
It was kind of a separate branch.
Marco:
Yeah.
Marco:
It was a separate topic.
Marco:
But yes –
Marco:
There is the culture of using the w-all flag or w-everything flag or the various permutations thereof that specify the really esoteric errors in C, or esoteric, as you would say.
Marco:
And that kind of morphs into my position of, with my web development now, I'm doing...
Marco:
my php framework such that all warnings and notices in production even are treated as exceptions i was doing it in development for for the last few years but now even in production all warnings and notices are exceptions and i asked the listeners uh during last week's show because john you john and casey you guys uh severely disagree with that saying that in practice to paraphrase your arguments uh if you'll if you'll permit me in practice that um in a production environment
Marco:
Once you get beyond a one-person operation, that gets really tricky.
Marco:
You might have other people deploying PHP updates to the server and breaking the site in the middle of the night.
Marco:
And maybe it's not that important to break the site for some minor reason.
Marco:
It's not worth it.
Marco:
And it's better to keep everything up as much as you can and just log the warnings.
Marco:
So I asked the listeners...
Marco:
If they worked in a big organization that either has a really important web presence or is known for being really good at tech like Google or Amazon, I asked them, what's your policy in your organization?
Marco:
Please let me know in the feedback form.
Marco:
Boy, did they.
Marco:
Oh, my God.
Marco:
I think it's pretty safe to say that not only did I lose this argument,
Marco:
But I'm pretty sure I actually lost it unanimously.
John:
Well, there's no winning or losing based on what people say.
John:
A bunch of people sending feedback doesn't mean anybody won or lost anything.
John:
I've been thinking about it.
John:
I think I can frame this.
John:
The reason Casey and I kept disagreeing with you and the reason we had a disagreement last show is it's all about the framing of the thing.
John:
The thing I put in the show notes, which I'll talk about at the end.
John:
the major framing of the topic was that in the beginning, like the topic came up and you, and you mentioned something about it.
John:
And in the beginning, both Casey and I stipulated that there are certainly situations where it is both feasible and the right thing to do to elevate warnings, errors in production.
John:
And we gave the example of you, like you're,
John:
you control everything about it.
John:
You're one man shop.
John:
You're doing the client on the server side.
John:
Like, you know, you're not running a bank.
John:
Like it's all, you know, for a podcast app and, you know, it's like, it's reasonable at least.
John:
Uh, and then, and then you stipulated their, their institutions in which it is, uh, unfeasible to do this because of something about like, it's a different department that controls that, or the developers are too far away from it.
John:
Or, uh,
John:
Things have to be up all the time, and that's the most important thing.
John:
And you stipulated that if there's some sort of ailment in the enterprise-type company, it's also a practical concern that you might have to do that.
John:
But every time Casey and I tried to come up with a scenario where it wasn't just something that you have to do because of real-world practical concerns that are just such a shame, but that it was actually the right decision, not because of some sickness in your organization, but actually because...
John:
I don't know.
John:
organizations that have some sort of organizational sickness that requires them to do this.
John:
Isn't that a shame?
John:
Yes, I understand it's a reality in your life, but it's not really the right thing to do.
John:
And what I was trying to convince you of last time that I think is still the case is that there are situations where it is actually the right thing to do not to elevate warnings to exceptions in production.
John:
And the difficulty of convincing you of that, I think, has a lot to do with
John:
like us not since this came up as a tangent us not sort of being on the same page ahead of time as to what the heck is a warning what do you mean by a warning like we got to it from like the warning flags in the compiler but that's obviously not what we're talking about because that's like when you're compiling the program before you've deployed it there is no you know that those are different kinds of warnings and i was trying to think of a way to like
John:
get us to agree on what warnings are but that's almost impossible because we have to talk about specific technologies involved and where do they come from and i thought of like the most extreme example is like imagine there was just a random number generator in your code and 0.01 percent of the time on this particular line it would emit a warning and then you would elevate that to an exception in production and you'd be like well of course i'm not going to turn that on because i'm just signing myself up for downtime uh
John:
That is pretty much what warnings are like in many situations, in libraries that you didn't write, that you have no control over, in languages or runtime pass-through code that could emit warnings.
John:
And I think in that situation, that absurd situation, obviously, you would agree that if there's something randomly elevating things to exceptions, no, you wouldn't want to turn those into warnings in production.
John:
You wouldn't want to turn them into exceptions because then you're just signing up for downtime.
John:
And lots of other people who wrote in who belong to these organizations that have these problems that cause them not to be able to do what you think is the best practice,
John:
described why they think it was the right decision, but I don't think any of them were convincing that would have convinced you or should have convinced you that it really is the right thing to do.
John:
So I'm wondering if reading all those things, were you convinced that this is actually the right thing to do, to not elevate them to exceptions in some situations, and not just merely that it's something that poor suckers have to do?
Casey:
Now, before you answer that, Marco, let me jump in.
Casey:
There's a couple of quotes, just three quotes that I'd really like to read really quickly that I think really kind of nail this home.
Casey:
And unsurprisingly, I agree with everything John just said.
Casey:
The three quotes are from Alex Tall, and Tall was in all caps.
Casey:
In practice, the C-whatever-O, CIO, CEO, etc., doesn't give a flip about anything but their own agenda.
Casey:
In the end, Marco has the correct idea, but outside of small and extremely well-structured organizations, the practice falls apart.
Casey:
And I think that that's exactly what John and I are both saying.
John:
Well, no, but that's the guy who's in an organization that has problems.
John:
He's admitting that his organization has problems that cause him to have to do what he knows isn't the best practice because, oh, such a shame.
John:
That's not really what I'm saying.
Casey:
Okay, but I guess the way I read that was Marco's idea is absolutely right.
Casey:
It's just not always applicable.
John:
No, I don't think his idea is absolutely right all the time.
John:
That's what I'm saying.
John:
Isn't that what I just said?
Casey:
Well, kind of.
John:
Well, keep going.
John:
Read the other feedback because I don't know.
Casey:
Okay.
Casey:
So the other two were – secondly, there were two different engineers from Amazon that wrote in.
Casey:
And I'm paraphrasing kind of the mutual message that both of them said.
Casey:
And so this is not verbatim.
Casey:
But they said, I get why Marco says what he's saying, but when you deal with this kind of scale –
Casey:
Something is always broken.
Casey:
And so in the example of Amazon, there's so many moving parts that no matter what you're doing, no matter what happened, there is always going to be something that isn't quite right.
Casey:
And so you kind of have to plan for that.
Casey:
And there's not a lot you can do about it.
Casey:
And then finally, Anonymous said, we don't guarantee uptime with code quality.
Casey:
We guarantee uptime by having an institutional strength in reacting to problems.
Casey:
And this is kind of getting into a different tangent, but I just thought it was a very interesting point as well, that even if your code has no smell to it whatsoever, that doesn't necessarily guarantee uptime.
Casey:
And really, guaranteeing uptime is more about just being able to react to issues better.
Casey:
So anyway, those are the three quotes I have.
Casey:
So I apologize.
Casey:
Marco or John, feel free to carry on.
John:
Well, so before Marco has a chance to respond, I want to give what I thought was the strongest argument sort of buried in our feedback and that that many people have offered.
John:
And it gets back to kind of like getting back to the final draft thing where the CEO final draft was coming on that podcast and trying to make all his problems, your problems.
John:
And a lot of the people who were.
John:
discussing the problems with their big organizations that, that, that make this non feasible also said basically, and you know, more or less, and even if we could do this, it's essentially making your problem.
John:
And your problem is basically, I want to ensure that my code is warning free, but I think that will produce higher quality code.
John:
It's turning your problem into your customer's problem because, uh, it,
John:
You know, once once you turn that warning fatal in production, you have some sort of, you know, avoidable downtime that causes you to.
John:
Well, I'm sure we're going to go fix it now, because once there's downtime, everyone runs around like their hair is on fire.
John:
And that will make sure that we don't let human nature go through.
John:
And if we merely log the errors, maybe we'll just ignore them and they'll build up in a log.
John:
So this is a way to guarantee that we have code quality.
John:
But the way you're guaranteeing is at the expense of your customers.
John:
Someone just wrote in the chat room.
John:
I lost the name.
John:
I think it was.
John:
What was it?
John:
What something?
John:
Anyway, someone just wrote in the chat room, enjoy this downtime.
John:
I didn't trust myself to take a warning seriously, like message to your customers.
John:
And what I would say, the strongest argument in this vein is that by elevating warnings to errors in production and making your problems, your customers problems.
John:
If that's the only way to ensure that you stay in warnings clean, that in itself is a sign of an unhealthy organization.
John:
And a healthy organization would have a policy to log warnings and have them addressed in a timely manner, which was suggested in the last show.
John:
And a lot of people wrote it and they said this was the policy.
John:
So I think if this is the only way you can avoid the pitfalls of human nature and make yourself address these things, that's a sickness that's worse than the sickness that lets you not do that.
John:
Because...
John:
A lot of these people who are in organizations that did seem very competent say we have a policy.
John:
A warning gets logged.
John:
It makes a ticket.
John:
Someone has to deal with it in a fixed amount of time and they can execute in that policy.
John:
So that's their stopgap against human nature, not pushing it off onto their customers and causing them problems.
John:
And that's why I think there are actually situations where it is the correct move, not just the pragmatic one, not just the unfortunate.
John:
I'm sad I have to do this one, but actually the correct, optimal, no ends, ifs or buts about it policy.
Marco:
Mostly, I'm not going to argue this anymore because I've clearly been proven wrong.
Marco:
And I can see... I understand and accept a lot of the kind of arguments that have been put up.
Marco:
Just to clarify, though, when I'm talking about warnings in production...
Marco:
The kind of warnings that I see on my apps are usually things like MySQL truncated to value because I passed one that was too long and my application code is not validating that for length properly.
Marco:
Or something else with MySQL like the connection was dropped in the middle of a transaction and my library didn't reconnect.
Marco:
And that kind of thing, that's both the kind of thing that I want to know about.
Marco:
And so I think you're right, John, that yes, making it your customer's problem is not ideal.
Marco:
And yes, if you have the structure in place where if warnings just get logged in a database somewhere and then you're required to act on them, that's great.
Marco:
And if you have that kind of discipline within your organization, that's awesome.
Marco:
But I think so many organizations don't have that in practice.
Marco:
There's the big organizations that can have procedures like that.
Marco:
And they don't always, but usually big organizations are more likely to have something like that.
Marco:
Where this tends to fall apart and where a lot of software methodologies fall apart is – and a lot of discipline falls apart in our industry is in the small and medium-sized shops.
Marco:
And in that kind of situation where you don't have a lot of procedures in place, you don't have a lot of infrastructure in place, you don't have –
Marco:
giant different teams doing different parts of it.
Marco:
Maybe you have between 2 and 20 people in your organization.
Marco:
That's a lot of times where discipline goes out the window.
Marco:
And if you get a bunch of logged warnings in production, you might not fix them or you might not even see them.
Marco:
And so I do think there are a lot of situations where enforcing this...
Marco:
Enforcing – blowing up production with warnings as a disciplinary tool to combat human failings.
Marco:
I think there's still a place for that.
Marco:
I will yield to the counterargument on this being the right idea for everybody and even for a larger organization.
Marco:
I think that's been proven that that's probably bad.
Marco:
But I think you could apply this kind of rule of crashing in production on everything to more than just me.
John:
i think there's more of a place for it yeah it's not just you but you're like like again casey and i stipulated there are situations where that's valid in all cases we're trying to find the correct solution is the one that plays to the strengths of the particular situation the strengths of a small shop a one or two man shop a shop working on something that it doesn't matter if it's down for a little bit like a game or you know something that's not super critical that is you know it's not not necessarily a strength but like that is that's the shape of that beast is that you know you you can take advantage of this uh
John:
since you're a small shop and doing something non-essential, you can take advantage of this to make sure that you don't ignore the errors because, you know, you're basically, you're hacking.
John:
It's one of those self-hacks, like when you do something to remind yourself to exercise all the time.
John:
And, you know, it's one of those life hack things or whatever, but on a small scale.
John:
And that makes perfect sense.
John:
And then in the larger organizations...
John:
They have different strengths, and one of the strengths of a larger organization is they have the ability to have policies to be imposed on people.
John:
It's very hard to have a policy imposed in a five- or ten-person company because who's going to be the big guy imposing the policy?
John:
It's going to be your friend who sits next to you, and you're not going to take it seriously.
John:
That's a weakness of small organizations and a strength of a big one, so you have to pick the solution that's appropriate for you.
John:
We think it's not just for Marco, but for other organizations where it may be possible that this may also be the best solution.
John:
The tricky part, and it gets back to what I wrote in the show notes, which is
John:
what is the nature of warnings and warnings are just like without agreeing on that it's like it's very hard to have a discussion about this because you know uh transaction aborted or value truncated like everyone would agree that uh i mean regardless even like you know value truncated i think that should be elevated to uh an exception in almost all situations but the warning about like uh
John:
you sure you want to use this function?
John:
Because a lot of times people use this function and really they mean that function.
John:
And that happens at runtime because you never hit that code path or a particular value.
John:
And you're totally like, yes, I use the right function.
John:
Don't worry.
John:
That's why I get back to the random number generator.
John:
Like that's the extreme thing is like,
John:
Some code that you didn't write and some library that you don't control decides that it wants to send you a nice friendly message, depending on if it gets, you know, the data value is over five and it's past 3 p.m.
John:
on a Tuesday.
John:
And the system clock says it's past the year 2010, which I thought would be the distance.
John:
And it decides to emit a warning.
John:
I would consider that a problem if you didn't plan for that and catch it.
John:
No, but I mean, like, if the warning is like, are you sure you wanted to call this function?
John:
Maybe you meant another one.
John:
Like, it's advisory.
John:
It's guessing.
John:
Like, you're not the—if you could find the person who wrote this warning, you'd be like, stop writing that warning.
John:
Like, because they're human beings writing these warnings, and the warnings may have nothing to do with any kind of erroneous or unexpected situation, but merely maybe giving advice.
John:
right and advice is fine in lots of situations like again get back to the random number generator a lot of times warnings to me feel like they might as well have just been my code was running fine and and some random number some random number generator decide i'm going to send you a friendly message right now that had nothing to do with anything that was not useful and the only reason i have to react to it is to add whatever i need to add to make that warning go away if i
John:
can because sometimes you can't because it's in a compiled library that you use that you don't control that's not acting in a way that is unexpected or wrong but that that author decided to give you advice about something and that is the worst kind of warning the worst kind of runtime data-driven warning that you don't control and so that's why i think a lot of people have different positions in this because when they think of warnings it's like oh it's something i have to react to and when i think of warnings i often think of
John:
the only reason I have to react to this is to shut this person up because they don't know our code or they're trying to be helpful and give advice or suggest a different way that we could do things.
John:
And it's like, I don't want your suggestion now at runtime.
John:
I, you know, I need to now blank that out of the logs because I can't get rid of it.
John:
And it's not telling me anything useful.
John:
Um,
John:
Uh, so as with most things, when we're discussing this, trying to like agree on the premise, like that's why it's easier to talk about a specific technology or a specific version of something.
John:
Cause then you can kind of say, here's the set of warnings that come out.
John:
Are we okay elevating these all to exceptions?
John:
And then you have to look at the size of your organization and all that other stuff.
John:
But if you just say warnings in general, everyone's got a different picture in your head of what we're talking about.
Marco:
All right.
Marco:
We are sponsored this week by something pretty cool, something pretty new here.
Marco:
It's called In Flux, and this is a music album from Brave Wave Productions that highlights the diverse and ever-changing nature of music.
Marco:
It's a blend of chiptunes, rock, electronica, and more, and it features diverse musicians from around the world.
Marco:
Brave Wave's music is dedicated to exploring the interplay between video games, music, and nostalgia.
Marco:
You might know them from their previous World 1-2 albums.
Marco:
Influx's theme is collaborations between the composers of the East and West, featuring original music from Manami Matsumi, Tim McCord of Evanescence, Keiji Yamagishi, Akira Yamaoka, Sayori Kobayashi, and more.
Marco:
Get Influx today on iTunes, Bandcamp, or their online store at bravewave.net.
Marco:
So go to bravewave.net for more info.
Marco:
Now, rather than keep talking about this music for another 90 seconds, I asked them if we could just play a couple of samples from the album, and they said yes.
Marco:
Here's some samples from In Flux showing off two different styles in the album, and there's a lot of different styles on here.
Marco:
¶¶
Bye.
Marco:
All right, that was from Influx by Bravewave.
Marco:
Go to bravewave.net to preview more of it or buy a copy.
Marco:
Once again, that's bravewave.net, and the new album is called Influx, two words.
Marco:
Thanks a lot to Bravewave for sponsoring our show.
Casey:
You know, I'll always have a soft spot in my heart for chiptunes because it's straight out of childhood.
Casey:
You know, that's when even I cared a lot about Nintendo and things of that nature.
Casey:
And now I'm not that into gaming, but I'll occasionally stumble upon a chiptune album like this one and just absolutely love it, if for no other reason for the nostalgic factor.
John:
You wouldn't give me the bleeps and boops theme song, but we'll accept bleeps and boops sponsorships.
Marco:
Uh, yeah.
Marco:
Do you want to sponsor John?
John:
I hardly endorse bleeps and boops.
Marco:
All right.
Marco:
So I guess we should talk about software methodology.
Marco:
But first, we want to talk about any of these new bugs that have come out or Apple buying Nintendo.
Marco:
What else happened?
Marco:
A lot happened this week.
Marco:
CarPlay.
Marco:
We're not going to do that before software methodology.
Marco:
CarPlay.
Marco:
Right.
Marco:
CarPlay was interesting.
John:
We could do software methodologies first if we want Casey not to explode.
Marco:
Although, you know what?
Marco:
I'll tell you what.
Marco:
Do you hear the fans from my Mac Pro?
Casey:
I do not.
Casey:
Exactly.
Casey:
Wait, is that your new Mac Pro?
Marco:
Yep.
Casey:
Wait, what?
Casey:
You got it?
Casey:
It came today.
Casey:
Oh, my God.
Casey:
Are you serious?
Casey:
Yep.
Casey:
Are you... I don't even know what to say right now.
John:
I am so serious.
John:
You need to say something about software methodologies, Casey.
John:
Now is your time.
John:
Okay, so... It's pretty good, by the way.
Casey:
Don't... No!
Casey:
Stop!
Casey:
Oh, I hate you so much.
Casey:
All right, so a long time ago... Yeah, it's fantastic.
Marco:
Here, I posted this.
Marco:
Here, here's a picture.
Marco:
You can actually see just as proof.
Casey:
You waited just for this very moment, didn't you?
Marco:
I did.
Marco:
I've kept it off of Twitter all day.
Casey:
I need you so much.
Casey:
Oh, God.
Marco:
So, software methodologies.
Casey:
I was going to say, if this is the longest troll ever, half of me admires it and half of me is about to get in the car and drive to that town in which you live and murder you.
Casey:
Oh, God.
Marco:
And this is why I kept it off Twitter all day.
Marco:
For you, our listeners, to hear Casey's genuine reaction because he really didn't know that I had it yet.
Casey:
I hate you so much.
Casey:
All right.
Casey:
So a long time ago in a galaxy far, far away on a podcast very similar to this, we talked about...
Casey:
So we touched upon the idea of talking about software methodologies.
Casey:
And what we mean by that is, you know, how do you write software?
Casey:
How do you do that, especially in a group atmosphere, which means Marco probably doesn't do this very often anymore and hasn't done it in a long time.
Casey:
I haven't prepared anything specific about this, so I'm just kind of going to kind of ad lib.
Casey:
But a lot of my time, my professional time has been spent, actually all my professional time has been spent working in teams.
Casey:
And...
Casey:
I've found over the years that there are very, very, very many different ways of going about authoring software.
Casey:
And I should say right now that if you're not the kind of person that really gives a crap about how to write code, then this might be applicable to you anyway, because many of these things that we're about to talk about are actually applicable to just about any project.
Casey:
And
Casey:
So there's a couple of different, well, there's many, many, many different ways of going about this, but a couple of very, very obvious ones.
Casey:
And the way that I wrote most of my code in my career is by using a technique called waterfall.
Casey:
which is to say you do all the planning up front.
Casey:
And so that means you do a lot of planning up front.
Casey:
You do a lot of thinking up front.
Casey:
You have a lot of meetings up front.
Casey:
And you pretty much do everything you can before you write a line of code.
Casey:
And you do that all first.
Casey:
And you do no code until you are ready to pretty much just phone it in because you've specified almost everything up front.
Casey:
And the alternative to that, or the most obvious alternative to that, is something called Agile, which is to say, you just kind of fly by the seat of your pants and see what happens.
Casey:
So they're very, very different, and there's pluses and minuses to both.
Casey:
But before we dig into that, John, what do you use in your day-to-day job today?
John:
I don't use any method or methodology, depending on what you think is an actual word, that you could name with a proper noun with a capital letter.
John:
We use some vocabulary from the world of Agile, but it's kind of pointless.
Yeah.
John:
And there's no real we have a system and we have processes, but we don't have we're not we're not following any kind of methodology from a book or a paper, even within the organization.
John:
The processes that we have are mostly methodology agnostic.
Yeah.
John:
So I would not put us into any one of these bins.
John:
And in past jobs, I've in fact never been at a company that has adhered to a particular system for doing software development that I could name with a capital letter.
Casey:
So let me instead answer that.
Casey:
Well, OK, I'm sorry.
Casey:
I should ask Marco, what do you do, Marco?
Casey:
Or what did you guys do at Tumblr?
Marco:
The answer to both of those is the same, which is a long, awkward silence.
Casey:
All right.
Casey:
So I've had the benefit and detriment of using kind of a little bit of everything.
Casey:
I've used Agile in a strict sense.
Casey:
I've used Agile in a not-so-strict sense.
Casey:
I've used Waterfall in a strict sense.
Casey:
Waterfall in a not-so-strict sense.
Casey:
And what's interesting is there's a lot... It doesn't really matter what methodology you use or method or whatever that you use.
Casey:
A lot of it falls down to the team and what the team is comfortable with.
Casey:
And...
Casey:
So I've had a lot of experiences where I've tried to use Agile and in doing so in client work, in my personal experience, is going to be made or broken by the client.
Casey:
So the way Agile works, and I probably was being a bit flippant earlier when I said it's all about flying by the seat of your pants.
Casey:
That's really not it at all.
Casey:
The way it works is you spend a little bit of time up front planning the next couple of weeks or the next sprint, as it's called.
Casey:
And so you spend that time figuring out, what are we going to do for the next couple of weeks?
Casey:
And the way that typically works is you come up with something called user stories, which is to say, you know, as a user of this online banking system, I would like to make a deposit.
Casey:
And somebody will – or you as a team will decide, all right, how long do we think that will take?
Casey:
But not in terms of hours, which is a typical consulting way of doing things, but instead in terms of something called points.
Casey:
And points are –
Casey:
Not arbitrary, but not really defined either.
Casey:
And so what that means is typically you'll say, okay, of all these user stories, we agree that depositing a check is, for whatever reason, a one-point story.
Casey:
That's very, very, very simple.
Casey:
And so we will say that we will judge all of our other stories based upon the difficulty of this story, this one-point story.
Casey:
So in the beginning, you do sprint planning and you say, OK, for the next two weeks, we think we can cover 20 points worth of effort.
Casey:
And so what do we think we're going to do?
Casey:
And so you'll figure out these are the things that we're going to put in the current sprint.
Casey:
And then we'll have a backlog of things we'll get to if we can and an icebox of things we'll get to way in the future if possible.
Casey:
And you do your sprint usually for two weeks, but not always.
Casey:
And you do your sprint for two weeks and you try to figure out – you try to get all these things done.
Casey:
And at the end of that sprint, you'll see, okay, well, we didn't do as much as we wanted.
Casey:
So actually we ended up only doing 18 points worth of work.
Casey:
and we'll consider 18 points are velocity for the next sprint.
Casey:
And this is all very boring on the surface, but over a couple of sprints, you get to figure out what is your team's velocity.
Casey:
And your team's velocity can get you to a position that you can actually plan
Casey:
how much work you're going to do in the future.
Casey:
And that's the power of Agile is when you've gotten a couple sprints under your belt and you've gotten your velocity and it's relatively repeatable and reliable.
Casey:
And then at that point, you can predictably figure out, okay, given all the work we have left to do, then how much time will it take?
Casey:
And so I've done Agile several times, all but one of the times it failed spectacularly.
Casey:
There are many reasons it failed spectacularly, but in my personal experience, the most obvious and hugest reason that it failed spectacularly is because our client didn't really get it, which probably falls down to us not really explaining Agile properly to our client.
Casey:
But the one time it worked well, our client really got into it and really understood, okay, these point things don't really translate to ours.
Casey:
And they don't really translate directly to anything specific.
Casey:
But these points are kind of like currency.
Casey:
And if I decide out of the blue...
Casey:
that I really want some new feature.
Casey:
And if I ask the team, all right, how long do you think this will take?
Casey:
And they say, well, it's going to be three points.
Casey:
I know as the client, as the product owner, that I'm going to need to take away three points worth of effort if I want to shimmy in these new three points that I've just come up with.
Casey:
And when it got to the point that we and the client both understood that points are currency and really had faith in the system, it worked unbelievably well.
Casey:
But generally speaking, none of that happens.
Casey:
Instead, what you end up with is Scrum or Fall, which is you do a bunch of work up front, have stand-ups every day, say you're working in Agile, and none of it works, and it's a complete disaster.
Casey:
That's basically all I have to say about that.
Casey:
This sounds awful.
Marco:
Is this what working with other people is like?
Casey:
Which part?
Casey:
I'm asking honestly.
Casey:
Which part sounds awful?
Marco:
All of it.
Marco:
The coins.
Marco:
It sounds condescending.
Marco:
The points, I mean, whatever.
Marco:
I mean, it's like... It just sounds... I mean, there's been so much said and written and experimented with and tested over the years about how to organize and manage engineering tasks like this.
Marco:
Sorry, programming tasks.
Marco:
Sorry to the real engineers out there.
Marco:
And...
Marco:
Most of these systems boil down to ways that are easily exploited for laziness or personal gain and or ways that are just very obfuscated and potentially condescending or infantilizing.
Marco:
And I think I would have a hard time with some of this.
John:
It's not infantilizing.
John:
It's just having a boss.
John:
I know it sounds the same from your perspective.
John:
Someone else telling me what to do.
John:
I'm not a baby.
John:
Get out of here.
Casey:
So is there a specific thing or things that you take issue with?
Casey:
Because your reaction, to be honest, is not unreasonable, especially knowing the frame of mind you're coming from.
Marco:
It's hard to explain.
Marco:
I think just the whole setup sounds like...
Marco:
It sounds like a lot of people need something to do with their jobs who aren't necessarily programming all day, whether they're managers or whatever you want to call them.
Marco:
And managers have a role.
Marco:
Good managers are very, very helpful.
Marco:
But there are a lot of managers out there who aren't good.
Marco:
And so much of this stuff sounds like the creation of...
Marco:
mediocre managers trying to occupy their time and prove themselves worthwhile by coming up with some kind of system, some kind of procedures and frameworks and abstractions over people doing work and the process of building software.
Marco:
And
Marco:
maybe one of the reasons why these things often fall apart or don't work very well is because, like you just said, okay, well, this feature, you said in an ideal case, you can take the points of people's productivity and you can say, okay, well, this feature will cost three points.
Marco:
That's just, that's all it is, is estimating time, right?
Marco:
And we're always, our entire industry is, myself included, is horrendous at estimating time.
Marco:
And so, like, is it really any different to say, oh, that'll take two weeks?
Marco:
Or that'll take, you know, 30 man hours?
Marco:
And
Marco:
Are any of them even accurate?
Casey:
It's not really estimating time as much as it is estimating difficulty.
Casey:
And that's the key difference.
Casey:
And if I were you, I'd be kind of sucking air through my teeth and being like, is there really a difference there?
Casey:
But there is.
Casey:
Because you're saying relative to other things, this is either a little bit more difficult or a whole lot more difficult.
Casey:
And so a one-point story, we all agree as a team, including QA, including everyone, we all agree as a team this is not very hard.
Casey:
Whereas an eight point story and usually use the Fibonacci sequence.
Casey:
So it's what is it?
Casey:
One, two, three, five, eight, something like that.
Casey:
You know, this eight point story is many orders of magnitude more difficult than that than that other one point story.
Casey:
And so it's less about estimating time.
Casey:
then it is difficulty.
Casey:
And the theory is you take time out of the equation.
Casey:
And that's what that velocity is all about.
Casey:
Because over a couple of sprints, you realize, okay, we bid off 40 points worth of work, but holy crap, we only did 20.
Casey:
So realistically, we shouldn't sign up for 40 points anymore sprints.
Casey:
We should sign up for 20.
Casey:
And over time, things become a lot more predictable.
Casey:
And the other thing that you said, which makes perfect sense...
Casey:
but I think I'm doing a pretty crummy job explaining Scrum and Agile, is that, oh, it's all about giving managers something to do.
Casey:
Well, not all about, but in part about giving managers something to do.
Casey:
And in fact, it actually, to some degree, neuters the traditional project manager in that you're no longer beholden to a Gantt chart, which is possibly the most evil thing ever created.
Casey:
And instead...
Casey:
The whole idea of Scrum and Agile is the team is the one in power.
Casey:
And if there is a project manager, their job in life is, and to be honest, it is what I think it should be, which is to get obstacles out of the way.
Casey:
And the best project managers I've ever, ever, ever worked with do two things.
Casey:
Well, three things, actually.
Casey:
Number one, they get obstacles out of the way.
Casey:
Number two, they advocate on behalf of the client to our team.
Casey:
So they are the client's representative whenever the client isn't around and sometimes even when the client is around.
Casey:
And number three, they advocate on behalf of us to the client.
Casey:
So if the client is like, dude, you guys got to be able to do more than 20 points in the sprint, really?
Casey:
I mean, come on.
Casey:
This stuff isn't that hard.
Casey:
It's a project manager's job to kind of step in and say, well, no, whether or not you think it's difficult.
Casey:
The fact of the matter is history shows us, data shows us that we can only do 20 points a sprint.
Casey:
So this is the way it's going to have to be.
Casey:
And to think anything else would just be impractical and irresponsible.
Casey:
Does that make any sense at all?
Marco:
It totally does, but what bothers me about systems like this is I look at this and I say, well, why do you have to call them points?
Marco:
Why does it have to be this concept of this currency?
Marco:
Why does this have to be another level of indirection or an abstraction above what it really is, which is people working man hours?
Marco:
It's...
Marco:
This, to me, sounds a lot like the culture of Java, which has infected PHP as well, of making tons and tons of deep class hierarchies and classes on top of classes, inheriting from classes and factories and abstract factories and all this crap.
Marco:
And when you're really trying to do something that's a lot simpler than that, it doesn't need all of that.
Marco:
And so when I look at some of these things, it's easy for me to...
Marco:
to get turned off by it.
Marco:
And honestly, there's probably tons of value here that I'm not seeing because I'm an idiot in this regard.
Marco:
I've never, I'm completely inexperienced in following any kind of formal methodology.
Marco:
In all of my programming jobs, even when I work with other people, we never followed any methodologies closely.
Marco:
We would, you know, we would kind of like what John said earlier, we'd like borrow occasional things and like, oh, we'll try a few weeks with this or try a couple of months with this and it would never stick.
Marco:
So I don't know what I'm talking about in this area.
Marco:
So keep that in mind.
Marco:
I mean, normally I don't know what I'm talking about with a lot of things, but this time I'm actually admitting it, so that should mean something.
Casey:
No, but your questions are completely reasonable.
Casey:
And so to answer one of them, you know, why points?
Casey:
Why that level of indirection?
Casey:
Why not just speak in hours?
Casey:
And it's because of exactly what you said, which is that developers are unbelievably, indescribably bad at coming up with accurate estimates.
Casey:
And so the whole idea of points is, like I was saying earlier, it's an order of magnitude of difficulty.
Casey:
And you can kind of construe how many hours a point will be after a few sprints when you say, okay, well, sprint is two weeks.
Casey:
Casey has done 10 points worth of work every two weeks, so that's about five points a week.
Casey:
So, you know, you can extrapolate that out to figure out what hours is.
Casey:
But the idea is to take away any sort of measure of time and just argue about difficulty and track difficulty so that time kind of falls out of that equation.
Casey:
I'm not sure I'm doing a great job describing it.
John:
I think there's a lot of reasons why this agile methodology is BS.
John:
And I think I have my own cynical take on, on, on agile and other methods as well.
John:
But I wanted to get to a link that someone put into the chat room, whose name I will get this time because I froze my scroll back.
John:
Wandermat put in a link, the thing that I wanted to mention, which is, um, maybe, I don't know if any of you use this, uh, fog Creek software, Joel Spolsky's company, uh, introduced this thing as part of, I forget which product is part of, uh, I guess I could click the link to find out, but, uh,
Marco:
Yeah, the evidence-based scheduling, it was fog bugs a while ago.
Marco:
I think it was version 5 or something.
Marco:
It was a while ago.
John:
Yeah.
John:
And it's a similar take on this, but it's even more kind of data-driven in that on an individual developer basis, they ask that individual developer to estimate how long simple it will take.
John:
And basically, each individual developer gets sort of a reputation within the system of how good they are about estimating how long things are going to take for them to do.
John:
And if there's an easy weakness to pick out of an Agile system that uses points in the way Casey described...
John:
It's that programmers aren't interchangeable parts, and your crappiness at estimating the difficulty of a task during one sprint probably has very little bearing on your crappiness of estimating difficulty of an entirely other task on another sprint.
John:
So you may think the entire team has a capacity of 20 points, when really, person A has a capacity of...
John:
50 points on his own if he's doing a feature that involves, like, OCR.
John:
But if he's doing a feature that involves pull-down menus, his point capacity is much lower.
John:
But he's able to estimate both of them really well, so you think you'll be able to, oh, we should be able to, you know, figure out exactly how many points we have, but the points vary wildly.
John:
Being able to estimate the difficulty, who you estimate it for, difficulty for the team, difficulty for you, who it's assigned to has such a big difference.
John:
That's why a lot of these things fall down.
John:
And evidence-based scheduling is trying to see what can we do to take the human element out of the equation and say, let everybody lie, let everybody be crappy.
Yeah.
John:
But even then, you don't have like, OK, they were crappy about estimating for this type of thing.
John:
But what about that type of thing?
John:
Maybe they're better at estimating that.
John:
And you're hoping it's going to home in on some kind of average.
John:
But I get the feeling that unless you find yourself doing the same kind of task over and over again, which would be super boring and most good programmers don't want to do, it'll be difficult to get something really predictable out of that system.
Casey:
All right.
Casey:
So, Marco, do you want to tell us about something else that's really excellent?
Casey:
And then, John, I'd like you to pick apart all of the arguments I just posited.
Marco:
Sure thing.
Marco:
We are also sponsored this week by our friends at Ting once again.
Marco:
Ting is mobile that makes sense.
Marco:
They're a no-BS, simple-to-use mobile service provider from the people at Two Cows, the company behind Hover.
Marco:
Go to our special URL, atp.ting.com, to learn more.
Marco:
They have great rates, and there's no contracts and no early termination fees.
Marco:
You own your device outright, and then they have a pay-for-what-you-use pricing model.
Marco:
So here's what you do.
Marco:
You pay a base price of $6 per month per device, and then whatever you use on top of that in minutes, texts, and data...
Marco:
they will just bill you whatever cheapest bucket they have that fits that number.
Marco:
So, for instance, if you use 100 megs of data this month and a gig next month, and then the next month after that, you drop down back to 200 megs, each month you'll pay a different price.
Marco:
Just whatever you used, you'll pay for that.
Marco:
So you don't need to guess what you'll need in advance.
Marco:
You don't need to raise your data cap before you go on a big trip and then lower it when you get back.
Marco:
And, of course, you'll forget until then you have two more months of paying the high rate that you didn't even use.
Marco:
Okay.
Marco:
You just pay for what you use.
Marco:
They bill you for the cheapest bucket that you fit in, and that's it.
Marco:
They even have new lower prices.
Marco:
If you checked them out in the past, check them out again because they even just lowered their rates.
Marco:
So, for instance, 2 gigs of data is just $29.
Marco:
500 megs data is just $12.
Marco:
So to see how much you can save with Ting, go to atp.ting.com and check out the Savings Calculator.
Marco:
You can enter in your last few bills of whatever your actual usage was from your existing phone carrier, and it'll show you how much Ting will save you on average and then over time.
Marco:
And if you're stuck in a contract with someone else,
Marco:
And suppose you have to pay an early termination fee to get yourself to Ting.
Marco:
They will actually give you 25% of it back in service credit up to $75.
Marco:
So like Hover, Ting has great customer support.
Marco:
There's a no-hold, no-wait phone number.
Marco:
You call them up.
Marco:
Anytime during the business day and a human being picks up the phone who is right there and ready to help you.
Marco:
It's really a great system, great customer support.
Marco:
And we can think of various ways you can use it.
Marco:
You can look at if you're a developer, you want some test devices that you want to be activated on cell networks, but you don't want to pay a lot of money.
Marco:
Or if you're just a regular user and you're tired of paying a really high phone bill for a lot of capabilities you're not really using.
Marco:
Check out Ting.
Marco:
Go to atp.ting.com.
Marco:
They're compatible with any Sprint phone because they're a Sprint MVNO here in the U.S.
Marco:
And if you have a Sprint phone, bring it over.
Marco:
If it's compatible, go to their site to see the list.
Marco:
They also will sell you a new or used phone for pretty great prices.
Marco:
So check it out, atp.ting.com.
Marco:
Thanks a lot for sponsoring the show once again.
John:
They should have a song with beeps and boops with a name like Ting.
John:
Or just bells.
Casey:
That's true.
Casey:
Two on the nose.
Casey:
Oh, goodness.
Casey:
All right, so really quickly before John destroys all of the points I just made, a friend of the show, David Smith, said earlier in the chat, and I'm quoting, Scrum slash Agile's purpose is to attempt to try and extract consistent or predictable performance out of an uncontrollable situation.
Casey:
It is better than nothing, but it is no replacement for talented, motivated developers who can get things done in any environment.
Casey:
Methodologies help reduce the impact of individual talents on the overall outcome.
Casey:
And I think that that really makes a lot of sense, and I completely agree with that.
Casey:
But with that said, John, tear me apart.
John:
It's not you.
John:
It's like the overall concept of having a particular method by which you develop software.
John:
Like, the reason Marco has a sort of visceral reaction against it, and I think most programmers do when they're in that type of environment, is that if you've spent any time programming, whether on your own or even just in a small group, even with just one or two other people, especially in small groups where you kind of, like, get a feel for, like, this is what it's like to make software.
John:
This is, you know, this is what the experience is like.
John:
You learn that... You learn kind of...
John:
What works and what doesn't in terms of getting the job done, independent of any schedules and stuff like that.
John:
And what works is having a bunch of talented people who are motivated and excited about the thing that they're doing.
John:
Right.
John:
And so all these methodologies in some respects are.
John:
attempts usually good-hearted and sometimes vaguely effective attempts to take for example mediocre programmers and make them into great programmers or to take great programmers who don't care about something and make them care about it everyone wants like what we want is what happens when you get a bunch of talented people working on the same product uh who are good at their jobs who are excited about what they're going to do and
John:
large companies say well we can't do that because we're too big and people aren't excited about our stuff and it's hard to get that many people who are talented or even if you could get that many people who are talented they don't get along with each other in big enough groups so we need some sort of method to arrange all this so that we so that we get some sort of somewhat predictable performance out about what we've got what we've got is maybe we've got really talented people we've got not so talented people maybe we've got people who are excited and people who aren't excited maybe we've got people disagree about how things are going to go and we have a whole bunch of people
John:
telling them what to do so they don't even get to decide which direction the product goes in and they have we want them to do that in a consistent manner and so if you're in this environment you're like you start to feel if you just left us alone and got rid of dave who stinks like then we would get this thing done but instead we have to go through these stupid steps of this methodology and these user stories and these meetings and these points and going through all this stuff and you're just like look i'm a software developer i know what it takes to get good software and
John:
It just put me in charge of the world, and I'll tell everyone exactly what to do, and just me and my three friends.
John:
Everyone wants to get back to that thing where it's just you and a couple of friends in a room working on your program, which is how lots of great software is made.
John:
And all this methodology stuff seems like it's pointless busy work that doesn't actually make anything better.
John:
And I think a lot of the times it is pointless busy work that doesn't make anything better.
John:
And the only thing that it makes better is that, as people pointed out in the chat room, people higher up in the org chart can point to, well, we've been following this methodology.
John:
Yeah.
John:
And it has predictable results and look at our things to say we have we know how many points in our velocity and blah, blah.
John:
It's all kind of like covering your ass that so you're not going to get fired because, well, we have a methodology and this is what we do.
John:
But in effect, everyone in that organization might feel like the stupid methodology is making us less efficient, less happy, making us do worse work than we would if we just, again, fired Dave because he stinks and let the three of us go off it.
John:
three of us go off for a weekend and we'll solve your freaking like that's how programmers feel like the cowboy coding like stand aside i know exactly what i'm going to do like that's the tension between the sort of feeling that any experienced programmer has that if you just let us do what we need to do we could get it done uh you know and the reality that in if you if you're on a large project you can't do that this is where this tension is and some people are trying to apply a methodology to to make order out of this chaos and and the people who are contributing to the chaos always feel like
John:
Anything you impose on me is making things worse and they get grumpy about it.
John:
And some people will get religion and say, I'm going to really get into this process and I like it and it's predictable.
John:
But like, bottom line is, no large organization is ever going to achieve the ideal of a handful of talented, like minded people communicating well.
John:
And even like in that article they put in the show notes link of why software methodologies don't work, even if the idea is like, oh, we'll just focus on communication and make sure we have personalities put together like those solutions are not scalable to organizations of hundreds of people like no, no way for people to do a job together.
John:
And, you know, at peak performance is scalable to hundreds of people because inevitably there's going to be personality conflicts, there's going to be disagreements.
John:
And that's why you inevitably have to fall back to some kind of methods.
John:
Now, for things that are regularized, which has been pointed out a million times, like building a road or building bridges or things people have been doing for hundreds of years that are very simple, you know, pretty much success and failure wise, there needs to be a span over this course of water, needs to carry this much weight, it needs to withstand these conditions, it needs to last this long.
John:
We've done this 20 times before.
John:
We know exactly the steps that are required to take.
John:
Still, things can get screwed up, and we can try new methods they might mess up.
John:
But in general, it is way easier than even the simplest software product where no one has made this specific thing before with these specific requirements.
John:
People don't even know what the requirements are, and they're going to change a million times.
John:
Software is so much more complicated than pretty much anything else humans do except maybe parenting that it's impossible to predict what's required to go into it.
John:
And so we're willing to accept essentially a massive reduction in peak performance just for some grasp on, like, can we get some predictability out of this?
John:
Even if it means that we're working slower.
John:
And once you get to a certain size in a public company, you're like...
John:
I don't care how much crappier it makes us.
John:
As long as we're still able to stay in business, I want everyone to follow whatever methodology, A, B, C, and D, or whatever processes.
John:
Even if I know that this is going to send the best programmers out of the company because they don't want to work for us anymore.
John:
And we're not going to get the peak performance that we would.
John:
It's just better than the unpredictable chaos.
John:
Because if you're not one of the programmers, but you're one of the people in charge, you could very quickly feel like nobody's in charge.
John:
Nobody's at the wheel.
John:
You're just up there and you just whisper down to the programmers and say, well, hey guys, you think you could make...
John:
a program do this and and then you just wait to hear a reply with your fingers crossed like that's not a way to run an organization so these rules always have to apply but they're always going to feel like they're making things work and and in many respects they're they're wishful thinking that you are going to somehow come up with the correct process to turn this huge team of people into the equivalent of 17 rooms full of five people who are really motivated
Casey:
The funny thing about everything you're saying is, and this was pointed out to me on Twitter by Chris H., and he's right, is that the origin of Agile was to try to get away from oversight by management.
Casey:
And so the whole idea of Scrum and Agile is that you self-manage as a team.
Casey:
The team is self-governing.
Casey:
You establish the team norms up front.
Casey:
We're always going to be on time to meetings, which never actually happens.
Casey:
We're always going to pay attention during meetings, which never actually happens.
John:
You're trying to get everyone to get along and agree, but you can't do that.
John:
That's not how human relations work.
John:
If we just all agree that we'll be friendly and motivated and work well together, then we will.
John:
It's not how it works.
John:
It's like coming from the outside and saying, it would be nice if the interaction with our groups were this way.
John:
And then if you just say that to each other, that doesn't make it so.
John:
If these two people still hate each other, they're always going to hate each other.
John:
These two people disagree strongly about this technical issue.
John:
Telling them that they shouldn't disagree is not going to work.
John:
Yeah.
John:
It's just kind of like shifting the things around on the table.
John:
Like, OK, well, we don't want people who aren't programmers telling us.
John:
So I'm sure if we just let all the programmers sort it out, they'll do fine.
John:
No, you just move those those dynamics to a different group of people, a different, even more passive aggressive group of people.
Casey:
So I take it, John, that you've never been in a situation wherein you feel like the method improved the product.
John:
processes sometimes improve the product and like i said for large organizations you have to have processes and you have to have methods because if you don't it's just wildly unpredictable and it's depending especially with your mix of people like the chestnut that you always heard is like if you have a bunch of great programmers then you can just let them do whatever the hell they want and you'll be awesomely successful if you have a bunch of mediocre programmers you need to apply you know processes and methodology and if you have a bunch of crappy programmers you need massive methodology application to them uh
John:
And then in the end of it, all of those situations, you end up with a product of similar quality, which I don't know if I believe that.
John:
And I don't know which one of those things is better.
John:
But most most companies are a mix of those type of things.
John:
And it's just there.
John:
I don't think there's any avoiding with something as complicated and unpredictable software.
John:
I don't think there's any avoiding that dynamic that.
John:
Small groups of focused, really smart people can do great things in short periods of times.
John:
Things that larger groups of less motivated, less experienced, less talented people can never do.
John:
It's not like, okay, well, it takes these five people in a room a year to do this, but if I had 300 people in three years, I could equal them.
John:
No, you may never equal them with 300 people if you don't have the right five, for example.
John:
It's because it's not a predictable thing, because it's not something you can systematize.
John:
Someone in the chat room was saying, oh, come on, there's plenty of things that are more complex than software.
John:
Plenty of natural things, not plenty of man-made things.
John:
I would say a 747, I mean, the consequences for errors in a 747 are much greater, but software is much more complicated.
John:
The consequences are usually stupid and pointless and nobody cares, which is why we get away with this.
John:
But software is insanely complex in terms of
John:
you know what what number of states can can this thing be in and how how many transitions from one state to another can it go through like i mean think of the freaking halting problem we can't even reason it you know make basic reasons about arbitrary programs that you're going to consider it programming is is different by nature than most things that people do it just so happens that the consequences are usually not that serious and that's when you see programming where there is real consequences like you know missile control systems or things in planes hopefully
John:
they have massive process applied on them.
John:
Like they're willing to sacrifice productivity and, you know, job satisfaction and not have the smartest people to say, look, we have crazy requirements about how everything must be done to the most conservative fashion possible.
John:
And it's like some people look at it and say it's a miserable existence, but like that's our only tool to say we would like to make a program, but we would also like it not to fail like ever.
John:
And so we are going to apply the methodology nuclear bomb or nuclear, if you want to pronounce it correctly,
John:
to this to this problem and we are going to make it miserable for like no one would sign up for this like you can't use these features you're not allowed to ever allocate memory we have the system system for doing like i mean for the space program and stuff like that that's our only tool like method that's what our tool is for for trying to make it so that you know we can minimize bugs and make it reliable but it destroys productivity you can't use that same methodology that you use for like the mars rover software you can't use that to make like whatsapp
John:
Like you'll be out of business.
John:
It's not, you know, you can't, you can't even use it to make iOS for crying out loud.
John:
Like you, they would never produce a product, you know, like how many years and they would never get the people who wanted to work on it.
John:
So it's, that's how I think that's the place of methodology.
John:
Like it's,
John:
it's an evil that is necessary to the degree to which you you demand a predictability of your software and even then you have things going out of orbit because of unit conversion errors and this bug you know like we're never perfect right so i i feel for the people who want methodologies to make things better but i mostly see it as like the only tool we have to try to fight against the inherent chaos of writing software
Casey:
And as per usual, I think you've hit the nail on the head.
Casey:
And coincidentally, I was about to bring up that there are instances where Waterfall, which among software developers is considered to be evil in almost all cases, there are instances where Waterfall is absolutely the correct answer.
Casey:
And in fact, as I kind of hinted at during the debug that I was on with Guy and Rene.
Casey:
Nice plug.
Casey:
I do what I can.
Casey:
It was pretty good, actually.
Casey:
I haven't like halfway through it, though.
Casey:
oh thank you um so yeah so when i was working on on some stuff for where failure was not an option we had pretty much everything that was waterfall a lot of planning up front a lot of meetings up front code reviews and all of these things and that was in order to prevent exactly what you described john you know it was to prevent a poor poor unit conversion or something along those lines
Casey:
And in that situation, it was absolutely necessary.
Casey:
It was absolutely necessary, absolutely the right answer, and absolutely the right way to get that project done.
Casey:
The problem was is that as a developer, especially one who tends to want to sling code and rather than talk about slinging code, it was incredibly neutering to me.
Casey:
Is that a word?
Casey:
It doesn't matter.
Casey:
Anyway, it made...
Casey:
It made me feel like I could never get anything done because I just had to talk about getting things done.
Casey:
And that was very frustrating.
Casey:
But I don't begrudge my then employer for doing things that way.
Casey:
It was absolutely the right call.
Casey:
It's just it wasn't the right call for me.
John:
waterfall is like almost impossible with anything that's reasonably complex because nobody knows what the correct design for it is no matter how much you talk about it like you could you could talk for three years to come up with the design and once you start implementing it on a third day you're gonna go oh
John:
we didn't think of that because like because the running program is too complicated for everyone to keep in their head and like what happens at that point is do you bravely plow forward with the waterfall design do you you know go back to the drawing board and start it all over again or do you just make some little tweak and then like you end up with this thing that's kind of misshapen it's like putting together a piece of furniture and one piece of wood is like bent so it barely fits like hey they followed the plan right and slot a into tab b uh yeah and
Casey:
Yeah.
Casey:
And coincidentally, Marco, to bring him back into the conversation, has dealt with a lot of that lately.
Casey:
Not as much waterfall stuff, but you've dealt with the reality and realization that, you know what, maybe I need to throw away a lot of work I've done and do it all over again.
Marco:
Oh, yeah.
Marco:
I mentioned in the after show about four episodes ago.
Marco:
I can tell you because it was about a month ago.
Marco:
I think I even cut it out of the final edit, but the live listeners probably heard me...
Marco:
a month ago, say that I was rewriting the Overcast sync engine because I discovered some sync shortcomings and I was rewriting the engine to be much better and everything else.
Marco:
And at the same time, I was doing... And of course, in hindsight, I can see why this is a bad idea.
Marco:
While rewriting the sync engine and the whole protocol with which it synced to the server, I also took the opportunity to break up the data model
Marco:
for the two key models of the app, which is podcast and episodes.
Marco:
I broke off parts of those that were the user parts of them into separate models.
Marco:
And this required such massive changes to the code on both sides, server and client.
Marco:
At the same time, I was also changing the sync protocol and trying to make it generic so I could use the one master superclass slash library functions to sync anything.
Marco:
And...
Marco:
And the result was I lost a month, basically.
Marco:
And last night I decided, you know, as I was staring there with the parts of my app on the floor still, and as I was trying to...
Marco:
rework the changes, you know, still back into the app.
Marco:
And I realized I was throwing away so much working behavior and so much like nuanced, complicated stuff, especially on the iOS app that depended on the old model.
Marco:
Meanwhile, this whole time on my carry iPhone, my main iPhone, I was using the old version of the app from a month ago because this whole time I couldn't put a new build on yet because it was broken.
And
Marco:
And for the whole month, it's been fine.
Marco:
It's been working great.
Marco:
And I've been sitting here using this build for this supposedly unshippable alpha software.
Marco:
I've been using the same build for a month every day heavily, and it's been perfectly fine.
Marco:
And I realized, you know what?
Marco:
Now that I'm like two-thirds of the way into this massive sync change, I realize now that even if I get it all back together, it's going to be too complicated, too fragile, and not at all maintainable.
Marco:
And so even if I finish this, the result will be worse than what I had before.
Marco:
I was wrong when I thought it would be better.
Marco:
In practice, it's not better.
Marco:
So therefore, I decided...
Marco:
to go back to what I had and I spent today basically reverting back to the old version from a month ago and merging in a few, basically cherry picking by hand a few of the improvements I made that will fit in the old system just fine.
Marco:
And so I've lost, I wasn't doing this the whole month, I was doing some stuff I could keep, but I would say I probably threw away two and a half weeks of work because the result is actually better the old way.
John:
I think you're only on step one of four of the Brent Simmons syncing development.
John:
Because I think at this point now you have to also throw away this one again and try the other one.
John:
And then you have to revert back again to the previous.
John:
If you're following the Brent Simmons Vesper Sync Diary plan of syncing software development, you've got a long road ahead of you.
Casey:
And to be fair, you know, to bring this very briefly back to methodologies, no methodology would have fixed that in my estimation.
Marco:
They might have made it take longer.
Casey:
Yeah, you're absolutely right.
John:
Like agile would have or would have forced you to ship something you didn't want to ship because, you know, in in areas where there are constraints.
John:
Yeah, like that's that's what I was getting at.
John:
It's like that a lot of times methodologies are seen as the way to solve your problem when your problem really might be your one software you have working on a sync system has not written a sync system before.
John:
There's no methodology that's going to make that go faster, make it come out better.
John:
There are lots of practices that you can adopt.
John:
It's not like saying, oh, it should just be the Wild West.
John:
For example, there's practices that should be imposed on people that I think everyone would agree on.
John:
I don't pick the language you're trying to like JavaScript with the stupid use strict token or whatever.
John:
If you decide that's a reasonable thing to do, and I think it is, and it doesn't affect your compatibility to say everybody's got to put the JavaScript, the use script.
John:
Deciding on your compiler flags, having some sort of common naming convention and indenting style, like all the easy things that people can agree on.
John:
That stuff counts, and it helps everybody.
John:
But people say, all right, that's good.
John:
Coming up with agreement on these standards helps.
John:
If we come up with agreement on even bigger, more sweeping changes, surely we'll get a proportional benefit.
John:
And you don't.
John:
That's where we should start talking about testing, I think, is that testing is definitely something you really need and is great.
John:
And testing taken to its logical conclusion and test-driven development is...
John:
is certainly better than having no tests at all, but you can't just keep cranking that dial until it's like now just everything will be perfect all the time because if a little bit of testing helps and a little bit more testing is great, then if we have 100% code coverage and everything testing, we've solved the problem of software development and you haven't.
Casey:
And unit testing is something that I think is a little bit – I don't know if taboo is the word I'm looking for, but not a lot of developers that I know are really into it.
Casey:
And I would argue that test-driven development is taking it a bit too far in my personal opinion.
Casey:
But –
Casey:
But writing comprehensive unit tests is the same sort of thing as code reviews, where at first I was like, oh, God, really?
Casey:
This is a thing we have to do?
Casey:
Everyone has to look at my code and try to tell me why it's wrong, and they don't realize that I'm actually right.
Casey:
Now I've got to convince all these people.
Casey:
But in the end, it actually worked.
Casey:
Code reviews were extremely, extremely bad.
Casey:
And I always learn something from it, even if I never change my code.
Casey:
And most times I did change my code.
Casey:
Unit testing is a similar thing where it's like, oh, God, do I really need to write unit tests for all these things?
Casey:
I run it a few times.
Casey:
I give it a few example inputs, and that should be enough, right?
Casey:
But unit testing is an unbelievably...
Casey:
awesome way to make sure that not only that what you've written works, but also that it will stay working.
Casey:
And that's what's extremely powerful about it.
Casey:
And you can take it to the nth degree, which is test-driven development, or you can use it where appropriate.
Casey:
And one of the things that I need to explore more in Objective-C is looking at Xcode's unit testing framework, because I never really played with it.
Casey:
But there's great frameworks in Java, in .NET, and
Casey:
Like NUnit, for example, and actually Microsoft has their own copied version of that.
Casey:
Of course they do.
Casey:
Of course they do.
Casey:
That allow you to do those sorts of things.
Casey:
And I agree with you, John, that having these unit tests is a really valuable thing.
John:
every methodology has something about it that you can take away from it that's good like waterfall has some good things about it as in like let's think about what we're doing before we type agile has some good things about it like you know let's take smaller steps because if you if you don't know that if if you describe something as one big giant step you have no idea what's involved in it if you break it into smaller steps
John:
then you have an... That's from the Gantt charts as well, but also you get that experience in Agile.
John:
Test-driven development, a lot of developers left to their own devices won't do tests, so if you try to indoctrinate them into this crazy cult of test-driven development, then they'll learn to write tests.
John:
And I think test-driven development is actually not that far off from something that everybody should do.
John:
It's just that it's so far off from what people would do on their own that it seems crazy at first.
John:
And I'm a big proponent of massive amounts of testing.
John:
What you run into eventually...
John:
with test-driven development or any kind of testing thing is that tests are also code.
John:
Like, it's not like another infallible person comes and writes the tests, right?
John:
And it doesn't mean you shouldn't write tests.
John:
That doesn't invalidate tests, but, like, that's the limit that you hit.
John:
The limit that you hit at a certain point is that...
John:
you're you know tests are code you're not infallible when you write them either and the more of them you write the more difficult changes become both in good and bad ways and like so every one of these things if taken too far uh can have problems and that's what again what we're looking for is like oh just if we've got those two or three guys who really kind of know what they're doing and have have experience with each of the things they're going to be doing and have done something like this before and can kind of get the balance and just you know
John:
firing on all cylinders and the project is small to fit it all in all their heads collectively and then you know they're super geniuses and they make this great 1.0 product with this great potential feature and they hand it off to another group like we're all trying to go to get to recapture that it's like it's like trying to recapture your youth like you're never going to get there again right
John:
You're never going to be like you were when you were 16 years old.
John:
It's like, if we could just apply this series of constraints.
John:
But there's wisdom in every experience that you've had that you want to apply.
John:
And in some respects, it doesn't matter if you're in an organization that's like, you know, whoever's in charge of things says agile is the way we go.
John:
Whoever's in charge of things says we got to do test driven or we have to do pair program.
John:
We have to review.
John:
It's like someone's leaning heavily on whatever button or dial or accelerator they think is the best thing.
John:
In the end, what matters is like the people in the group
John:
uh the dynamics between the people their motivation for what it is they're doing and and their skills and experience have they done something like this before and almost any methodology that you apply to them will appear to work because they would have been fine in any situation and those same people
John:
would choose to write tests because they know it's good.
John:
There's no methodology that omits tests entirely because that's insane.
John:
There's no methodology that omits any planning up front because we hate waterfall.
John:
There's always something, some piece of every one of them.
John:
no matter what methodology you apply to a bunch of good people they will pull that pull the parts from each one of them when the problems only come in when it's like you know i mean how long ago was like no silver bullet written and you know the fred brooks stuff like that's that's so long ago like we've known this for so long it's just people keep reaching for that for that brass ring and saying this time i've got it and every time it's like you don't have it but you've discovered something new that maybe we can take away from what you're preaching and move forward
Casey:
So in summary, you know, methodologies can help, but really they're not going to fix anything.
Casey:
And it's all a bunch of hocus pocus.
John:
With that said, we should suggest, we should, oh, you want to know the sponsor?
John:
I was going to say that both of us should convince Marco to write way more tests than he's currently writing.
Casey:
Which is to say more than zero?
John:
I don't know what that number is.
John:
I wasn't going to say, I'm just saying.
Casey:
Which is to say more than zero?
John:
Yes, I would suggest that.
Casey:
I would too.
Casey:
I really would.
Casey:
But anyway, Marco, what else is really cool these days?
Marco:
It is once again our friends at Squarespace.
Marco:
Squarespace is the all-in-one platform that makes it fast and easy to create your own professional website or online portfolio.
Marco:
For a free trial and 10% off, go to squarespace.com and use offer code.
Marco:
Now you guys know it's a new month.
Marco:
January was Marco.
Marco:
February was Casey.
Marco:
March, offer code for Squarespace is critical.
John:
Nice.
John:
Everyone else gets a name.
John:
I just get a truncated version of my old podcast.
John:
All right.
John:
Well, I guess people can spell it better than my name, I hope.
John:
Well, maybe critical is your identity.
Casey:
I was going to say that's so critical of you right then and there.
John:
I guess hypercritical.
John:
It was too long to fit in the database column they store the coupon codes in.
Marco:
And maybe they throw a warning and it blows up their whole app.
Marco:
Squarespace is constantly improving their platform with new features, new designs, and even better support.
Marco:
They have beautiful designs for you to start with and all the style options you need to create a unique website for you or your business.
Marco:
They have over 20 highly customizable templates for you to choose from, and these templates have won numerous design awards from prestigious institutions.
Marco:
Now, Squarespace is very easy to use, but if you need any help, they have an amazing support team of over 70 people in New York City that works 24 hours a day, 7 days a week.
Marco:
And even they have won numerous awards.
Marco:
So Squarespace starts at just $8 a month.
Marco:
Now, they have this cool feature called Squarespace Commerce, where you can build an online store that sells physical or digital goods.
Marco:
It's this whole storefront capability built into Squarespace.
Marco:
So it looks like your site.
Marco:
You can theme it.
Marco:
You can customize it.
Marco:
And you don't have to build the shopping car, the tracker for all the inventory and all that crap.
Marco:
They do all of that for you.
Marco:
Building a store is a lot of work.
Marco:
They do it all for you.
Marco:
And Squarespace Commerce is included in every Squarespace plan.
Marco:
So if you want to use it, great.
Marco:
No additional charge.
Marco:
If not, you just want to make a site, a portfolio, whatever the case may be, you can do that too.
Marco:
All this starts at just $8 a month.
Marco:
You get a free domain name with that purchase if you sign up for a year up front.
Marco:
You can start a free trial today.
Marco:
No credit card required for that free trial.
Marco:
It's a real free trial.
Marco:
You don't have to give them a credit card and hope that you remember.
Marco:
Otherwise, you'll get charged.
Marco:
Nothing like that.
Marco:
Real free trial at Squarespace.
Marco:
Go to squarespace.com and use offer code CRITICAL.
Marco:
to learn more, and to start building your site today.
Marco:
Now, one more thing.
Marco:
If you hurry up, they are interviewing designers and engineers because they want to hire 30 designers and engineers before March 15th.
Marco:
Now, right now, this episode is going to be released on March 6th, so hurry up, basically.
Marco:
But if you interview for an engineering or design position before March 15th,
Marco:
They will invite you and your partner to be New Yorkers for the weekend.
Marco:
They will fly you out, put you up at one of the city's best hotels, and give you a long weekend of being a New Yorker, going to restaurants, attractions, etc.
Marco:
And they will pick up the whole tab for it.
Marco:
They've been voted one of New York City's greatest places to work for two years running, so put them on your shortlist.
Marco:
They're looking to hire, again, 30 engineers and designers by March 15th, so hurry up.
Marco:
Go to beapartofit.squarespace.com to learn more and apply.
Marco:
So thanks a lot to Squarespace once again.
Marco:
Remember, squarespace.com, offer code CRITICAL.
John:
If you've been hearing Squarespace ads on podcasts for months but not going to the site to sign up, now's the time to do it with my code to show the other two.
John:
i wonder if i can get them to tell me like you know in a couple of months tell me which of our codes won yeah which of yeah and it's too late for you two so now everybody pile on my code so when marco gets this information that will be the overwhelming winner well i don't think our codes stop working i'm pretty sure the codes still work it just you know the i don't know that that would be bad because then like you whoever had the first code would have the accumulation of you know they had months of of uh of users signing up anyway everyone use my code
Marco:
So, Casey, after all this time, was the methodology talk on this show everything you hoped it would be?
Casey:
No, actually, it really wasn't as exciting as I thought.
Marco:
You think it's over, though?
John:
Are we done?
John:
Are we?
John:
I don't know.
John:
We don't have to be.
Casey:
We don't have to be.
Casey:
I don't really have that much more to say, to be honest, after all that.
John:
Well, I have a question for each one of you.
John:
I mean, we are going to have nine episodes of follow-up.
John:
Maybe Marco can abstain.
John:
But, like, which – what methodology or part of a methodology have you found to be –
John:
make the biggest improvement in how you feel about coding or how you write code.
Casey:
So Marco, do you have an answer for that?
John:
It doesn't have to be like a formal one, just anything you've done, you know.
Marco:
Honestly, what has improved my code the most by far has been open sourcing it.
Marco:
And not necessarily because of the contributions I get, which are good, but I don't get a whole lot of them.
Marco:
It's mostly that if I know I'm going to be open sourcing it, I hold myself to a higher standard and I kind of reconsider my decisions more.
Marco:
And so by editing myself more and by...
Marco:
by pushing myself to a higher level of discipline for these very important modules that I'm open sourcing, that has helped me dramatically.
Marco:
And, you know, as an independent developer, there's, you know, I don't really have code review.
Marco:
I don't have pair programming.
Marco:
You know, there's a lot of methodology type stuff that I just can't do as one person.
Marco:
And a lot of the stuff I could do, like having tons of tests, I could do a lot of that stuff, but...
Marco:
it would take so much of my time and it would slow me down so much that it might not be worthwhile or practical for me to do that.
Marco:
And so I don't do a whole lot of the other stuff, but certainly, yeah, open sourcing by far, that's helped me more than anything.
Casey:
So for me, I would say that I think scrum, which is to say the thing where you get together either physically or on the phone for five to 15 minutes each day and talk about what you've done, what you're doing, and what stands in your way, that sounds wonderful in theory.
Casey:
And in practice, never works.
Yeah.
Casey:
even in in in my company where we take agile extremely seriously and of course all the people who think i'm wrong about everything are laughing right now but we do take agile very seriously and whether or not you think i'm i know what i'm talking about i assure you that they do and so they they take scrum very seriously and we have scrums every single day and even though we take all this stuff so seriously um
Casey:
Scrums never last the 15 minutes they're supposed to last, and they always go into tangents that they're not supposed to go in.
Casey:
And so Scrum has never helped.
Casey:
However, that one project where we had that perfect storm of willing and capable developers, willing and capable QA, willing and capable PM, and willing and capable product owner slash client,
Casey:
When all of us really went all in on Agile and really bought into it and really believed in it and really took it seriously, it was fantastic because it allowed for us to roll with the client's ever-changing requests, which to be fair, they were actually very good to us and didn't really change things that often.
Casey:
But when they did...
Casey:
The product owner, the client, would come to us and say, oh, I really want to do this thing.
Casey:
How many points is that?
Casey:
And we'll go and talk for a few minutes.
Casey:
Okay, it's eight points.
Casey:
Oh, man.
Casey:
All right, let me figure out what eight points I want to get rid of, and I'll get back to you.
Casey:
And we didn't have to argue with them.
Casey:
There was no scope creep.
Casey:
There was no, well, if you'd like this to happen, you're going to have to take some other stuff out.
Casey:
Well, how much other stuff?
Casey:
We don't know.
Casey:
You just have to take out other stuff.
Casey:
Well, I need none of that awkward conversation happened.
Casey:
They took it upon themselves to realize, well, you know what?
Casey:
You've told me that that's that this thing that I really want is eight points.
Casey:
And so I know that I need to take away eight points from what's currently on the docket.
Casey:
And, oh, my God, it was so wonderful.
Casey:
I mean that genuinely.
Casey:
It was so wonderful.
Casey:
And I think this is exacerbated by the fact that in consulting, you have this client versus – well, not versus necessarily, but you have your client and your own team.
Casey:
And sometimes that can be an adversarial relationship.
Casey:
But when we were all on the same page with Agile, it was so wonderful because we were truly, honestly partners in getting this project done, and it was great.
Casey:
And so to answer your question, John, the one time of the 10 or so years I've been working, the one time that Agile really, really, really, really stuck –
Casey:
It was incredible.
Casey:
But to be fair, I've tried Agile many, many other times, and it hasn't really worked out that well.
Casey:
And at best, it was a distraction, and at worst, it was a hindrance.
John:
Yeah, I would say for me, it's hard to pick because a lot of things like there's a lot of steps and things that I've done that have helped.
John:
I mean, I recognize Marco's thing with open sourcing stuff like me having a lot of my Kobe open source already in my career, though now it is super embarrassing.
John:
It's terrible.
John:
That really helps, you know, for all the reasons Marco cited, like you just feel the pressure to make it better.
John:
And especially when you're a young developer working on your own.
John:
like i was on just like you know random open source stuff uh you need some kind of external motivation because you don't have a boss telling you to do it maybe you don't have other experienced programmers uh trying to get you to do stuff but i think the thing that has made the biggest impact on me in terms of how i develop software was as i started to do more and more uh testing uh and not in any particular thing not particularly test driven not particularly even unit tests versus integration tests or his function tests but just the idea that testing uh
John:
is not like eating your vegetables.
John:
And I, I know I had turned a corner when I think it was like one or two jobs ago.
John:
At some point there was some fairly complicated project that they wanted, uh, with like, you know, just big, long description of how it's supposed to work written entirely by non-technical people.
John:
So of course they have no ideas about feasibility or anything like that.
John:
Uh,
John:
And they need it in a super short timeframe.
John:
And they're like, you know, this is super important.
John:
We know it's really complicated, but like, you know, we have all this meeting about it.
John:
Like what's it going to take to get this thing done?
John:
And my reaction to being put in that situation to be like, you know, the, the, the lead guy on this project was, uh,
John:
immediately to uh to revert to kind of like you know not test driven entirely but like to say i'm going to need a massive amount of tests more testing then my tests have to be great and they have to be awesome and i have to really concentrate on testing because that's the fastest way to get this thing done on time with the fewest bugs so on and so forth and the fact that that was my reaction shows that i had you know sort of learned through bitter experience that uh
John:
Testing is not like eating your vegetables.
John:
It's not like a luxury you can get that you can afford to do if you have the extra time or whatever, but rather when you're under the gun is when you really need to pull that out of your back pocket and not be religious about it and say, oh, I'm not going to take a step until I've got a failing test and all this other stuff.
John:
Not that crazy, but just like for me to feel confident that I can move at my fastest pace, I have to be sure that the code I'm writing is correct and the code that I've written remains correct during this entire development process.
John:
And I've never been under quite those same constraints before, but now like...
John:
That's an example of a turnaround methodology.
John:
I think people who do pair programming have the same feeling sometimes where it's like, I'm not going to do that all the time as the most extreme thing, but when push comes to shove, I know which dials I can turn on myself to get my best performance, and I will choose from those things.
John:
And I think testing is the one that...
John:
probably i don't even know how it probably came up because of the test driven development like you know hype and everything but i would not have thought of that on my own to be the thing that i should do when i was a young programmer but eventually came to have it as one of the tools in my toolbox and i leaned on heavily now and i try not to preach each other people but i say like it it should be something that you do from time to time to know how it affects your work
Casey:
Yeah, I agree.
Casey:
And it's funny because formal unit testing is something and also formal integration testing is something that I find often gets punted if you're running out of time or budget.
Casey:
Additionally, performance testing is another example of something that gets punted if you're running out of time or running out of budget.
Casey:
But all of those things are extraordinary.
Casey:
important to give a deliverable that you're really, truly proud of.
Casey:
And it's a hard thing, man, when somebody's looking at you, be it a project manager or a client, saying, oh, my goodness, you really, really, really need to get this thing shipped.
Casey:
And you say, no, my test classes aren't complete yet.
Casey:
There is not enough code coverage, so you need to leave me alone.
Casey:
It's a hard thing to sell, and it's a hard thing to say.
Casey:
But so often, if you don't get that right up front, you'll pay for it later.
Casey:
Same thing with performance testing.
Casey:
Oh, well, you know, we don't need to worry about that.
Casey:
We shouldn't have but five users at a time.
Casey:
And something weird happens.
Casey:
Next thing you know, you have 500 users at the same time, and your website comes to a screeching halt.
John:
Yeah, the key thing is to recognize when each tool is appropriate.
John:
So for the example that I cited, I was handed a big giant, you know, Word document.
John:
There are always Word documents.
John:
Of this complex system, not written as a programming spec by any means, but merely written as like, you know, a fantasy scenario.
John:
Wouldn't it be cool if, and what about this?
John:
And this would do this, and this would do that.
John:
Really complicated stuff.
John:
It involved tables or whatever.
John:
It was kind of like unintentional waterfall, where it was like a big idea of a complex system that
John:
That is just now in the kind of like blue skying stage, but that needs to be shipped, needs to be shipped this software in like a very short period of time, like less than a month.
John:
Right.
John:
And that's a case where you can say, look, if you agree, this is how this is, this needs to work and you think you've got it all down.
John:
It's the fastest way for me to do this is to lean heavily on testing because there are so many complicated scenarios that I need to run through.
John:
And it's not like I'm going to get a hundred percent coverage.
John:
It's not like I'm going to test every possible iteration of input.
John:
But at the very least, this document here describes many different situations and how they interact.
John:
And I can test every single one of those things.
John:
It's the only way I'm going to be able to ratchet my way through this code.
John:
And that's different than a situation of like, well, we're not quite sure what we want to make it, but it's going to kind of be like this.
John:
And in that case, writing all these tests would just be like...
John:
pinning yourself down with spider webs while you're trying to move to an unknown destination.
John:
So you have to recognize, like, when do I have enough information to really pin this down with tests right now?
John:
Or when do I have to do kind of a more fast and loose agile type thing of, oh, I'll just get something up and running and we'll look at it and we'll poke around that and we'll see how... Like, in that case, you're wasting your time to...
John:
writing and changing and writing and changing tests for something you're not even sure how it's supposed to work so in all these cases like you can't take you can't use the same tool for all different situations you have to know like for example in marco's case when he's doing the ui like oh let's look over there how does this transition look maybe this button should be over there maybe this actually shouldn't be a button it should be a slider let me try this with a gesture like
John:
Writing tests for all those cases would just slow him down.
John:
It would not help.
John:
Whereas, for example, the sync code, which can be largely faceless, and very complicated in many different states, is an ideal opportunity to do a very complicated series of data-driven tests and maybe even some fuzz testing to be confident that this tiny little kernel of stuff that you've made works the way you expect it to.
Marco:
Oh, yeah, and one of the reasons why I don't write a lot of tests is because most of the code I write, and especially most of the difficult, tricky code I write, is the former, which is it's UI stuff that's much harder to test and write tests for and maintain those tests as I change things and as I refine the design, as I add buttons and features and move stuff around.
Marco:
It's much harder stuff to test for.
Marco:
I don't end up writing a lot of the...
Marco:
easily testable faceless module math code.
Marco:
Like that's, that's very unusual for me to write a lot of that.
John:
But you've got, no, you've got the F something DB.
Marco:
It's not FM DB.
Marco:
It's FC DB.
Marco:
It's FC model.
Marco:
And somebody else wrote tests for that.
Marco:
This is why open source is great.
John:
Yeah, but I'm saying, like, that's another thing that open source does, because most open source cultures have a culture.
John:
Oh, I'm going to say most of them have a culture of culture, but I'm always depressed when I download something on Tart and, you know, run configure and make an error and make tests, and it says, no, make tests.
John:
I don't know what you're talking about.
John:
And I'm like, oh, come on.
John:
uh but yeah most most of the newer uh software cultures are uh in dynamic languages instead and even javascript stuff like testing is part of the culture and if you release something as open source you're kind of it's expected there's social pressure to say where's the test suite how can i tell that this works on my system i want to immediately you know run the test suite although i mean pearl is super crazy on the testing thing where it won't even it won't even install modules if they don't pass their tests unless you know the secret incantation to tell it don't bother running the tests uh
John:
And that runs into all the anti-patterns that I talked about.
John:
Like, well, tests are software, too, and the people who wrote them aren't infallible, so a lot of times the module won't install because the tests won't pass, but the tests are wrong because they were written by another fallible human.
John:
And, you know, you can go too far in that direction as well.
John:
But overall, it's a good idea to, you know, test until it hurts, basically, and then back it off a notch.
Casey:
Oh, goodness.
Yeah.
Casey:
All right, so are we good?
Marco:
Thanks a lot to our three sponsors this week, In Flux by Brave Wave, Ting, and Squarespace.
Marco:
And we will see you next week.
Marco:
Now the show is over.
Marco:
They didn't even mean to begin.
Marco:
Because it was accidental.
Marco:
Accidental.
Marco:
Oh, it was accidental.
John:
Accidental.
Marco:
John didn't do any research.
Marco:
Marco and Casey wouldn't let him because it was accidental.
Marco:
It was accidental.
John:
And you can find the show notes at ATP.FM.
Marco:
And if you're into Twitter, you can follow them at C-A-S-E-Y-L-I-S-S.
Marco:
So that's Casey Liss, M-A-R-C-O-A-R-M-E-N-T, Marco Arment, S-I-R-A-C-U-S-A, Syracuse.
Marco:
It's accidental.
Marco:
Accidental.
Marco:
They didn't mean to.
Casey:
Accidental.
Accidental.
Casey:
Gentlemen, thank you for letting me have my moment.
John:
I wanted to talk about it too, but I think the problem is software methodology is too big a topic.
John:
It's like software development.
John:
Tonight's going to be the development show.
John:
Right.
John:
Discuss it.
John:
Software.
John:
What do you think, guys?
Casey:
Yeah.
Casey:
And the other thing is, it occurred to me that I was describing my experience with Agile
Casey:
But I know that we're going to or I'm going to get so much email.
Casey:
Oh, that's not how Agile is.
Casey:
Oh, you're calling Scrum Agile and Agile Scrum and you don't know what you're talking about.
Casey:
Oh, my God.
Casey:
I'm not looking forward to that at all.
Marco:
I'm just glad because last week when I asked people to tell me what their organization did about warnings in production –
Marco:
I don't think we've ever gotten that much feedback.
Marco:
Seriously, every time I check my email, all day long, there'd be three more, and they were each five paragraphs long.
Marco:
It was actually a lot to keep up with.
John:
Well, when you solicit, like, tell me about the problems that you have at your work, people will say.
John:
We didn't solicit feedback in the show about software methodologies, but...
John:
Well, when we get the things of like, if you were doing it right, like you didn't put the butter in the coffee or whatever, like the whole, the whole nine yards, like, it's just kind of like, no, you don't understand.
John:
My religion is the true religion and you're doing it ever so slightly wrong.
John:
Like if only you didn't eat shellfish, you'd be fine.
John:
Like, and it's, it's, that's why I was trying to get at the beginning of like the whole point of software methodology is like to take, to, to attempt to impose order and to make things better than they could ever possibly be.
John:
Like no software methodology can possibly do this.
John:
Like there is, there is no,
John:
there's no silver bullet there's nothing you can do to make it as good as it can possibly be you just have to decide what is the appropriate level of annoyance for the given task at hand and then there are many things to choose from and some are better than others and people write in to tell us that but like i don't think we're gonna get any absolutists who are like you know pair programming is the only way to do programming anyone not doing pair programming is doing it wrong and there's no way anyone who's not doing pair programming
John:
can be as good as someone who's doing pair programming say that well i don't think we will because they won't listen they don't listen to our show and the thing is like that's the that's the thing we didn't discuss here is like unless you have a time machine you can't a b test these things because software is like it's
John:
It's always different.
John:
You have to get the same exact people solving the same exact problem in the same exact environment with the same exact knowledge.
John:
And by the time they're done with that project, they have new knowledge.
John:
And you can't find people who are identical.
John:
It is impossible to validly A, B test because everything software engineers do is novel in some small way.
Marco:
Yeah, that's one of the problems with a lot of these things.
Marco:
I mean, this is a problem in so many fields and so many actions, but when you can't really scientifically test this stuff very easily, if at all, then you might do something in your methodology and ascribe your success or failure to that thing when in fact it had little to do with it or nothing to do with it.
Marco:
And
Marco:
That's why I look at so many of these things with skepticism.
Marco:
Like, okay, you did it this way and it worked.
Marco:
But if you did it some other way, would it have also worked?
Marco:
And did it work because of the way you did it?
Marco:
Or did it work because of the people and the conditions they were in?
Marco:
And there's all these uncertainties.
Marco:
Like, I recently got into the world of high-end headphones.
Marco:
And...
Marco:
I mean, the audiophile world is comical in the things that it believes in.
Marco:
And I go on HeadFi, the biggest headphone enthusiast forum, and I have trouble relating to the people there because they're all talking about how they upgraded the cable to this new cable and now they can hear all sorts of things that cables can't actually make you hear and that all cables, you know, cables don't vary that much and it's all psychological and you're spending $400 on a headphone cable.
Marco:
I can't understand these people because I know scientifically what they're thinking is invalid and what they're saying is wrong and they're wasting their time and money doing things that are just totally placebo.
Marco:
And I wonder how much of the methodology stuff is that same way where you can't really say that helped you.
John:
Yeah, I think individual people can tell what parts of a methodology they're using is helpful to them, basically by gauging their own performance.
John:
They're like, I've gotten similar problems like this in the past, and I performed this way on it, and it's taken me this long, and I've had this much difficulty.
John:
And I know when they told me to do this, I felt that I was going to have difficulty with it, but I did this new thing this time, and it helped me do it better.
John:
And like...
John:
That's like on an individual basis.
John:
Like I decided to use testing or I had a friend look at my code before I checked it in.
John:
So we kind of had informal code reviews or I clarify the requirements.
John:
Like that's just, you know, becoming becoming a programmer and having experiences.
John:
You learn what all those little things are.
John:
And that's also part of the frustration is if you're put into an organization where you're told to do X, Y and Z, but not this thing, you know, that helps you.
John:
And you're like, oh, well, you know, I really I really do better when I'm pair programming or I can't stand pair programming.
John:
It makes me unable to work.
John:
But the organization, like, it wants to have rules for everybody.
John:
They don't want you to just do whatever the hell they want, because then they feel like they can't manage anything.
John:
And that's the difficulty of the situation.
John:
That's like, even without A-B testing, I feel like individual programmers can get a feel for the things that help them and want to repeat that, you know, as appropriate.
John:
Did you see a link up in the chat room, by the way, with the audio file Ethernet cable?
Marco:
Yes.
John:
Dalton posted that app.net today, and he said he couldn't tell whether it was a joke or not either, and I can't tell either.
John:
That's the thing about these sites.
John:
It seems like it's got to be, but then you never know.
Marco:
Anything that is made for audiophiles that promises better sound quality, that has no basis in science, has no basis in ABX testing, and costs a lot of money, is probably not a joke.
Marco:
The law of audiophile crap out there is like, yeah, it's out there, they're serious, and people are actually buying it.
Marco:
Probably not a lot of people, but enough people to make it worth selling a $1,000 six-foot cable.
Casey:
Yeah, that is absolutely ridiculous.
Casey:
There's got to be a joke.
Casey:
Come on.
Casey:
Hey, do we want to do a quick accidental neutral on CarPlay, or do we want to save that for next week?
Marco:
We can do it.
Marco:
Honestly, I really don't think there's much to say about it yet.
John:
Why do you even say that?
John:
You know how this goes.
Casey:
That's the Top Gear equivalent of how hard can it be.
Marco:
Right, exactly.
Marco:
Yeah, I mean, we knew about what they were calling iOS in the car last summer.
Marco:
And we knew this was in the works.
Marco:
And there's some stuff in the iOS 7.1 SDK that's in beta still.
Marco:
There's some stuff in there that looks like it's probably related.
Marco:
And...
Marco:
So this is not really a huge surprise.
Marco:
And then even like a month ago, I think it was Stephen Troughton-Smith, one of the good iOS hackers was leaking screenshots of the simulator running with the CarPlay interface.
Marco:
Anyway, so...
Marco:
It's not big news that this is happening.
Marco:
The important news, I think, is that it's twofold.
Marco:
One, that Apple's actually kind of working with the car manufacturers to give a variety of input methods.
Marco:
The Ferrari one that was demoed was a resistive touchscreen.
Marco:
The Mercedes one used a control wheel and the screen wasn't a touchscreen at all.
Marco:
And then some other one used a touchscreen.
Marco:
And so they're showing off... There's a variety of different screen inputs, which is important because if you look at the car...
Marco:
screen control landscape, as we've discussed many times, it's all over the map.
Marco:
And not everybody, including our beloved BMW, they don't use touchscreens at all.
Marco:
Lexus also stopped using them recently.
Marco:
I believe that will probably also filter to Toyota if it hasn't already, where these little remote dongles of some sort, these remote knobs or pointer things, are being regarded as more safe than touching the screen and certainly works a lot better.
Marco:
So...
Marco:
It's nice that Apple is kind of adapting to what's out there to a degree.
Marco:
It's also not surprising that what they want is, and what CarPlay seems to be, is literally AirPlay, basically.
Marco:
It's like iOS is creating the entire interface as a video and streaming it to the car's navigation system and taking over the video screen.
John:
Well, it's two-way AirPlay because it takes input.
John:
Sure.
Marco:
Yeah, yeah, yeah.
Marco:
Sure.
Marco:
So it's basically AirPlay video output, at least, so that, yeah, so Apple's just taking over the screen.
Marco:
So it's not surprising they're doing this.
Marco:
It's not surprising they got a few car manufacturers to say, we will do this soon.
Marco:
What will be news, and this is what I said in my post about it, what will be news is when a lot of cars have shipped with this.
Marco:
Because that's still up in the air.
Marco:
That could still not happen, or that could still take a long time to happen.
Marco:
And if a few car makers introduce it...
Marco:
on a few of their high-end models for model year 2014 and the future.
Marco:
And let's say BMW has this thing called BMW apps.
Marco:
If you want that in your car, you have to pay extra money in most cases on most of the models.
Marco:
And so if the other manufacturers offer CarPlay, but it's a $500 option or a $200 option, or if it's an option at all that costs extra money at all,
Marco:
And it's only on certain models.
Marco:
How long is it going to be before a lot of cars actually have this on the road?
Marco:
And that could be a while.
Marco:
So there's two sides.
Marco:
As a user, if you buy a car with it, that's great.
Marco:
It works for you.
Marco:
As a developer, I think it's potentially a lot less interesting for a while unless it gets a meaningful install base.
John:
I was kind of depressed by the announcement because what it showed me is that like television thus far, this announcement proves that cars are another area where Apple is not going to be able to make things better as much as we want them to.
John:
Like television, they have the little puck and it does some things, but it doesn't solve like the whole television problem.
John:
And you're like, oh, I was really hoping Apple would just go in there and solve everything like they did with music, but they're not.
John:
And in cars, same thing.
John:
They're coming into... We know, like television, it's all a screwed up situation and everything.
John:
They were screwed up.
John:
We're like, oh, God, Apple, please save us from these terrible car interfaces.
John:
And they can't.
John:
They just can't.
John:
Like, what they're doing is saying...
John:
You know, please let us have access to your existing screen where you run your existing software and let us take over it briefly.
John:
But that's not the way that's like saying, please, Johnny, I've designed the iPhone for us.
John:
But all you get is what's on the screen.
John:
We're going to tell you what's surrounding it.
John:
whether there's any buttons what they look like how big it is how much it weighs what the battery life is but make a great product for us and as we've discussed when we discussed the car car interiors what was that was that a neutral or on this show i didn't remember it was neutral like the things that make a car interior like it's it's a holistic thing it's it's everything about it it's from the driving position and the visibility to how many physical controls are to how many virtual controls to how they interact with each other to the software the hardware like it's
John:
it is one big whole thing and it's like unless apple can design that entire thing they're not going to be able to ever really solve the problem and they can't design that entire thing because they're not a car maker the same way they can't fix television because they don't own all the programming and they don't own all the television sets and you know i guess they're doing the best they can in an ideal scenario the integration required for this will will shrink to some 10 cent chip that just like everybody has in their cars and
John:
And they use that same chip to do interaction with Android and whatever else.
John:
And it's just like, well, when you buy a car in the future, whatever smartphone you have, which we'll just call phones because all phones are smartphones by this point, will be able to throw up its UI on the screen and will make something out of it.
John:
But that interface is always going to be less satisfactory than it would be if there was one design thought for the entire thing.
John:
You can't just make some rectangle on your car and say...
John:
This is the rectangle where smartphone stuff happens.
John:
And maybe there's some buttons on the steering wheel that activate and do stuff like you are never going to get the right, really good interface with interaction of everything unless someone is designing the whole thing.
John:
And I believe karma manufacturers are not thus far capable of designing the whole thing.
John:
And Apple is not allowed to design the whole thing.
John:
So we're kind of stuck with this crap for now, I guess.
Casey:
Yeah, and the other thing I've noticed is I had a heated but friendly debate with Dave Nanian, who writes the excellent software SuperDuper, which if you don't have, you should.
Casey:
And he was extolling the virtues of the Tesla interface.
Casey:
And I have not interacted with it myself, but...
Casey:
He was saying that it's extremely good and it's touchscreen done right.
Casey:
And I have, in neutral, I quite vehemently said I hate touchscreens in cars.
Casey:
And I stand by that to this day, but I've not seen the...
Casey:
The Tesla interface and Nainian, among others, he wasn't the only one, but he was an example of somebody who came out of the woodwork saying, oh, my God, really, the Tesla interface is so good and this is so bad.
Casey:
And he in a series of tweets that this might have been a direct message between the two of us, but he said to me, it's like Mac OS on the phone.
Casey:
Do we want that?
Casey:
Or another example is iOS on the Mac.
Casey:
Is that really what you want?
Casey:
I'm not sure if I agree with him or not, although I really don't like the name CarPlay.
Casey:
The screens I saw I liked, but his point is absolutely interesting and worth thinking about.
Casey:
Is this really the right answer?
John:
Yeah, I think the right answer has to involve more than just that screen.
John:
I mean, just look at the little home button, like the UI home button.
John:
Why is that there?
John:
Because they can't make a hardware home button.
John:
Like, because they're confined to that little screen.
John:
And, like, it's sad that their interface is probably going to be better than the iPod integration that car makers have been shipping for years simply because, like, look, it's not rocket science, people.
John:
Can't you just integrate?
John:
We gave you this interface to integrate with our iPod.
John:
iPods.
John:
I've got it in my Honda.
John:
You can show the track name, you can go next in previous track, but you still did it bad and you got the details wrong, so just give us a screen and we'll do an iPod and we'll do Siri integration.
John:
In many respects, as many people pointed out, there are advantages to this over the existing systems because now I can upgrade my phone and I automatically get something better with CarPlay and all that stuff, but
John:
If, for example, your car has a really slow UI and CarPlay is laggy on it, or if you buy your $200,000 Ferrari and it's got a resistive touchscreen, upgrading your phone is not going to fix the resistive touchscreen.
John:
Upgrading your phone is not going to add a physical button.
John:
And if your car UI has one touchscreen and they use that touchscreen for climate controls, but then you have the CarPlay thing on it, you have to get out of CarPlay just to change the temperature and you wish they just had a knob, it's not going to fix that either.
John:
So I really wish there was like...
John:
Sort of a single-minded, holistic approach to interface, and that's why I think Dave likes his Tesla so much, because that's a case where the carmaker does do the whole thing, and they do concentrate heavily on touchscreen-type interfaces, and it does come together in a manner better than most other cars, but...
John:
I mean, the Tesla, for example, I think it should have more physical controls and it's definitely a version 1.0 software and it's not as snappy as like an actual iPad is.
John:
And it's like we see that the technology for all this is there.
John:
It's just not like the correct arrangement of the people with the technology and the people who make the cars to make it happen.
Casey:
Yeah, I don't know.
Casey:
I'm very intrigued by this.
Casey:
I think it has a lot of potential.
Casey:
One of the things I'd noticed is that, to me, the look of iOS 7 made a lot of sense on screen.
Casey:
I don't know why.
Casey:
Not to say that I dislike it on iDevices, but I actually really, really, really liked the look on the Ferrari and Mercedes and Volvo video demos.
John:
The bar is low.
John:
Think of what your UI is like.
John:
I should show you some screenshots of what my Honda's UI looks like.
John:
It's like a web page from 1995.
Marco:
It's not good.
Marco:
My favorite part of the Ferrari video was when the Apple rep who was demoing it, she's showing that you can switch back to the Ferrari interface.
Marco:
She's like, well, if you want, you can tap here to switch to the FF interface.
Marco:
But we'll just go right back.
Marco:
She showed it for a second, and it just looked awful.
Marco:
And this was a brand new Ferrari.
Marco:
The interface looked horrendous, and then switched right back to this nice, clean Apple world.
John:
Yeah, because Ferrari's expertise is not in user interface design for the touchscreens in their cars.
John:
Like that is not where their strengths lie.
John:
And it's never going to be.
John:
And like in this respect, I bet Ferrari is like, oh, finally, someone could take over some of this stuff.
John:
But but still, it's like you have not everyone's going to have a phone or plug it in.
John:
So you have to have an interface there.
John:
And just the standard is so low for these for these interfaces that, you know, they're.
John:
i don't know what the solution is like again tesla at the very least they're taking it seriously and saying we're going to have a different ui we're going to take ownership of it we're not just going to have some sort of generic touch screen and we're going to have some third party write some software and put like our logo above it in a different background color and call it a day i know other companies do much more than that but like it's a difficult problem it's difficult on many levels to figure out
John:
what the best balance is between physical controls and touch controls and all the modern features people expect and integration with their devices.
John:
So I think CarPlay is a step forward, but it's a small one.
John:
Like Apple TV was a step forward too, but it's a small one.
Marco:
I think it's worth asking what problem this solves for everyone involved.
Marco:
Now...
Marco:
To me, a lot of the audio functions of it are solved perfectly well by Bluetooth, and Bluetooth is extremely convenient because when done right, and it's usually done pretty well in cars, surprisingly, because there's not much to it.
Marco:
When done right, I have Overcast on my phone, and if I'm in my house and if I'm washing dishes or whatever, I'll play a podcast.
Marco:
And then if I go to my car to go to the store, I get in the car, turn the car on, and just start driving.
Marco:
And a few seconds later, my podcast starts playing through the car speakers.
Marco:
When I turn the car off, it pauses and saves my position.
Marco:
And then when I go back inside, I can resume it and play inside.
Marco:
And all of that works without having to plug the phone into the car, without having to wait, without having to launch anything.
Marco:
I get in the car, the phone happens to be in my pocket because it's always in my pocket, and it just works.
Marco:
Do you have a way to pause the audio?
Marco:
Yeah, through the car's built-in wheel controls and stuff.
Marco:
Because the car, using the Bluetooth protocol, the car can signal basic things like play, pause, track forward, track back, stuff like that.
John:
Can you change playlists and stuff?
John:
Because this is like the simplest possible scenario that you're describing where you're in the middle of an audio and you know exactly what you're playing.
John:
And I agree that that's a step up from what you would have had to done before.
John:
But even a slightly more complicated scenario, like I'm going on a trip and I want to hear this song or this playlist.
John:
That's a place where CarPlay would have your back, because it's like, I know how difficult it is to, you know, using my stupid on-screen controls, even if I have my iPod plugged in, to find the playlist I want, to select it, to, you know, enable or disable shuffle, to, you know, to do all that stuff with a touchscreen, not touchscreen, with my stupid controls.
John:
It is terrible.
John:
and siri is probably also kind of terrible but it's better i would rather shout something out to my car and say and tell it what to play than do nothing but bluetooth doesn't solve that at all because bluetooth doesn't give you like here's a here's a visual interface to like all your playlists or all your songs now go find the one you want right it's merely like a wireless version of an audio cable and so carplay i think is a step up from that even if it lacks the seamlessness of you just being able to get in and out of your car
Marco:
Oh, yeah.
Marco:
I mean, for podcasts, I think the difference is a lot smaller because you tend to listen to one podcast for much longer than you listen to one song, and you tend not to have to do serious navigation to find the podcast you want to hear at this moment.
Marco:
Generally, you put it on, and whatever's on, you keep listening to it because it's an hour and 50 minutes long.
Marco:
So it's not that big of a problem for podcast music.
Marco:
I agree.
Marco:
You're right.
Marco:
And obviously, a lot more people listen to music than podcasts.
Marco:
But just pointing out that Bluetooth...
Marco:
Bluetooth convenience is pretty severe competition for this at the start for audio functions.
Marco:
And Bluetooth is also everywhere already.
Marco:
Bluetooth is in so many cars now, so many new models included.
Marco:
It's been around forever, so there's so many cars already on the road with Bluetooth that it really does solve a lot of these problems in a pretty limited but very effective way.
Marco:
So where CarPlay, I think, will really shine is navigation in theory.
Marco:
But I think in practice, this is still iOS maps, iOS navigation, and trying to replace a car system or either trying to sit on top of a car system that's being ignored or be present in cars that have screens but don't have nav, which is not a ton of them, but certainly there's still some.
Marco:
And is that really what you want?
Marco:
I mean, usually a car's built-in nav is not that bad, and it's also all loaded, all offline, all built-in, ready to go.
Marco:
It has the high-precision GPS receiver on the car.
Marco:
Yeah.
Marco:
In my opinion, the GPS that's built in to cars that have navigation is usually way better and more consistent than the one in iOS 6.
John:
Well, I mean, maybe in an M5, that's true.
John:
But I think the big advantage it has is that as your car ages, assuming you keep it for a while, your phone will get better and the navigation presumably will get better.
John:
You know what I mean?
John:
Whereas whatever navigation your car came with, that's the navigation it's going to have.
John:
And that in my experience is what happens when I get into someone's car and it's like an eight year old car, their navigation is gross looking.
John:
If they bought a modern car, it would be better.
John:
But I think the key is that to do navigation well, you need to integrate with the rest of the car.
John:
Like Marco said, from the antennas that you're getting the signal from instead of having a tiny little iOS device inside an armrest plugged into a cable underneath a big steel rear.
John:
roof all the way up to like you know eventually we're going to show you know the augmented reality stuff you're going to want to show stuff on the hud you're going to want the navigation to know maybe the navigation wants to know the speed from the speedometer and the angle of the wheels instead of having to get that info from gps and dead reckoning like there's so much more you can do when you did navigation built into the car than when all you get is to be i'm a phone i do navigation and i can project my image onto the screen like it's it's such a weak solution to a calm uh to a common problem that cars have been solving for years on their own
Casey:
Well, the other problem is Marco's navigation in your brand new M5 is excellent.
Casey:
And the navigation in my 2011 3 Series is pretty darn good.
Casey:
I'm actually very glad I got a car with navigation because that wasn't the plan when I went looking for a used 3 Series.
Casey:
However, even in the... I think the build date on the car was December 2010.
Casey:
In the...
Casey:
three-ish years since the car has been built the local area has changed quite significantly and so if for no other reason even the ui left alone there's an extreme advantage in having your phone do your navigation because the maps get updated and i'm not talking like the ui i'm talking the actual data gets updated
Casey:
And I'm looking right now at how much it would cost to get my maps upgraded from BMW.
Casey:
And I need to pay for a $40.90 USB key.
Casey:
And that just gets me the key.
Casey:
On top of that, I need to pay $204.11 for the actual maps themselves.
Casey:
So I'm in $250 to get an update for the nav on my car.
Casey:
And one of these days, I'll probably pony up for it because after three or four years, it gets to the point that you're really in need of it because a lot of the streets I go to, I shouldn't say a lot, some of the places I go to, they just don't, they plain don't exist.
Casey:
on the navigation in my car so that's a bummer additionally traffic lately as mentioned by david t move in the chat it traffic lately is way better coming off the phone than it does my car and my car does accept it does receive traffic and it's good but it's certainly not foolproof and with the uh advantages that ways brings among other things with kind of crowdsourcing uh traffic reports
Casey:
it's almost always going to be better in navigation on the phone.
Casey:
So yeah, right now your M5 is wonderful, but I'd be curious to see if you said that in three or four years.
John:
Well, that's another example of your car aging and not doing well with the tech.
John:
But like, I think the root problem is right now it's
John:
It's unacceptable for someone's home to not have an internet connection, but it's acceptable for cars to not have an internet connection.
John:
Everyone's like, I don't want to pay for two wireless bills.
John:
I don't want my car to have a separate connection.
John:
That's a symptom of the market, the shape of the market now.
John:
What we would want is, as time goes on, as cars get better, inevitably, cars need to have network connections, and cars need to auto-update their maps, and they need to not charge it.
John:
Your car is old, so it doesn't do this.
John:
Modern cars still don't have internet connections, but they can get one through your phone, maybe.
John:
Actually, we're doing the reverse here in saying, nope,
John:
car you still can't have an internet connection but my thing that i have that has an internet connection it's allowed to spray its image up on your screen and you're allowed to send it inputs down to it but like you know not too far in the future if we ever get the stupid carrier stuff sorted out or like we have better wireless like cars need to have internet connections just like homes need to like
Casey:
Well, mine does.
Casey:
Even my 2010 built car does.
Casey:
And if I subscribe to like the Super Baller BMW, what is it, BMW Assist, which is kind of like OnStar, I can do basic Google location searches from the car.
Casey:
And certainly up until Google freaking ruined Google Maps recently, I was able to send addresses from Google to my car, which sounds silly, but oh my God, it's the most wonderful thing in the world.
Casey:
And so my car has some modicum of internet connectivity, but that doesn't really...
John:
With terrible software.
Casey:
Right.
Casey:
And to be honest, you're on a kind of different point, which is it should be able to do a lot more with that Internet connection than receive extraordinarily small packets of search results and addresses.
John:
Yeah, that's what I'm saying where we see all the pieces.
John:
We know what iPads are like.
John:
We know what iPhones like.
John:
And we know all the things that could be useful to cars.
John:
And it's like we have this tech.
John:
It's not that expensive compared to the cost of a car.
John:
Yeah.
John:
We know people know how to write software to do this, but they're not at the car companies.
John:
And, like, we just got to get these guys together.
John:
And that's kind of like, you know, we were hoping in the Apple announcement or something, like, maybe they would get together.
John:
Maybe Apple would buy Tesla and be able to do the whole experience.
John:
But they're still so far apart.
John:
And the things we know today are technically possible that either are not financially feasible or just not organizationally feasible.
John:
Like, we can all envision, you know, like, why is the car this separate car?
John:
realm where we can't have the nice things that we know exist why do we have to choose between navigation that's integrated with our car but it's crappy in other ways and navigation that is you know fast and responsive and can respond to voice commands and gets its maps updated all the time but is not integrated with our car in any way yeah i don't know i'm curious to see where it goes though for sure
Casey:
I'm going to be very jealous when my car can't do it.
Casey:
I'll just have to get a new M3.
Casey:
It's the only answer.
Marco:
I wonder, too, how much of CarPlay will fail to be useful to people who aren't totally bought into the Apple ecosystem?
Marco:
There's a whole lot of features in Mavericks and iOS 7 where if you don't use Safari as your browser, for instance, then it doesn't work right for you.
Marco:
Or if you don't use iCloud's Reminders or Calendar or whatever.
Marco:
And
Marco:
So how much of that do you think will apply to CarPlay, where obviously it's very much based on Siri?
Marco:
And actually, one topic is third-party apps integration with it.
Marco:
And Apple, as far as I know, they have not clarified whether anybody will be able to make an app that uses this or whether this is partners only, like Siri.
Marco:
And it sure looks like it's partners only to start, at least.
Marco:
to what degree will this be limited if you choose not to have, not to use, uh, Apple services for everything or Apple's apps for everything?
John:
Yeah.
John:
I mean, Google maps, you know, it was the obvious example of like, what if I don't want to use Apple's apps, uh, maps?
John:
I want to use Google maps.
John:
Right.
John:
Exactly.
John:
Yeah.
John:
I don't, I think they're going to have to limit it probably, you know, like safety and legal reasons.
John:
Like, uh,
John:
we have all these rules about you can't even enter the destination of where you're going if your car is not moving.
John:
The car manufacturer puts that into their navigation, right?
John:
At what speed is it safe to play Flappy Birds on your AirPlay screen?
John:
You know what I mean?
John:
It's only one tap.
John:
We can send that over CarPlay, right?
John:
That's really easy input.
John:
Yeah, that'll work with the iDrive knob.
John:
Just hit the knob to flap.
John:
And I think one of the conversations that Casey was having with Dave on the Twitters was...
John:
what do you call it?
John:
The scrolling, like touch scrolling.
John:
Like, and how that's not quite as natural as you might think it would be when you're in a moving car versus buttons.
John:
That was mostly getting back to, like, the resistive touchscreen that the Ferrari has.
John:
It has to have buttons because it's terrible, right?
John:
But, like, even without that constraint, you know, what's the easiest way to find something in a long list when you're in a moving car?
John:
Because, like...
John:
scrolling through a list is great when you're looking at your phone in your hand and flicking with your thumb but your eyes are on the phone the whole time when you're when your eyes are supposed to be on the road is you know if you flick and then look back at the road and look back down and you've passed it like maybe that's not the best interface that's why it keeps getting back to syria that's why they keep demoing syria because that's what you want you want to eyes on the road but still get done what you want to get done and that's one of the strengths also of knobs and dials is that you if they have little things you can feel them clicking you know how far you're going or
John:
You can feel switches in the on or off position.
John:
You don't have to take your eyes off the road.
John:
It's a different environment, and the things that work great on iPads and iPhones UI-wise don't necessarily work the same way in the phone.
John:
That's why I think CarPlay looks so different, and it is so, like, sort of Spartan and limited, and they keep demoing Siri.
John:
It's like...
John:
They don't want you to say, oh, great, now it's exactly like mounting my iPad to my dashboard.
John:
Mounting your iPad to your dashboard is dangerous in terms of what you can do to distract yourself.
John:
And CarPlay, I think, is trying very hard not to be that dangerous.
John:
So that's why I would imagine it's not going to be open season.
John:
Or if it is open season, the things that third-party apps are allowed to do through the interface is going to be so limited that...
John:
It's not going to allow you to put Flappy Bird up there or play a movie or something in the front seat of your car.
Marco:
Right.
Marco:
Now, actually, the new stuff that's in the iOS 7.1 SDK looks like it would be a way... Stupid NDAs.
Marco:
Whatever I can say.
Marco:
It looks like it would be a way to have arbitrary apps be usable from the screen, but only present a structured menu, kind of like the old iPod.
Marco:
So your entire interface could be the structured menu, and you have a few limited things you can do, but you're not just given an arbitrary view that you can do whatever you want with, like put a game in it.
John:
And I bet those menu items would be speakable.
John:
You'd probably put in some metadata to say, if they say this, that's what they mean.
John:
If they had voice... They want it to be a simple interface, so you can't do some crazy thing.
John:
And also, ideally, you wouldn't have to touch the screen at all, but you could activate the app and say, like they were showing...
John:
play song name whatever or if you put a menu of five options pick an option which is send text and then you know casey's app would send a text and it would say you know like that type of integration and that's what i mean it's kind of boring because you look at it and you're like oh it's like it looks kind of like a car ui oh it's a bunch of items and the thing is it's sometimes it's not even it's not even as responsive as you expect it to be because of whatever the crappy host operating system or the host hardware is so
John:
It's still a far cry from the performance and experience of having an iPad in the dashboard, but you probably wouldn't want to have that anyway in terms of the UI.
John:
The UI has to be simpler and different because it's not the same as holding an iPad and using it.
Casey:
By the way, I should mention that what was news to me anyway, and I believe news to everyone, was that CarPlay will support things like the iDrive controller, which I consider to be a tremendous win.
Casey:
Despite Dave Nanian's love for touchscreens in cars, I'm still of the opinion that having a physical control is a much, much, much better way of doing things.
Casey:
And so having some amount of integration with
Casey:
Things like the iDrive controller I think is very important and a very welcome bit of news that I didn't know before.
Marco:
oh yeah definitely and and that's me too like when i when i saw that because that's the thing you would expect knowing apple and the way they usually do things you would expect they would say all right everything that we that we support has to be a touch screen period like and they would just dictate that and then you know two manufacturers would sign up and no one else would and heck maybe that's why we haven't heard about ios in the car for almost a year maybe their original plan was to dictate that and they couldn't get enough support they've been slowly backsliding fine resistive touch screens are in fine you can use a job final but
John:
We'll put the home button on the screen since you guys can't find a spot for it on your dashboards.
John:
It's not going to change your dashboards for our UI.
John:
And they were probably all saying, we also want to be able to integrate the same way with Android.
John:
So nothing you do can preclude someone plugging in their Android phone to do whatever the hell they're going to do for that.
Marco:
Right, exactly.
Marco:
But yeah, I think the new stuff in 7.1, it doesn't say it's for CarPlay, and it doesn't say much of anything, actually.
Marco:
There's not a lot of documentation for it, but the new stuff in 7.1 sure looks like this is what it's for, and it's a way to create a hierarchy of menus for things that could be music or it could be anything.
Marco:
So that would mean that both Overcast and Fast Text would, in theory, work over CarPlay.
Marco:
And whether it's integrated with Siri is a different story, and they could be, it might not be, it might be limited, who knows.
Marco:
But that's a different story entirely.
Casey:
Yeah, I'm very interested to see whether they do something a la, you know, BMW's connected apps where you have to be a blessed partner in order to get access.
Casey:
We'll see.
Casey:
It'll be interesting.
John:
All right, it's getting long.
John:
Titles.
John:
man, this Mac pro is good.
John:
Save it for the next show.
John:
Now you get to suffer.
John:
Now you get to hold back and we'll wait until next week.
John:
You can tell us.
Marco:
Well, the funny thing is there's not that much to say about it.
Marco:
Really?
Marco:
It don't know.
Marco:
Don't, don't go there.
Marco:
This is going to be a short topic.
Marco:
Don't go there.
Marco:
The biggest thing I noticed so far, it is, it is noticeably faster, not by like an earth shaking amount.
Marco:
Cause what I had before was already fast.
Marco:
Um, but it is noticeably faster.
Marco:
The IO is definitely faster.
Marco:
Um,
Marco:
What is most noticeable by far, besides how cool it looks, is how much quieter it is.
Marco:
It's shocking how quiet this thing is.
Marco:
I've always been of the opinion that the Mac Pros were always pretty quiet.
Marco:
Compared to what they were doing, compared to any other tower PCs that you would have, they were always pretty quiet.
Marco:
But now that I have this in the same room, and then across the room I still have Tiff's old Mac Pro...
Marco:
It's a big, big difference in noise.
Marco:
And John, if you end up getting one of these things, which you probably won't and probably shouldn't, but if you do end up getting one of these things, that I think is what you will notice first.
Marco:
It's such a big difference.
John:
I'll get one eventually, assuming this form factor lives as long as a cheese grater.
John:
Inevitably, I'll eventually get one.
John:
Yes, I'm looking forward to that.
John:
That and the size, like seeing it there on your desk, like next to your water glass, practically being the size of your water glass.
John:
Like, that's just going to be such, I mean, I'll have more leg room.
John:
Presumably, there'll be fewer cables draped from the top to the bottom of my desk.
John:
You know, it'll be nice.
Marco:
Yeah, it is really cool.
Marco:
So, titles.
Marco:
And I'm actually... I'm not touching the case, because I've seen pictures online of people who have, like, you know, they're covered in fingerprints.
Marco:
So, I pick it up by the lip, how you're supposed to, from the top, and I set it all up.
Marco:
I didn't touch any part of the case except the very lip part, and I wiped that off with the microfiber cloth after I was done.
Marco:
Listen to that.
Marco:
Do you hear that, Sustain?
John:
Well, you would if it was playing.
John:
You don't get that reference.
John:
Never mind.
John:
Titles.
John:
Titles!
I...
John:
I know this is one of my suggestions, but I kind of like it because who suggested it?
John:
Dave, who stinks.
John:
Suggested by underscore David Smith.
John:
I didn't mean that to reference him, but now that I think about it, it's funny.
John:
And I think that's a title that will be difficult to guess.
John:
Well, I guess if you know it's a software methodology episode, you can guess, but I find that one funny.
John:
I didn't get it.
John:
Someone suggested hell as other people.
John:
I always say hell as other people's code.
John:
Like, that's why I was amazed when someone buys a software product.
John:
Like, Daniel Jalkin bought MarsEdit and people buy, like, other apps that companies don't want anymore.
John:
I'm like, that's, like, my worst nightmare.
John:
Like, getting someone else's pile of code dumped onto me, right?
John:
Even if I got to see it beforehand, it would be like...
John:
you know here you go you paid a lot of money for this hope you can make a good go of it hope it's not too crazy if it came with the other person and they were my slave for the rest of their life and they're like what did you mean by this what are you doing like what is the purpose of this class describe to me you know and then if they didn't know i could just beat them you know and say it's also you never thought about what the purpose of this class was did you it just does stuff