Embedded - 116: You Have to Care

Episode Date: September 2, 2015

Glenn Scott (@GlennCScott) spoke with us about API design and techniques for writing good software. Glenn glossed over his bio but it is quite impressive. You can reach him via his PARC page. PARC's Content Centric Networking home: ccnx.org which we talked about in 75: End Up in a Puppy Fight. Literate Programming by Knuth And the more recommended Bob Martin's books While latest source code requires licensing, the binary version of CCN includes the LongBow tools (in user/local/parc/bin). Description of tools and doxygen docs. The LongBow getting started guide should be part of the mid-September binary release. PARC's C Style Guide and C Function Naming Guide

Welcome to Embedded FM, the show for people who love building gadgets. I'm Alicia White, here with Christopher White. We're going to speak with Glenn Scott about API and software design. Hi, Glenn. Thanks for joining us today. Thank you. Good to be here. Could you tell us about yourself? Sure. I've been doing this for a long time. I have a wide background in software development, of course.

I was thinking a little bit about, you know, you sent me some information about this little interview, and I thought on, you know, how exactly I got here, and we were going to talk about APIs, and we were going to talk about even some other things having to do with software ease of use. And I mean that in a different way than most people think about it. I have an educational background that's very wide and one of the

things that comes into play here is that I have I did work at UCLA in linguistics and computer science together. And that added a lot of thinking back in the day, and that still plays out in my career to this day, where APIs, where you're trying to express access to something that has linguistic elements to it,

as well as writing software in a way that anybody can understand it. These are challenges for a lot of people. I'm sure a lot of people have seen really bad code, and I'd like for that to stop, so I'm doing my part. I think there's always the fear that I'm writing really bad code. I mean, I think everybody has that fear. Yeah. Knuth had it right.

It's the art of computer science. It's not exactly science, science or engineering science. I mean, we try and codify what good code looks like, but really, we have many different languages. We have lots of different approaches. We have different ideas. And all of these things come together. But maybe an obvious idea to me may be really hard for someone else to pick up. And when we write prose, for example, you can be a very clear, easy-to-understand writer

or you can be a really difficult writer. Some people pride themselves on those things, those differences, but I think when it comes to software, there are things that we can do to improve the way we communicate. Because we are writing software, of course we're writing it for a computer

to make it do things, but really we write software for people. Because I write software and if I need help, that is to say I'm writing a system larger than what I can write alone, then I need other people to understand what I'm saying. Software is where we do that. That's our language. There aren't as many systems that you can write by yourself anymore. Nope. No. And in fact, even if you did write a large system by yourself, I would challenge you to test it by yourself. Well, and by yourself is a strange definition too, because you can be an app developer, but you're building on top of millions of lines of frameworks and operating systems. Framework. And those folks have tried their best to make their framework accessible to you by using

a vocabulary that is you know comprehend you can be comprehended by you um and a model that can be comprehended by you this is it's it's wide ranging and yet i think a lot not necessarily a lot of people appreciate the difficulty that can be right so do you have some tactical advice? I mean, what are the three most important things we should know about writing good code? Naming. I would say that's probably the most, of all the things that you could do, I would say, and there'll be arguments about this,

and of course I already can interrupt myself and say, well, what about this? But I think that naming is probably the most important thing you spend your time on. Figure out the names of the things. Because if you have the names right, they will explain to you more about what you're doing by using the names. You know, your own brain and its own linguistic capacity will be able to help and guide you, even in your design. So I think that would be the first thing, is to sort out your names. I remember one of the things, so we worked together at PARC for a little while

when I was my short stint in content-centric networking. And I worked more on the hardware layers, but I did sit in on a few of the meetings where you were talking about how to make this API accessible. And I remember you talking about naming and vocabulary in that the API should have as few words meaning the same thing in different places. If you're going to use start, then use start. Don't use start and begin and end.

Yeah, exactly. You want a variety of things. One of the fundamental things you want for your API is that you want to really make your user not have to understand a whole bunch of jargon, acronyms, abbreviations. If you want to say begin, then say begin. Don't take the vowels out and say BGN or something like

this. And you see many APIs that try and squeeze out vowels and it's just silly. Say what you mean and be really clear about it. Don't introduce, yeah, don't introduce a different name for the same thing because as soon as you've done that, that's your clue that you've named it wrong. Don't use a name that you have to explain. So someone says, what is a container? A container holds, you know, a bunch of things. Maybe you should call it thing container, whatever your thing is. This is probably a bad example. But my point is, is that don't be super abstract, because then you have to always explain what you really are trying to go for and don't you know don't require your users to understand you per se use a use a vocabulary that everyone

can understand well one of our listeners we talked about some of similar concepts with dennis jackson on episode 94 and one listener listener, Ed Doitzel, wrote in and asked if we were familiar with simplified technical English, where they tried to find very consistent uses for words. Yeah, I have a favorite application of that, simplified technical English, and that's in your documentation. If you're writing your API, you're undoubtedly, application of that simplified technical English, and that's in your documentation. If you're writing your API, you're undoubtedly, and you better be, writing some documentation on how to use it. I really like, I'm going to jump off a cliff here a little bit, I really

like what Java did. For all of its problems in the language, and there's lots of debate about that, I don't care. What I really liked about Java is it arrived on the scene with a very broad runtime environment that was very easy to see. Of course, part of that came out of Smalltalk, which also came out of Park. But the point is that it came with a bunch of stuff already available to you. You didn't have to go write yet another linked list implementation. And it came out of the box with this stuff. And the documentation was also readily accessible. It was HTML. You could bring it up in your browser. And I can't say whether or not they

use simplified technical English, but that's where you would use it, right there. I'm not talking about using it in your papers. I'm not talking about using it in your books necessarily. But if you're writing API documentation, that's going to be displayed by your IDE or a user is going to jump on a web page and look at it, that's where to use it. Granted, some of that may also guide you in the way you choose names for your functions or your types. That may. It doesn't have to. But certainly in writing documentation, it should. Because not everybody is a native speaker of your language, right?

So pay attention to them. I do get frustrated when people say, well, I don't want to type that every time. I was just thinking about that with Cocoa, Apple's APIs. Many of the types are really, really really really long and i remember trying to learn x windows back in college and you know there were function names there were 40 characters and stuff it was very intimidating but now i find that refreshing because it's like oh okay i can see what this thing is yeah when you're reading somebody else's code it's easier to get it right

i remember okay i'm really gonna date myself i remember getting um my this was in the 80s i got uh you know i brought up i had 4.2 bsd running on a vax and i curated that thing and i added all the best drivers and stuff i could find around the planet and one day we got a new compiler and that compiler had a new assembler and the assembler allowed you to have names that were longer than eight characters and i vowed that day to never grunt at the world again through eight characters or less and i understand there are people out there that still use things and i'm going to start a war guys vi is not your friend anymore granted i use vi for lots of stuff and i can fly with vi but yeah if you've got a long function name or something like this it's a pain to type in i get it but i don't care there are power tools there really are that make this not matter and it's worth investing your time and getting those power tools under your belt because you will fly with them. Whether they're Eclipse or Xcode or whatever,

there's lots of them. Even some of the VI-like things nowadays know how to do completion. Get those going. I mean, I work with people daily who still use VI and yeah, I get it. But I also tell them I don't care anymore. Stop grunting. If you use VI, then you should be an excellent typist, of course. There are two, right? I haven't said that, but by the time we get to this conversation, they're already a little red-faced at me,

so I don't really push their buttons. But my point is that, yeah, I think those days are gone. I mean, seriously. It's time for Emacs. Dude. Exactly. Yeah, I'm not going to get on that. I also fly with Emacs.

Emacs does all kinds of stuff. I use Emacs regularly for doing big batch stuff, which I can't do in Xcode, for example. Xcode is horrible at refactoring. I can do stuff in Emacs in just a few lines and just jam it. It's great. Okay. So I'm multi-editor,

but I really have to recommend, you know, getting past the tools of the 80s. For some reason, I use VI when I just need to change one thing. Yeah, me too. I'm making a list of something. I'm sending an email or whatever. I will do that. But yeah, not when I'm writing code anymore. So naming. Naming is one of the

top three things people should think about with simple code. Yes. Let's go on to number two. Okay, the number two. So if you're doing an API, you need to think about the model of the thing that you're making the API for. You know, the API might be to some, let's say it's a device, right? Some device, I don't know, like a serial driver or a serial chip or whatever. That chip has a model and you can see what that model is. It could be really stupid, just some kind of FIFO clocked out thing, or it could be more sophisticated or whatever. Take that model and just express that model in your first API. And that's where to start.

APIs, you should also prepare for your API to change over time. So that means a few things. You should probably plan for future extension. But it also means that once you add something to your API, your users are going to be married to that for a while. So you don't just want to change it on them in the next release and then everybody has to rewrite their code. That'd be awful.

But you have to plan ahead. Get your fundamental model down. If you got that down, then all the other stuff that you can add to it sits on top of that model. And then you can make, you know, you can make it look like, you can even make, you can even remodel it and make it look like something else. And you'll see that oftentimes in software where you'll have plugins, where the plugin has an API to a model of a thing underneath, which does a variety of things, right? Many different kinds

of things like Xcode has a plugin system allows you to do all kinds of things to code or do all kinds of things to the output or display. And that's because there's this model. And so once you kind of have your naming down of the thing you're talking about, then arrange those names, you know, the things that you're naming into a model. And then to jump ahead a little bit, the next thing you need to, which sort of blends these things together, the names and the model, then you want to have the abstraction. And the abstraction is the thing that your users will actually use. The model will map to their mental model. The names will map to their linguistic model.

But the abstraction will actually map to the operational model. And I hope I'm making that clear. To be specific, let's go back to the serial port example and talk about what the model for that would look like. I mean, you have a baud rate, and you have an RX and a TX. You have a series of properties, and you have a series of inputs and outputs, presumably. Yeah, maybe it interrupts, right?

So you've got that kind of a weird little thing going on in the model that you can get something asynchronously. But barring that for the second, you can treat it as basically a queue. So the model could be for such a device, it's just a queue. You enqueue the output and you dequeue from the input. And don't have your users be concerned with, set the baud rate as a property, but don't have them concerned about accessing it a different way should the baud rate change, right? You want one way.

And just off the top of my head, I think that modeling it as a queue would be just fine. And that would allow you to say, well, you know i want to swap out the the serial device to something else i still have the same model my software still works i haven't embedded in my software now above my api i haven't embedded in that any detail about the underlying hardware that's bad because then you're really stuck with the hardware and yeah i understand there are cases where you're going to be stuck with the hardware. I mean, my heart goes out to the video guys where try as they might, we still have not got what we need for all the video cards to get along with all of the software.

Well, now they're going the opposite direction. They're all making very low-level, bare-metal APIs to get around OpenGL entirely. So everybody's got their own in one of those. And what that just means is that we have not yet become one with what video is like. We understand what it does. We understand what we need from it. But what is it like to get that? And that's why we have these different APIs

and why now they're trying to say, oh, screw it, we're going to do something else. This is because the model is still unclear. And so there's going to do something else. This is because the model is still unclear, right? And so there's going to be wrestling with that model. Fortunately, I think the serial drivers are probably not so complex. But it's a good example of getting the model and using a model that's, you know, comprehensible and adaptable in a way that in the future, should the device change, no big deal, right?

And you see that, obviously, nowadays. I think that serial drivers are pretty much cooked. And they're often queues, and the queues are often filled inside interrupts. So modeling a serial driver as a queue makes sense. But I'm still not sure I understand the difference between abstraction and model. So can we have another model example?

Okay, let me think. So, yeah, so here's a model. So I'm going to use contemporary experience with Project at Work, right? Where the model is, is that you send network packets, and for every network packet you send, you must receive one network packet in response. That's it.

That by itself, that's a model, right? Now, I've said nothing about what the packets are. I've said nothing about what's in them. Or how they're transmitted. Or how they're transmitted, right? But the model is, I send one, I get one back. There are other examples we could come up with. Maybe I should have thought of

something before now, but that's the model. And of course, that's a very simple model, so I'm not giving you a super complicated example, but that's the model. And it's no more sophisticated than that. Other systems may have a different model. Heck, I don't know. But in this case, that model then can inform you on what the API should provide you. Hey, the API should provide you a way for me to send a packet and a way to receive a packet. That's the model. And of course, this is very straightforward. What I haven't said now is what's the abstraction.

And the abstraction is now we get to talk about what are in the packets. The packet now is abstracted to be, in this particular case, an interest and a content object. And so I have an abstraction for an interest, and that abstraction further adds color to the API because now the API has a way for me to compose a message to be sent. And the message to be sent is an interest message. That's the abstraction. And that abstraction does away with, for example, encoding, does away with order of the packet format, does away with all of that stuff. Again, above this API, the application is not involved

in worrying about that. They just set some properties for the packet, and away it goes. This is a very simple example, but I'm trying to distinguish between the two. So the abstraction for back to the serial port, what would you, what is the, I understand the model now. Okay, Q, got that. Yeah. What does abstraction mean for that? See, maybe. And we've totally gone off the outline so

glenn is making this up as he goes along please be uh be nice to him on that one i think that so if the serial device is you know if it's a byte you know if you're clocking out bytes for example or or i don't know what you're clocking out but you're clocking out something um i think the abstraction would be that I'm queuing something. What's the thing? That's the abstraction. Oh, so like if I was talking serial to a command prompt sort of thing, the abstraction would be each command and each response. Yeah, to up-level a little bit rather than just clocking out bytes. Maybe I'm clocking out command lines being sent over a serial line

to some console input of some router or something. Or even output debug messages. Exactly. And so the abstraction would be those things. What am I outputting? I have maybe an abstraction for every command or an abstraction for a log message, while the model still remains the same. It's a queue, right? So the API, of course, is formed

from these two things, as well as your vocabulary or your naming. And then this is how I go about making an API. So far, my APIs are pretty successful. Folks like them. But of course, again, it's an art. So you are always practicing. You're always trying to improve what you got. What about complexity? Yeah. So that's a different animal that, of course, plays into APIs, right?

So APIs, you can get very complex and ugly APIs. And these are just signs of the fact I think the model is poor. I won't criticize very many APIs publicly because I don't want to get in trouble. But the idea is, is if you have an API with a lot of pieces to it, it's got a bad, either a bad model

or likely a bad abstraction. Or it's a mishmash of two different models that need to be separated. Or 70 people worked on it and nobody could agree on exactly what the thing was, and so all of that is in there. It's a big committee API, which is also horrible. You'll see that show up in the... Like a very common threading API can be criticized for being too much that way.

On and on. But when it comes to complexity, that's one thing. The APIs need, you need to have your names, you need to have your abstraction and your model. Simple. Everything else can be built on top. Don't do more than your API needs to do. Just because you can doesn't mean you should.

Don't add a bunch of all kinds of special condition single function calls to do some special thing that no one in the end will ever do. Just relax. I came across a software golden rule recently that I hadn't seen summarized, and it was you aren't going to use it. You shouldn't put it in. You ain't going to use it.

Agony. I say that a lot at work. Stop it. Agony. put it in yeah you ain't gonna use it agony i say that a lot at work stop it agony and there are many people i probably will be saying it too in the future because it it really is true i see people build complicated things and the truth is you're not gonna use that part let's wait until we need it to build that's exactly and that's a perfectly valid thing to say, because people, it's natural, people like to, creative people like to create things. When people create things, they like the thing they created, typically, they like the thing.

And they'll like it just enough to see that there's one flaw. They have to buff the chrome a little bit. And sometimes you'll end up with somebody who's written some piece of software and they just buff the Chrome for years. You'll end up with features and capabilities that no one will ever touch. That's especially true in API design because as you said you are thinking about the future. And if you leave a function in for people to use,

they're going to always expect it. Exactly. Even if they could have done something better a different way. Yep. The more you add to your API, the less flexible it will be in the future. Kind of black and white, though, because I can see wanting to add accessors

for all the properties of a particular object with an API. And you might not have a use case for that yet, but you might anticipate one. It's sort of a gray area where, yeah, I'm pretty sure somebody's going to need this and they're going to yell at me if it's not there. Or do you just wait until somebody asks? Yeah, I see what you're saying.

So one thing, you know, accessors to, like, properties of the device. Yeah, I would probably say that's reasonable. I don't know. I would make an assessor for each property because what if the device now, what if version two of the device now sprouts more properties?

I have to expand the API, but I would certainly have a way to get a property named or signaled somehow. That's valuable. But what I mean is maybe some higher level construct where i call a function and it does a whole bunch of stuff um you know sets up communication speed or makes a tcp connection to home all kinds of stuff that's too much so yeah get the low level stuff accessible so that you can extend your API. Again, being careful not to make special API function calls for, for example, every property. Just make one, get property, and then use the name of the property, which you can extend without changing the API.

So going back to our serial port, you would maybe make one function that said baud rate parity and bit numbers. That seems reasonable rather than a function that said 300 baud, 600 baud, 1200. Oh, I see. You don't want those. It makes the API too big and someday 300 baud may not be supported and it's hanging out there and now you've got to explain to everybody, deprecated. Oh my gosh, don't do that. Just stay simple. That's complexity in APIs. We can also talk about software complexity itself. Yes. Because this is a hot button for me.

I remember you really actually looking at the code, wanted the code to be easily testable. And I think it was you who introduced me to the word cyclomatic complexity. It's an old concept. It's been around since the 70s. So to sort of back up a little bit, one of the things that I'm sure everyone can appreciate is the problem of bad code. And bad code means a lot of different things, right? It could be an API that's got too many moving parts,

or you have to make too many calls to the API to actually get anything done. Those are complex, right? Other complexity is the code, the actual functions in the code can be complex. And there's a variety of ways that that's made complex. And I think by complex, we mean hard to understand because code can be complex. It can be a complicated problem, but that doesn't mean a complex or complicated problem

needs to have difficult code. And, um, again, kind of back to what I was saying earlier when you write software you are really writing it for other people you know and including yourself i mean yourself on this day two years from now that self me like what does this do most of the time i don't even recognize that i did it see so get blamed oh that was me right and so that's another area where I think not a lot of people pay close attention to this part of writing software. I also think a lot of people, and I don't mean this necessarily as a bad criticism, but I think a lot of people need to write more code and get more practice at it because code comes hard for them. And so once they've written it and they get it to do the thing that they want it to do,

they're kind of relieved. And if they don't want to go back and touch it again, because it's traumatic, right? Troubles them, keeps them up late. And I think that that's just a familiarity kind of problem. Just get really fluent with what you're, what getting your ideas out in code. But your question about cyclomatic complexity, it's pretty simple what it is. Really, it's given a function, you know, some entry point and an exit point between those two places in your code. How many different paths are there to get from the start to the end? If there's one path, it's a pretty simple function, you know, increment. That's one path, basically.

But a pretty boring function. A boring function, but nonetheless, it's a simple one. When you see it, you immediately can see what's going on, right? But if you have a function which has 50 different paths through it you're going to study that guy for a long time and if there's a problem or a bug you're going to take that function apart i guarantee it either you won't take it apart and actually step through all of the combinatorial states that that function can get into through your debugger, which will take you probably a long time. Or you will just say, you know what, this is a horrible function. I'm going to split it up.

That's what I usually do. And reduce the complexity, the cyclomatic complexity. And by doing that, you make it easier, of course, for people behind you to come along and see it too. So recently, and you saw this at PARC, I was insisting that our cyclomatic complexity should be no more ever than five. So I want to give a little bit of baseline for what that means.

Because when you say 50, it's like, oh, wow, that's a lot. My code would never have that many paths. But that is six if-else statements. Yeah. Because, you know, you go through the first if, or you go through the first else, and now you get back to the point they joined back up, and now you go through the second if or the second else. And now you have not two paths here, you have two conditional, you have four paths. Yeah. you have not two paths here, you have two conditionally, you have four paths. And if you add another if statement, well, powers of two being what they are, you don't need that many to get up to a pretty high

cyclomatic complexity. Exactly. I think I wrote a function with a thousand then, once upon a time. I'm thinking switch statements are also another. Switch statements are the worst. And C, the switch statement will show up as a high complexity number, even though the switch statement is usually very clear. You can have a switch statement with, heaven forbid, go-tos, or you can have continues and fall-throughs. There are ways to abuse switch to make it really ugly. Don't do that. If you're doing that, you're doing the wrong thing.

You need to bust that function up into other functions. But there are reasons to have switch statements that have 10 clear, simple branches. Yes, where every branch has a break. Oh, yes. No fall through, no order. You always say, oh, gosh. Yeah, so that's true. And so that will blow your measured cyclomatic complexity out of the water to a high number and

again even though i said we should have nothing greater than five i also say and i'll say it here there is no substitute for professional judgment you know you'll end up with a lot i've worked in a lot of places where process was a big deal right i've worked in product groups i worked different companies and invariably in any large organization you'll come up with a process even not large like five people you'll have a process like right like how do you handle a bug report? That kind of stuff. How do you do, you make a branch and all of that stuff is part of the process. And sometimes the process then becomes king and process then dictates how work is done. And I do not like that. I much prefer that, you know, never substitute process for professional judgment. So in this case where you have a switch statement that's very clear,

you're making it clear in the code, your cyclomatic complexity number might show something large, but that's okay. So the number, you know, the number's important, but professional judgment always trumps the number. Especially the sort of professional judgment that trumps the number. Especially the sort of professional judgment that comes after looking at the code again. Yeah. Not just taking it the first time.

Oh, my God, it worked! And stopping. That's not where you stop, thank you. Exactly. Or you say, oh, my gosh, okay, I figured that function out. It's good. No, no, no, no. Don't do it that way. It really needs. No, no, no, no. No, don't do it that way.

It really needs to be a very clear and obvious function. And detecting that and seeing that for yourself, I think that comes about as a result of your own experience and your experience with other people's code. You need to see the garbage that can come at you and to say to yourself you know i'm not going to do this right i won't do this say that don't say oh i should cut and paste that it seems to function don't cut and paste that improve the world you know that's again you probably heard me say this do the boy scout rule always leave the code better when you leave it and when you got there um that's another one to apply but complexity and I'm certain because I've heard this too, you know, folks will say, well, I just write my code and it works. It's great and whatever. That's wonderful and I'm happy for you. And, you know, I get it. You're a coder.

But if you want to be more than just a coder, if you want to be a programmer, you want to be a designer, you want other people to follow in your steps, you want other people to work with you, you're going to need to do more than just get your code to work. You need to use your code to teach, to pull along other things, to exemplify where you're going, to even give signals to those that might come after you about how to extend it. This is all stuff that's more than just just hallelujah, it compiled, it worked. To me, that's the bottom rung of anything is that it works. That's tough if you need to

ship. How do you balance that? Yep, that's right. And I think to get there, again, this is a professional kind of thing. I think that every one of us has a professional responsibility to make sure that we can do that even so that we can write code in such a way that's automatic you write code in simple you know forms simple expressions that you still ship i've shipped a lot of stuff, but I've never compromised on any of this. I've compromised, you know where I've compromised? I've compromised on documentation

because that's always tough. But you should never let that sit. But don't compromise on any other stuff because first of all, you don't have to because if you find it getting in your way it just means you need to practice your chops a little more so that you can write for example your unit tests while you're writing your code

that's sensible, seriously it will save you more time later, really most of these things, all of these things the reason they are such good suggestions is not just because they're exemplary code or you're teaching future generations. You're really doing this because it will make it better, which will make it faster. It's like driving fast on a curvy road. You go slow to go fast. Yeah, exactly. Exactly. I mean, how many times have you been stuck on some hard problem

because it was a really crappy code, you couldn't figure it out, and your manager's screaming because he's freaking out, the VP's screaming because he's freaking about his bonus.

Everybody's freaking out and you've got to fix it. And you're saddled with somebody's code that they checked in three months ago. It's crap and they're on vacation.

Don't be that guy. Do not. That's awful. And so that's a professional thing. Yes. And people who are interested in more on this particular subject should go back and listen to Jack Gansel in How to Be a Grown-Up. That was an episode where we talked a lot about the importance of professionalism. Going back to code complexity, cyclomatic is one measure. Are there other measures? Are there other ways I can think about how to keep my code simple? There are. This is all very subjective. There was some efforts in the late 70s to, I forgot even what this was called, but it was software science.

And it was about actually applying science, of course, to writing software. Now, of course, you think, well, of course, we're always doing science here. Not exactly. We do a lot of engineering, right? And engineering is basically, not to sound too glib, but it's kind of hammers and mauls. We have a thing and we need to hammer something into place and we kind of get it there. That's a lot of engineering. Some engineering, of course, is more sophisticated. But my point is that the science is really stepping back and trying to understand more about what something is as opposed to how it is.

Engineering is mostly oftentimes about how to get something done, while the science is like, what is it that we're going to do? And I don't think there's a lot of work these days going on in software science, but that was a proposed discipline back in the day. And I think that there are still pockets of people that care about such things. So there are other measures, right? Just lines of code. That's another measure.

People will use that or abuse that in a variety of ways. And I've gone back and forth on that one. I used to think it was dumb because really I could just hit return a whole bunch more times. But now I think about the lines of code and how every actual line of code, I have to babysit. And that code has to be maintained.

And it rots. It doesn't actually rot, but it feels like over time the code doesn't get better. It's a very coarse measure. You can take a look at it and say, well, this program is probably more complex than this one because it has 10 times.

But beyond that, I don't know what you can really say without looking at what the code actually is doing. Right. It is a metric, though. And so that's one of the metrics that you can use to think about your software. It's just how big is it, right? Or

if your software is broken up into modules, how big are the modules? And that line to code, that can turn into things like, okay, I want to measure how my code is tested. Do I have unit tests that actually test all those lines? Well, if I do, that's pretty good. If I don't, there are lines out there in my code that I'm not exactly sure what they may do under certain circumstances, right? If I don't have unit tests to do 100% coverage, for example. So number of lines of code can feed into that scene where you have unit tests or you have some other kind of testing thing that actually tests your code. So another thing, which kind of harkens back to what we talked about originally was naming what is the vocabulary size of your code meaning how many names

are there and everything how many names if in one function let's say that you uh let's say that you have a common type used all over your your, a common type, I don't know, something. And in one function... Int 8 underscore T. Yeah, and then the same one function, you call it X. And in another function, you call the same thing, you give it the name Y. Okay.

Why are you doing that? Just use the same name all the time. And don't use X, by the way. But, you know, if it's a foo. Use I. If it's a foo, always call it a foo. And that reduces the total vocabulary. So someone coming along, looking at your code,

they will see the foo and they'll know, I know what that is. As opposed to, I see X, I don't know what that is. I have to go hunt back up in the code to see what X actually is. These are just things to reduce the reader's vocabulary. And I heard that from you then about, and it was initially in terms of naming the API to reduce the vocabulary, but then you talked about naming all over the code. It made me want to have a tool that would go through and figure out how many

different variable names I used and how many different words in my function names and then calculate them all. Because if foo is my variable inside, I kind of want my function name to be change foo to blah or whatever it's doing. Yeah, you're right. And I do have a tool like that now to do that at Park. But yeah, you're right. And even through that simple thing, you'll find more hints in your own naming that you can refactor your names and make your code even more simple. And that is a great benefit because I don't know about everybody listening to this podcast,

but I've written a lot of code, but I tell you what, I do not drag that code around me, fixing it every day. I like it that other people are working on that code. And the sooner I can get them up to speed on that code, the sooner I can get on to my next thing. And that's a big value for me personally, right? That I don't have to actually curate my code forever. It's readily understandable.

At least most folks say so. It seems like one other measure that's related to cyclomatic complexity or may actually be cyclomatic complexity is your maximum stack depth of an API. Because I've worked with some APIs where I'll break in and I'll have 30 functions on an embedded system and that makes me extremely nervous because I have very limited stacks. It seems like that's more difficult to measure, though,

whereas with cyclomatic complexity, you can look at a function and say, well, I can visually see these paths, whereas with functions calling functions calling functions within an API, without running it, you can't really see. Exactly. This is the problem of the embedded don't want to say this.

This is the problem of the embedded system is that you're in a constrained environment and code that you might just cavalierly, like some recursive function, right? Not going that far, but yeah. It's not going to fly. So yeah, there are fewer tools for that, measuring that, and there's some value there. Well, function mapping will do that.

Oh, Visual Studio will function map for you now. Who writes embedded system code in Visual Studio? I sometimes import it so that I can function map. I'm sorry, this is totally secrets and confessions. But you may not have access to the details of a third-party API or something. That's true. Kudos for using your tools, though.

I appreciate the fact you're not trying to do this in VI. But that sort of battles cyclomatic complexity. You were talking about breaking things into functions. I think that's where I was headed and didn't head there. Chris is, but we can't go that many functions down. Oh, but this assumes that the function you write in a source file is actually an honest-to-goodness call with a return. Many compilers nowadays will figure that out and then line that stuff. That's true.

Granted, in the past, that wasn't the case always, but compilers have gotten better. Turn your optimizer at least up to one. Please. And we should insist that our compilers and our optimizers always do better. So remember, yes, you're writing code for humans to follow along behind you. And in some cases, if you have a particularly old compiler or one that's not too savvy, you will induce, for example, a function call. On the other hand, I've met compilers that are extremely aggressive with inlining and

i'd rather they backed off because well hopefully there's a knob on your compiler yeah turn up or down but yeah that's a problem too so again you'd have to make a trade-off sometimes um you know the professional judgment thing has to step in and say look man i got this much stack i can't call that this is and and then and then there maybe there are other ways to simplify your code to still make it understandable, even though the cyclomatic complexity might be high for a function. Remember, the goal isn't the process. The number is not the goal.

The goal is to make it understandable. The number is just sort of a finger pointing, a bony finger pointing at your code. Maybe you should look at this. Maybe you should check this out. But again, professional judgment should trump it all. So about learning code and learning APIs, I don't know whether it was you or one of your other colleagues

who talked more about APIs need to be fractal in nature to some extent, where in the beginning you only have a few things you look at, and then as you understand those, you can dig deeper and get to more detailed functions. That was probably me, and that was probably in a conversation that was very close to the Agni conversation, which was you're not going to need it or you ain't going to need it.

Yeah, I think that if all APIs just do not sprout from the earth fully formed. You will start with something, meaning you, an individual, would typically write an API. You may have other colleagues writing an API to the same thing and then you will compare notes and compare APIs and sort it out.

Maybe you'll need to get some use. But all APIs should be informed by use, not by guessing. You write the functions, you get your names down, get the model that you want to express it in, and then get the abstraction. So you are uniting the pieces together. And then you write your API. But again, don't add in a bunch of stuff that you think might be cool,

but nobody will ever end up using. Well, that you particularly want to use. Or that you particularly think would be cool. But as you use the API, some things will become very obvious to you. That your constructors were wrong, or you needed some, you know, you have too many assessors, you don't need them. You know, remember, I will say this, adding assessors to an API means that you're giving up control. You're letting something else fiddle around behind the scenes with your bits that may or may not be the best idea.

Because if someone uses the assessors to change the state of your underlying model, does your other function in your API continue to work? If, for example, you have a function that can access or get or set, or set, horrible, your state. Because you want to see what state is the state machine in from the outside. Right. And you write an accessor function that actually allows writing, and now they can change your state from the outside. Yeah.

That might be fine if you want to be able to reset the state, but anything else is likely to be awful. Yeah. And then your API doesn't work. So you've got to be careful with those. And then you get in trouble, because then likely to be awful. Yeah, and then your API doesn't work. So you've got to be careful with those. And then you get in trouble because then you've got a bug report, and then you've got those people out there saying your API sucks.

Don't do that. So watch out for your assessors. That's a bad path. Well, they're essentially windows to global variables. Yes, that's exactly what they are. And I think we all can sort of agree that global variables should be used in moderation and with thought. Especially exposing them.

Hydro-globals. Yeah, if used at all. Yes. Yeah, I agree. Hydro-globals inside classes and call them objects. Yeah, there's that trick too. That's fine if you have a language that supports that. Oh no, not the C++ debate again.

Not debating. Not going to touch that one. APIs are tough to change. You talked some about how you're designing for the future and you are fixed for a good long time for the past with backward compatibility. How do you design flexibility for later? Yeah, so...

And how does that fight with you're not going to use that? Well, okay, so to make it possible in the future, your model and your abstraction will be your friend for that. If your model is simple, it should be apparent that it is simple. And your abstraction should get you just what you need to get something working. You may, for example, provide an assessor, though. Like, get property. You might provide that. Depending on depending on set property i don't depends on your your model of course whether or not you want to set properties but you may provide that you want to provide just what you need though in the in the initial api or the initial

abstraction to allow extension and you may not know all the extensions. So you need to bring out in the API, just the minimum things without, without, you know, without decoration, without anything else, just get the very basic API going. That may not be the API you want to give your users. Think of that as your pre API or your API, you know, for the next API right above that, that's the one you would give to your users, which isn't a bad idea because you could keep that upper API and refactor the lower one as you need to because you need to give yourself some space. So having an inner API and then this outer or upper API

for users to use, you get to play that in the middle. And that space in the middle, if that makes sense, I'm drawing a picture in the air here with my hands, there's an upper API which your users use, and there's a lower API which you, the developer of the API, use. And in between there's an abstraction layer. Yes, abstraction, some glue in there. And that's where you're going to play with the future,

in that space there. Future. So, but are there other important things? I mean, just tactical stuff like versioning? Or do you try to keep versions out? If you have a version in API, okay, you're always going to have a version in API. Whether it's yesterday's build or today's build.

There's a version implied that, oh yeah, I changed that. It's new. It's a new version that, oh yeah, I changed that. It's new. It's a new version. You're always going to have that. I think that you need to decide if you want to have new versions of the API being so starkly different that your users will have to re-code, if not recompile. So you need to make that decision, right? So some things are worth maintaining backward compatibility, but at some point you may have discovered in the use of your own API that it is so wrong that you need to make a big shift in the model

or its abstraction. And as a consequence, the future API will not be backward compatible. You need to indicate that somehow in the API. Oftentimes, you don't need to indicate it as an API call. Maybe it's just the library name's different, right? But certainly being mindful of versioning is good when you're thinking about trying to think about what might happen in the future. How do you feel about things like, if you have a sophisticated means of dispatching to an API through whatever, dynamic linking

or some sort of dispatch table, I know they do things like this on iOS where you're allowed to say, well, does this particular API exist? Does call exist? If so, I'm going to do this. Otherwise, I'll take this other path, which is backward compatible. So you end up littering your code with all kinds of,

do I have this call? Okay, do it. That seems to be kind of an unfortunate consequence of maintaining backward compatibility, but I don't see a way around that when you have a general use API like that. Yeah, and the attempt there, of course, is to provide future extensions without really having to change the API.

If you can ask the API, hey, what do you do? If you could ask every API what they did, every API would work, right? So I appreciate what they're trying to do, but yeah, it makes it hard because now you've got to put in your code all this query stuff. What's under there? What is what am i dealing with that's a hassle um you have to decide okay i'm going to break off at this point and stop asking that question and i'm not

going to support the older versions of the api exactly and this also presupposes that you have a runtime environment or a language that even lets you say that, right? You're going to do this with C? You're going to get reflection out of C? Right. Yeah, that's going to be hard. And, of course, get that to work on Linux and Mac OS and Solaris and all these guys. It's like, oh, that's not going to work.

So, yeah, actually, I don't do that. I make a hard demarcation. You link with this library or you link with that library. And if it doesn't link, you need to recode, right? It's just like that. I've never really had to get involved in an API that was so general purpose that it was shipped to the masses that I was compelled to do some reflection kind of thing. But yeah, I could see that coming up.

So you've written reports for PARC, probably other places, on coding style and software design. What were important parts of those that we haven't already covered? Acceptance. Acceptance, yes. Everyone's always telling me that's important. People don't like to be told about style i like to write my code the way how do you avoid religious wars with bracket

placement uh seniority there is a little even that doesn't work you can just say look either you're on or off um it's it's tough and of course you have bracket placements like i don't care just as long as everybody's brackets in the same place yeah and you know it's the case too that we'll end up where we are now everybody conforms to the style it's cool sometimes somebody will come in internal come in and do something different you know what i have a thing that you just squirt you squirt it through the the free formatter and you're golden, right? We also score it, right? So when code goes in, we have tools that score it, compare it against the style, and so forth.

So things pop up. We have a dashboard that shows this over here is in trouble, whether it's unit test coverage or cyclomatic complexity or vocabulary or style or whatever, we have a way to see that this is a potential trouble spot over here. And for us, a trouble spot is that the code's hard to understand, measured by cyclomatic vocabulary, unit testing may be iffy, whatever, or style's iffy, because we are trying to make code that other people can learn from to build their systems sort of it's a reference implementation but yeah it's the case

you know it's like unit testing too it's like not everybody's at one with unit testing and then you'll see somebody write unit tests and everybody written unit tests before it's like what is this so there's some training that has to go on. And yeah, there's going to be naysayers and so forth, but people need to figure out the importance of whether or not the code is to be maintained by someone else and then understand how their style may or may not affect that other person because that's what it's about.

They may like their brackets one way and but you know everybody needs to write the same way so that the code is uniformly understandable it's a team sport people it is and if you don't like that don't be on a team that's cool so these tools you mentioned they are park specific they're not freely available are they well they're kind of coming out to be freely available so so park has um where to pick this up so we have the ccn project at park and in that project we have uh software that's available the software is available right now it's it's um you have to license the software but there are freely available versions of the software already built. And so you can get the tools for unit testing in C, as well as all of these dashboard scoring things, in the Longbow distribution of that CCN package. So Longbow is the tools I have that I wrote originally, and I've had some help since then from some other colleagues to build these out. And all of those Longbow tools are in that

distribution. And you can get that for free. It's the binary distribution of ccnx.org. And there will be a link to that. But the ccn.org is really focused on the content-centric networking and the API and the reference platform. And so I assume the documents for those are all very reasonable. Are the documents for your tools ready for people to go and make their own? See, that's a dodgy question. Are they ready? Yeah, I'm going to say they're ready. And you know,

if you get them and you don't like it or you think something should be more clear or you don't get it, tell us. Because that by definition of our own process, that's a bug. So failure in the documentation or something like that is not an RFE. It's an actual bug.

Documentation is critical to all of this, both the tools and the API. How do you... But documentation is hard. You even admitted that that might be an area where you would give on if necessary occasionally. Under time constraints.

I would not give on it under any principle other than time constraint, and I would need to necessarily buy into that time constraint. Just because somebody's freaking out doesn't mean that we're going to throw documentation out. How do you make and keep up good documentation to go along with your pretty code?

Well, so one thing is to make use of, okay, here's another thing that Java brought. That's JavaDoc, where you can actually write comments in the code, right, that are extracted and used for documentation. Kind of like Doxygen? Exactly. Doxygen is one of them. JavaDoc is the one for Java, but Doxygen can do it for several languages.

I use Doxygen. It needs some help a little bit to be as as nice as it probably could be but um it worked it does fine and so we used oxygen and park for all of our c code um knuth had some work on this illiterate programming stuff that he talked about in the 80s and 90s uh that's still relevant although we don't really have any tools to do that um at park right now not an easy book to read. No. I mean, that was... Probably not.

It's probably not that accessible to people to get that. And some of the concepts, even in literal programming, weren't exactly what I'm talking about. I'm not talking about writing your code in such a way that it can be printed out and used as documentation. Although that would be cool. Not going to happen. No.

Not now. You're not going to take C code and print that out and say, I mean, yeah, somebody can say, hey, read the code. Read the code. There are no comments. There are no comments. No, no. That sounds like Linux.

So, yeah, we extract it with Oxygen and make an online version of it so you can get it from there too. And when you download the CCN distribution, you get the documentation along with it that you can get it from there too and when you download the the ccn distribution you get the documentation along with it that you could host yourself but that doesn't that doesn't imply good documentation i've seen plenty of oxygen nothing implies good yes that's true you've seen attempts to make doxygen stuff and everybody just copies the template from function to function and puts in the function name and the parameters and nothing useful. Doxygen will allow you to easily extract individual API documentation, but it doesn't give you

the big picture automatically. Somebody has to write that. Yeah, someone has to write. It's not, again, not a substitute for, you know, some sort of big picture or an overview or a book, you know? But it's certainly better than having to go through an undocumented set of code and then write all that stuff. Look at the.h files, right? Something like that.

It's awful. Other than literate programming, which I only mentioned because I picked it up recently, thinking, oh, you know, I'll read this. And I got, like, page 12. And I was like, this is not worth it to me. I'm going to go find a nice O'Reilly book that is written for humans. Do you have other books or blogs or resources you recommend

for people interested in good code and API design? Yeah, there are a lot. Part of what happens is that we'll bring in interns every few months. And if they hook up with me somehow, I will steer them onto a set of books that I think everyone should read. I have to say that the books that Bob Martin writes, Robert Cecil Martin, he generates some controversy. controversy that's fine i don't care about that but i have to say the things he does say are spot on about about being professional about the things that you need to do as an individual to participate in the team and all those things they have well worth reading well worth listening to and if you're one of those people who thinks everybody

else is wrong you you need to read Bob Martin's books. Yep, exactly. It may be that they all are wrong, but you may be able to convince them of that without being a jerk. Yep, that's an important part. Again, if you want to be in a team, you're going to need to do that. And if you don't, don't be in a team. Do not do it, because other people don't care and we've created a generation of basement zombie coders

who will not absolutely will not join teams anymore yeah well there's no I in team I'm not in team there's a joke about the I in team which I'll tell you later do you know what you call a pirate without an I?

No. A prate. Oh, I see. That's right. Oh, I'm sorry. We're doing a podcast here. Ah, yeah. Dog fooding.

Why does something so good sound so disgusting? Well, I don't know where that phrase came from. That's true. But of course, it has a great effect. If you, let's say, I'll tell us, this is a war story. So I worked at Sun for a long time. And I worked in and out of the lab. I was in the lab and then the product group and back and forth.

I did lots of different stuff. And we were working on a project that was very popular, but we were very stealthy about it. And it was just kind of, in the beginning, it sort of just limped along a little bit. It was a networking product, so we had to pass packets through it. And, you know, we would get them through and it just was sort of kind of a toy for a long while. And then some of us decided, you know what,

to make this real, we need to just simply take the whole group and put the whole group behind this thing. So if it didn't work, you had no internet access, you had no email. You had nothing. And that was a big shift in the rate of change, improvement, how quickly it took to solve a problem was just that simple move. That was dogfooding, right? We were eating our own dogfood. As weird as that sounds, I don't understand that phrase either, but this is what I understand it to mean. And it was extremely valuable for the project because the project probably was finished a year sooner than we really anticipated. That's something that was really easy to do with networking, it seemed like.

We did that at Cisco, all the projects. Put all your personal use behind your code. Yeah, absolutely. Stuff gets fixed real fast. Stuff gets fixed really fast. And so there's there's there's great value in that you know if you get some controller control something that matters to you with it and uh or even better control something that the whole group cares about and then if it

doesn't work you'll hear about it right quickly often and sometimes with great anger yeah it's a funny thing too at park Park, you were there. We have the lunch bell. And the lunch bell, as goofy as it sounds, is really a bell that's connected to the network. It's connected simply with, I think it has an Arduino and it's got some stuff. It's a bell with a clanger.

And that thing goes off every day at 1130. And if it doesn't go off there's something wrong and people notice that's not exactly eating our dog food but people have come to be when that bell rings it's time to eat lunch and uh when the bell doesn't ring our lunch starting process is much more jerky right and people notice and one of the things about lunch at Park is that it was a team activity. Yes, it's a team activity every day. I realized I was doing it wrong when I would just wander off and have lunch whenever I felt like it and meet up with people or not.

I didn't really care. As a contractor, I don't always engage in the team activities. But at Park, it was very much team activity. Yeah, we definitely live together. That's true. Back to the APIs. You mentioned working at Sun. You also worked at Oracle, right?

I did for a short while. After Sun was acquired, I worked for Oracle for a while. What about APIs and legality? Did you hear about that oh yeah oracle versus google where uh the apis are are copyrightable but then that got partially reversed so maybe they it was just the function signatures yeah it could be copyrighted well it was they were not copyrighted and then that got partially reversed. So now it's in the air. Okay, first of all, I'm not a lawyer.

Neither are we. And I'm not speaking for anybody's interests. I have an opinion. I think that if your API is copyrighted, to me that's just a lock-in to your API. And I don't see a benefit to your customer. I don't see that you're offering them a benefit. The only benefit you're offering to them is that you're code. And some people will say, well, that is my benefit, is the code. But somebody else can come along and make a different API. And now if the other people convert to their API,

you are definitely hosed. I think common APIs are very valuable for that. Then you can actually compete on features, not the API. I mean, give me a break. This is my opinion, but I see no value. Arguing the other side, just for the fun of it, we've been talking about how hard it is to build a good API. How much thought and development and time goes into thinking about how to build models and explanations

and function names and documentation. If I put all this effort in and then somebody else comes in and rewrites the underpinnings. That's a lot of effort. I feel like my customers maybe should be tied to me at least for a while. Then copyright your API. Oh,

all right. Fine. Well, I just don't, I can understand that argument. I think that, you know, some,

in some point, there is a cost of doing business, and perhaps that is a sunk cost, the cost of developing the API. If your API is so popular that other people are willing to try and participate in it, then I think that's a good thing. But yeah, if you're the sole provider of some API, I don't know.

I'm not going to use you. That presupposes there can really... I mean, yeah, I think it goes back to functionality versus some names. I mean, because you can get into situations where you allow this and people backtrack and now somebody copyrights the POSIX API or something else and now you're in a situation where very common names are all taken right.

That's true. You're right. There's probably a slippery slope here. I don't know. Again, I'm not a lawyer. But copyright has certain things that make it copyrightable. You can't copyright. Did Java do that beforehand? I didn't see that part of the case. We're talking about whole function names. Yeah. And I believe the whole API itself.

Well, what Google did was they re-implemented the Java API as part of their virtual machine on Android. So I don't believe that anything part of the case was about code. No, no, it was all about the function names. Yeah. And I would say that those are hard, although I kind of agree with Glenn that if you've done such a great job of this and somebody is going to come and write other code for you, it might be better to be flattered,

even though it might make your company annoyed. I'm also not convinced that just because something is hard, you have an automatic lock on it. No, I can pretty much guarantee you don't, speaking from personal experience. Okay, well, it sounds like we're all pretty much in you don't, speaking from personal experience. Okay. Well, it sounds like we're all pretty much in agreement on that one. Going back to designing APIs and all the advice you've given,

what differences do you think we should be doing when we are designing APIs versus modules, internal modules? Are they essentially the same process? Or do you think there is a big difference? Yeah, so earlier you mentioned this discussion that you're unclear where it came from, and that's the fractal API. And I know that discussion.

So, yeah, so you're writing a system for which it has an API that other systems will use, and you will have internal APIs. That's the fractal API. So your modules inside, each one of them will have an API. You should pay attention to each one of these modules and their areas of concern and not leak out stuff, because that still will make your own code hard to maintain if you don't

do that. So everything below your user API, to maintain if you don't do that. So everything below your user API, so to speak, is still an API. And it may be just you or you and your colleagues, but those APIs are just as important in the model that they represent and the abstractions that they provide. Yeah, so definitely pay attention all the way down. I agree with that. And I think we don't often, sometimes we write an API for users,

but we forget that our coworkers are also our users. Yep, exactly. Or you, your future self may be a user of your past self's code, and you'll be cussing at yourself if you mess it up or particularly you haven't designed for the future. Speaking of the future, what new technology are you excited about? You've gotten to work on some really neat stuff

from the past and so I'm curious as to what do you think? What should I invest in? No, no, no. What new technology are you excited about? Well, I have to say I'm pretty interested in the concept of drones and data acquisition through drones. I most recently kind of hooked up with some folks

that were talking about putting drones on Mars. And rather than put a rover that squirrels around, you have drones that move around, probably get greater range. I think that is an interesting project because there are networking elements there that need to happen. Relays, probably a satellite to relay information as it comes, all kinds of stuff. I'm very interested in that. I did some work before on some distributed hash table communication mechanisms. I could see such a thing working out on, you know,

on some other planet where we were not there. We have to get communication devices up. So that's something. I don't know if you can invest in that right now. You know, it's not you can buy stock. But I think that this is something that's got my attention. I'm not that interested in particular on sort of the we have this sort of

current trend in social media stuff it's not that interesting to me I think it's probably going to fade I don't really know but I think but I saw you made a twitter account I did make a twitter account I haven't done anything with it

but yeah. But I think this other stuff is definitely going to be interesting. Also, same sort of things for ocean exploration. I think that is going to work. We're going to have water drones. There's so many new ocean exploration things that are just fascinating. Yeah, I think these to me are the things that... The stuff I'm doing now still gets me up in the morning.

I still run out to my truck getting my pants on, but someday it's going to be these other things too. Yeah, I would go for ocean over Mars because then I could visit it. Well, maybe. Maybe. I don't know. I don't know that we'll get to see Mars, but if somebody asks, maybe we'd consider it. Chris and I don't travel well, but I don't know.

Maybe I should wait to see the Martian first. Yeah, maybe. I hear it. You may not be encouraged to go. No. I read the book. It was not encouraging. Yeah, exactly.

Yeah, but I think those two things, any kind of thing that basically expands our understanding of where we are and what we're doing here, I think that's worthwhile. Cool. Chris, do you have any last questions? Just something I thought of when we were first talking in the beginning.

When you're talking about designing APIs, there's a formality to it that i think i haven't seen people use recently uh and just gets me thinking there's a lot of computer science and the kinds of things you learned in introductory computer science about languages and formal languages that we don't apply really unless you go off to make languages or compilers and things like that uh and i just wanted to kind of to hear what you thought about how to kind of reincorporate that back into normal day-to-day engineering um whether it's go read this or make sure you you know find applications for some of these concepts or reapplications for these concepts that you've lost?

I guess I'm kind of ticked off at sort of the current state of education and computers and computer science and stuff like that. To me, anymore, it seems that students come out having just kind of gone to trade school. And that's okay. I mean, to a certain extent, it's a trade. But not a lot of discipline, not a lot of appreciation of the fact that there's still an art here that you must practice. And I think that you're not going to go get, you know, like an undergraduate degree or a graduate degree and be guaranteed that you're going to come out of there

knowing what you need to know without a lot of practice and experience. And we're just not getting there, right? This kind of talk doesn't happen very often in the undergraduate arena, right? This kind of talk doesn't happen very often in the undergraduate arena, right? It just doesn't. And I think a lot of people come out of there thinking that they're going to change the world. And they may change the world, but they're not going to change the world with what they arrived on graduation day. They're going to have to spend more time

developing that formal perspective and of course depending on the school you go to those perspectives can be taught and you maybe get a better appreciation for the scientific aspect or the scientific method of applying the scientific method to actually doing this kind of work in other cases you know a lot of people aren't um i don't know if i'm touching your question exactly but i exactly I think that's about what I was wondering there is some formal stuff here that really is sort of I don't know

I think it gets lost in the day to day, sprint to sprint make this, make this, ship it, everything should be shipping all the time and that really discourages I think it discourages thought, to be blunt. Definitely, yeah. I definitely agree. And, you know, I'm fortunate, obviously, that I work in a place where it encourages thought.

And I've kind of, in retrospect, I've always worked in a place that encourages thought, but I've seen other folks work in places that do not. You know, what are you thinking for? You know, Get this done. Quit thinking. Start typing. Yeah. And those are bad places, guys.

Find another place. Because you're not going to grow there. You're just not. You should expect and insist on better. Because if you did, and if we all did, then it would get better. And if it was all better, we would make much more progress. It is hard for new college graduates, or even people in college now,

to hear you have so much more to learn after you graduate. You mentioned Bob Martin's books, and we mentioned Noose a couple times. What other things can people prepare? Or if people are early, well, you know it doesn't have to be early in their career. What other things can people do to gain this perspective? The very first thing you have to do is you have to care. Yeah, and that is the hardest one. You know, if you just can't get up in the morning and think

about writing some other piece of software or i don't know i'm making that up there's other things you could do just because you wanted to if you really don't do that and and you have a job that you go to and you do it but you don't really envision yourself doing it otherwise it may not be what you i mean it may it may pay the bills and you may be okay but if you want to go past that you're really going to have to and i think that this is not the only profession that's like that that you're going to need to continue to educate yourself um you know what what you learned in school in the 90s is not going to necessarily apply now some of it will mean, a linked list is still a linked list.

But these are teeny things. The whole discipline thing, the whole idea of getting your model and abstractions right, really, this is a practice thing. This is not something you're just going to sit down and somebody's going to point to something and say, do it this way. You need to come to this on your own.

You need to see it for yourself. But I do think reading other people's code. Oh, yeah, that's true. Reading other people's books. Yes, yes. Getting their perspective in your head helps you form your own perspective. Otherwise, it's a long, long road. You can do it, but it's a long road.

It's hard to invent all this stuff yourself. Exactly. It's a lot easier if you wonder, well, is there a better way? Somebody says yes, and you see their better way and think, no, there's actually one better than that. Yeah, exactly. You can improve upon it if you know about it. Well, I think we should wrap it up. Do you have any last thoughts you'd like to leave us with, Glenn?

Well, I think we just actually touched on it. I thought about this, and I was going to say that when it comes to all the software, writing good software, making it matter, at work I'll often say to someone who I think is not doing that, I'll say, look, I was promised flying cars

by now, and we're still messing around with VI and make. So let's get some perspective here. That's and make so let's get some perspective that's distressing let's get some perspective and uh yeah i think people need to care i think that people should expect um to invest in this like any other reasonable profession you need to keep up with what's going on i think you you need, not everything new is good. Keep that in mind. You need to make your own professional assessment about that.

I think that you need to take the time to expand your own skills. And I think that you should insist on better from not only yourself, but your colleagues, your employer. Things should be better. And if they're not, move on. That's all I can say. It is a team sport. And not only coworker to coworker, but your coach has to be part of it too. Yep, exactly. And I'm happy Park has such a very nice way of doing that.

But for the rest of you who don't have good coaches, go find some. They're out there. Lots of friends, too. My guest has been Glenn Scott, principal scientist, researcher, and principal engineer at Networking and Distributed Systems in the Computer Science Laboratory at PARC. Wow, does that all fit on a business card? No.

If you want to know more about content-centric networking, check out ccnx.org, which will be in the show notes, or listen to show number 75, that is End Up in a Puppy Fight, where I talked to Glenn and Nacho about CCN and what it was. Although I seem to recall there were some tangents there. It was one of the ones that I recorded on my own and it shows some. So be sure to send a big mental

thanks to Christopher for all that he does with producing and co-hosting. Just send money. They're going to ask us how, you know. If you would like to send an actual thanks or other note to us, show at embedded.fm or hit the contact link on embedded.fm. And of course, thank you for listening.

We do appreciate it. I think final thought this week will come from Edward Tufte, which is a good book to read if you haven't already, Envisioning Information. And the quote, Clutter and confusion are failures of design, not attributes of information.