That's really where it all started and interestingly, as we're looking at the 10-year anniversary of writing -- authoring the Agile Manifesto, this was all kind of happening around the same time. So about 1999 or so, my business partner Dave Thomas and I were writing the Pragmatic Programmer book and like most projects we started on that. We didn't intend to go write a book other than -- let alone a book that would still be popular 10, 12 years later and have been still topping the charts that that wasn't our intent at all.
We were actively consulting, going out and seeing customers and realized that a lot of the practices they were doing to develop software were quite poor. They simply weren't doing it the right way. So we started it and we had our little stories that we could tell from our own individual experiences and we think you should do it this way and here's this nice story, this nice anecdote, you should do it that way. And we thought, we should write that down. We should just write like a little white paper, something to give our clients so they'll be able to develop software better.
And about that same time was when Kent Beck was writing the first Extreme Programming Explained book, the XP book. We both ended up with the same publisher so we got to see each other's drafts and we're kind of discussing it and those books came out in the late '99, 2000, somewhere in that time frame. And that was when the sort of grounds fall started coming up. There was a lot of folks interested in how can we develop software better. Alistair was in on it. You had the Scrum folks, you had the XP folks, you had us. You had all these groups saying, hey, maybe we should talk about this idea of lighter weight methods, something to do. And that's how the first meeting in Snowbird came about and we authored the Manifesto saying, all right, let's do it this way.
It's been interesting watching everyone's recollections of how the writing came about and how we came up with these values and these principles, all that sort of thing. And I'll add my own recollection into the pile because many of the folks who were there had a particular position they were putting forward. You had the Extreme Programming folks who were putting forth their codified ideas as XP, the Scrum folks with their thing. You had DSDM from there. You had Alistair and his Crystal methods used, working on Jim Highsmith with his adaptive software developments. So you have a bunch of these folks with their different methodologies coming forward. And then you had those of us who are sort of unaligned like Brian Marick, possibly Ward, Dave, myself were -- we were -- Dave and myself here, we were there really to kind of promote and defend the interests of the average developer.
We're not methodologists. I have to say actually on a wider scale, we're not programmers either, none of us. We're folks out in the audience, folks up on stage, we're not programmers. We're not methodologists. We're not evangelists. We may do all of those things in order to get something done but first and foremost, we're problem solvers.
That's what we do in our industry. We go out and solve problems. So when Dave and I first wrote the Pragmatic Programmer book, the overall problem we were trying to solve was what kinds of techniques, what kinds of philosophies, what kind of approaches is should you take to create software more efficiently and more effectively. And that's where we got this whole notion, sort of Pragmatic Programming -- not following the kind of mindless dogma that says, well, you have to do it this way because that's what you learned in school or that's what this book told you to do or that's what this method tells you to do. Sometimes, some or all of that might be correct but you can't just blindly do it for the sake of doing it.
You need to know what you're doing. So that was kind of how we came to be involved with and be interested in what ended up being the Agile software movement. It was looking at a more pragmatic approach saying, okay, well, the way we've been doing it as an industry hasn't worked.
It's not working. Maybe sort of traditional plan base approach to a development project does work for maybe -- I'm guessing here -- 5% or 3% of the projects that are out there and those are the ones that people write the textbooks on and give the courses on but that's not the real world. That's not what the average developer who we were trying to champion. That's not what they run into.
So that's how we kind of came to that with the idea made quite simply that, all right, let's find out what does were. And better yet, teach you as a developer to recognize what you're doing, whether it's working for you, whether it's not working for you and what you might do to change that. And to continuously improve and get on the right path. And that still kind of a -- I don't see it's a hard sell but it's a hard thing to do. So a couple of years after that, we started the Pragmatic Bookshelf to further these same ideas. There's more good stuff out there that Dave or I could personally write books on. We've got a lot of friends who know what they're doing, know what they're talking about, we'll publish their books. Our goal with the Bookshelf has always been to publish books that we would want to read.
So we get tons of proposals every week, some of them are really interesting, some of them less so, but even for the really good ones, it might be a great topic. It might be a great author but if it's not something that we would want to read as developers or think you would want to read as a commercial developer, we'll pass on it. We'll say, take it to one of these other publishers that would be happy to; publish it yourself; do what you want to do but that's not our mission. Our mission is to do what will help the normal developer in their day job, help their career, help their projects along.
Yes. I wouldn’t necessary say that’s all about it but it certainly has a very strong component in it, taking pride in your work and having that kind of craft approach that it's not mass production, you're not just slapping it out as the same thing you did on the last project because it's not the same thing. Each project is different, each context is different. You have to be aware of those nuances but you still have to be able to do -- you need an environment where you can do the best that you can and really craft a well-oiled machine that you’re building there.
So yes, we were definitely along that -- In fact that's actually where people sometimes ask, well where did you come up with the name Pragmatic Programmer in the first place. And back in slightly before that time period, so mid- to late '90s, one of the hotbeds of discussion in the world was the comp.object Usenet newsgroup. Newsgroups! Google for it if you don't remember. And there was this raging discussion on it. There was this one fellow whose name mercifully I don't recall all these years later. But he railed against that very idea of Software Craftsmanship saying, no, no, no, it's not a craft.
Craft is like little old ladies gluing macaroni necklaces together or some foolish metaphor like that. So it's not craft, it's an engineering discipline. It should be rigid and provable and all these very stiff things like he perceived engineering to be. Of course, engineering doesn't actually work that way either, but he didn't know that. And he actually took offense at being Pragmatic at having a craft approach. He was almost in favor of a dogmatic -- these are the rules, you do it this way and we just couldn't let that sit so we figured out this is the Pragmatic Programmer, this is the pragmatic approach and we took that as our mantra.
Well, that I could talk about. There's -- it's interesting in that everything comes in cycles and comes and goes and things that were passive for a while suddenly are hot again and things that are hot are cooled off and it's always a cycle like that. There are things I'm personally interested in and I can see where our sales are going right now and say, wow, these kinds of books are doing really well. The bloom is off these. I think for some of the newer stuff certainly CoffeeScript has become a very hot item. And that's relatively new. I discover some people haven't even heard of it yet.
So if you haven't, CoffeeScript is -- it's a language. It looks -- I can't say it looks like Ruby but it's sort of like it spiritually descended from Ruby is probably a more accurate thing. But it compiles down to plain old JavaScript and you can run it in the browser, you can run it server side using Node.js or something like that.
And its purported reason for existence is JavaScript is everywhere. It's what holds the web together, everyone is using it. But as languages go, it's not a pleasurable experience. It's lacking some things that people would like to see. So here comes CoffeeScript which makes it a much more pleasant experience to work with but with no loss in speed or applicability. You can still run it everywhere JavaScript runs which is everywhere. But now you've got this much nicer environment to be able to create it in. And we were quite fortunate to be early in on that process and basically the day that they announced that CoffeeScript was now a part of the canon of rails. It would be in the rails stack -- we released the book.
And here's the book on it, ready to go. We had it out in beta as an e-book that very day and then followed it up with it in print, I think something like four or five weeks later. It wasn't very long at all. And that's been -- yes, that's still very popular. People are like, okay, let me look at this CoffeeScript thing 'cause that looks interesting.
Certainly HTML 5 in related --in all of these, picking up a lot of interest. It's not fully baked yet, I don't think but it's certainly -- all eyes are on that like, okay, this is where we're headed now. It's not your father's HTML.
Things are moving along. And that's kind of interesting because historically, we don't really sell a lot or do a lot with the kind of -- I hate to call it lower level but those were the markup level books for CSS and HTML. Some of our peers in the publishing business specialized more at that level and do a fine a job at it. That really hasn't been something our audience has particularly cared about or been interested in and that's changing. That's a hot topic now for our audience, for our folks. They're much more interested in that as the capabilities come along and you could do more with it. I think it's now much more of an interesting prospect.
5. Yes, right. Is that going anywhere?
I think so. The whole Arduino world is very exciting to me personally because I've always enjoyed tinkering with a little bit of electronics. I don't have an EE background particularly but it's a fun thing to play with. You get a chance to write software that actually does something. It doesn't just sit there and make pixels get brighter or darker.
6. People are actually building things with these little microprocessors.
Phenomenal things. In fact, yes, just the last issue of the PragPub magazine which you can get free online at pragprog.com/magazines, not hard to remember, our latest issue Mike Schmidt has this article on how to build, like a traditional video game that hooks up to a TV set and you hook in a Nintendo numchuck controller and you're sitting there doing like these little Tron racing cycles on this Arduino board. It's an awesomely fun toy.
I've used it to build -- I built a music accessory I like to play with. I wanted to build my own foot pedal that just sends out mini messages to control different things. Like I bought some switches and drilled a hole in a piece of metal and bang, I got this beautiful foot board. There's people building all kinds of stuff out of them and I just heard recently that now even RadioShack, who pretty much had stopped carrying wire at this point, it’s just cell phones, said they are going to start stocking the Arduino and related supplies.
So that to me is very exciting to see that kind of resurgence in people being interested in cobbling together their own whatever, their own devices, their own things. My next personal project for that we'd like to do a big Halloween display every year. And last year we introduced a couple Arduinos to make things jump and scream and these sorts of things one does with Halloween props. We're going to do that even more so this year.
I think certainly, at least in part. We might probably explained it differently or have a different -- a slightly different angle out but I share some of his frustration and some of it is just a natural evolution that this is how things unfold when you expose them to the masses. It doesn't quite always go the way that you hope it would. But there are some fundamental things that are not disappointing per se but really wished it had gone another way.
One wish -- and we alluded to this a little bit in the Park Bench last night when we were talking about what you do think about the state of Agile today? On the one hand, it's really wonderful to see such widespread adoption of the sort of low hanging fruit, the easier practices to adopt things like interest on unit testing and now expanding that into behavior driven development and more user acceptance testing and wire applications to that.
But a whole a kind of testing idea mean has really taken hold and that's really good to see. It's good to see people at least trying to do things like some of the less of palatable things like perhaps pair programming, which is really very effective on many levels. There's actually cognitive research that shows the benefits of pair programming. It's not just some weird funky thing to do. There's real brain science that this is actually helpful.
And various other practices like that. It is great to see those adopted. The downside of that -- and this is where it gets a little frustrating -- there's this sort of pervasive attitude that you do Agile. I'm doing the practices, I'm doing Agile. And that's great but that's not what we intended. We wanted people to be Agile.
We want people to be able to reinvent what they're doing as they're doing it to solve problems in context. And that idea of Agile being constantly evolving and adapting and changing itself, that we lost along the wayside. And again, it's not that I'm pointing fingers at us or at the industry or at the crowd, that's just how these things go for widespread adoption. But in the last couple of articles, I occasionally write a column in the PragPub magazine and I tackled some of these things about, this is what we meant back in the day about Agile and Agile adoption and these are things we kind of lost sight of. So the fact that it is supposed to constantly reinvent itself, you look right now, what practices is anyone doing today that are brand new or that have evolved out of the stew. Very few.
There've been a couple. There's the planning game, there are various things here and there. But by and large, it looked like the original 12 or 13 XP practices and they've largely continued to unchanged in 10 years.
And to me that's a bad thing. It's 10 years. We should be doing something completely different by now, better hopefully. So I can definitely see things not going the right way there. You get -- as with anything you get this idea sort of sloganization of terms. People will say, oh, yes, we're doing story cards or we've got this, or we're Agile or whatever the buzz word is with no understanding of why they're doing it or what they're doing but they carry the brand name around and think that's good enough.
So that's kind of distressing and certainly not going the way that we'd like to see And I think I can speak for all us when we say what we really want to see is professionals in an environment where they can increase their skills, where the organization, the environment supports them gaining more and more skills as they go along getting better and brighter, working better and brighter together as a team and being able to invent and come up with creative solutions to the very real problems that teams and organizations face and be able to do those and build on those and go forward.
And there are some cases where you can see that. Now and again, I'll go out and speak to private companies and get around to see what folks are doing and there are some examples that are out there but there's still much more rarer than I'd like to see. I'd like to see that be the norm not the, wow, look, somebody got it right.
I think it will come in time. I think probably everyone, audience and authors alike sort of underestimated the amount of damage we had to overcome first. And there are still an awful lot of things that within the community, we sort of have the right idea of what should happen but we're up against accounting principles. We're up against bits of organizational dynamics that we have no control or influence over that might be completely arbitrary but there they are.
So I think we probably underestimated the amount of all of that we had to kind of overcome to begin with. But I think on a hopeful note, I think we're getting there. I am -- back when we're writing the Pragmatic Programmer and all of these was kind of gelling together, one of the things I'd asked during a lecture if I had say, 100 people in the audience, I'd say, please raise your hand and tell me honestly if you're not using version control on your project.
And at the time I get maybe 30 people in the audience. Maybe a third of the audience would raise their hands saying, no, we don't use any kind of version control for our code. We got one big shared disc and the last one in wins.
Now, these days, I'll ask it, here we are in 2011, I'll ask it and there are still people who raise their hands but it's maybe three or four or five in the back and they're cringing 'cause they know that this is a bad thing. So you take such a very obvious and simple and almost take for granted practice that you got some kind of history mechanism in place and know e-mailing the source code to yourself so Outlook keeps a copy does not count as version control. Although I've heard that as a response: Well, does e-mailing it to yourself count? It's like, no.
Sorry, it just doesn't. So here's a very base level hygienic sort of practice and we've seen much greater uptake on that now. Unit testing, as I say, that was a very hard sell 10 years ago. And in some place it's still a hard sell trying to convince developers that this is not a testing practice. It's a coding technique. And that's part of the problem again, too. I think we had the wrong name for it. If we hadn't call it unit testing, if we called it something else, anything, call it Fred, call it XYZZY, whatever. If we called it something else, we probably would have gotten more attraction earlier. But as it was, people are like developers are testing, oh, I don't do that. That's Sam's job.
That’s QA, that's not me. And that's not what it's about at all. So the fact that that has gotten such great attraction is really quite heartening and that really has gotten, it's almost oversold now. People are like, oh, don't worry. We have a test for it. It's like, yes, you still do need to worry. So there's a little bit of over exuberance there almost but I think that starting to self-direct as well. So, yes, on some fronts that's great. We've seen this kind of great adoption where we're still lacking is the, okay, sit back, think, reflect, do it better because necessarily that's harder. You actually have to think. That's the hard part. So we're still waiting for that revolution to go.
Sure. And this was an article I did in the most recent, I guess the August issue of PragPub magazine. And it was neat so -- as with many things, I'll be reading something completely unrelated, some news article somewhere or some book and it'll strike me, oh, you know. That's really -- I can get an Agile lesson out of that. There's a metaphor in there. In this case I was reading Tina Fey in 3rd Rock and -- 30 Rock, and SNL and in her autobiography, she was talking about doing theory of improv and giving the rules for improv and I could just imagine a bunch of developers thrust in to do an improv session, right? One of them comes in and makes a statement and then the next developer says, no, that's not it. And then the dialogue stops. When the first one says, well, here we are on the moon. The second developer goes, yes, and the dialogue stops. And kind of I feel that's where we are now. It's like somebody comes out with a great idea and the other players are like, yep, okay. And that's it, the action stops.
Now, what she says about when you're doing improv is clearly that's not the response. Somebody makes a statement--well, here we are on the moon--you have to say yes. You agree with them. You don't say, no, we're not. We're actually in Paris. Well, that doesn't help.
10. So agreement is important.
Agreement is important. So you start agreeing and then you have to advance it. So, yes, here we are on the moon. And look, what was that? What was that shadow I just saw beyond the crater over there? Okay, that's interesting. You advanced it; you've opened up a possibility. Now, they can jump in and leverage on that. Another actor can jump in and leverage on that and you’ve got forward motion going because you’ve agreed and you’ve augmented. And a lot of places, we don’t even get the agreement. It's like, well, we're going to put para-programming. No, we're not. Okay, now you’re dead. So first, agree. All right, yes, we'll do all that but now advance it. We're going to do that and we're going to do this on top of it. Or we're going to make that better.
We’ve tried--pick something--we've tried pairing and we run into this issue. All right. What can we do different to make that work better for us in this context? In the last book I wrote, Pragmatic Thinking and Learning, one of the big things that I tried to hammer as a lesson in there is the importance of context. The fact that what works here now on this project may not work on the next one. It may not work on the last one. Every situation is different. You have to be attuned to the particular context that you're in. And this is a great case for that.
Some particular practice might work well for all kinds of folks and all kinds of circumstances but it doesn't work for whatever reason. Perhaps your team is geographically dispersed. You can't pair program in the traditional sense. Okay. What can you do to get those same benefits? That means you need to understand why you were pair programming in the first place. What are the benefits you're trying to get? How do those work in the normal situation? All right, we can't do that. What can we do? Yes, I agree we should do that and advance it.
And that part of advancement is what we haven't been seeing. I fully expected in circa 2002 that we’d see 50 new methodologies pop up, following the same very generic sort of guidelines which would really boil down to be smart, don't be a jerk. It's a fairly straightforward kind of stuff. I expected a real proliferation of folks for no other reason than commercial interest saying, oh, hey, here's my methodology and check this out. And that didn't happen. We kind of -- we got to the agreement phase, like, okay. Then we stopped. We didn't really press it any further. I mean, there's been some but not nearly on the scale that I would have expected it.
And maybe that's not even needed. Maybe it goes the other way. What we see is a consolidation of all these various ideas from Lean, from Kanban, from XP, from Scrum, from wherever and it all ends up coagulating into one thing which is, here's what you do. And that's another, a real possibility I think, the ultimate aim of Agile is to have that flavor of software development where you don't even call it Agile. It's just what you do. And I think that you've seen that already with e-commerce, right? Does anybody call it e-commerce anymore?
It's commerce. It's just what you do. There's nothing special about it. And I think that's the same sort of progression we'll eventually see. There might be another 50 methods that pop up and various good ideas in advancements but ultimately, it all just come down to, well, that's how you make software.
And I probably shouldn't repeat this, but a friend of mine said he was working in a place where this guy came down the hall. He was reading magazines and said, hey, I just read up on this Agile software development. This looks really cool. You know what I think if you heard about this, if you know anything about this, this was within the last six months. So here's this 10 years later and here’s this "ever hear of this Agile software development thing?" So yes, there certainly are some issues with getting the message out there accurately.
Well, and part of that -- this is another sort of beef I suppose I've had with Agile over the years for the sake of pedagogy, for the sake of explaining how to do Agile, most of the books and articles and talks and lectures tended to focus on, your right, it’s a brand new project, you got your brand new team together. Here's how you introduce the team. Here's how you start. Here's how you start this beautiful green field project that you're starting from scratch. All that's lovely. And do you know how often that actually happens in real life?
That's not the case. You've got folks who know each other. Maybe if you're with them have hated each other for a few years already, you got some baggage there. It's not a brand new project. It's a legacy project because every project is a legacy project as soon as you commit the first line of code, now, it's legacy.
So that's a much more realistic situation and that's a lot harder to manage. So you see a lot less in the literature of, okay, you're midstream; you've got this legacy product. You've got all this new features that is demanded by the market, by the stakeholders and you want to transition to an Agile approach. Now, what do you do?
And there's -- I mean, there are some folks who write on that, speak on that but it's not commensurate with the amount that that actually happens. Everyone is like, okay, clean slate, here's what you do. Well, that's nice but that's not the context where in.
And that's a much harder road to take which is why everyone avoids it. And there's ways to do it. I’ve always recommend to folks who go in and stabilize, depending where you're starting from, of course. Stabilize what you build first. If you don't have a build machine, if you don't have version control, well, you should be shot. But anyhow, just saying anyway, but get your house in order first. Then start working on bringing in maybe some pair programming, maybe some of this, maybe some of that, some unit testing. Any new piece of code you write, introduce some unit testing, get some sort of application level testing against that big, black box that's your legacy system. Just get something in place and then kind of work up from there. So I mean, there are specific techniques you can use and things you can do but ...
There's actually a lot of companies like that. I've been asked to speak at a number of places where they explicitly requested don't call it Extreme Programming. Don't call it Agile. Don't call it any of these names that you heard 'cause they tried that once and it failed. It went up in smoke. People lost their jobs. It was this huge debacle because they did it wrong but they still want to try so they call something else. Call it Pragmatic Programming, call it -- stick any name on it . Call it Fluke, whatever. Just don't call it "that" because we have a local negative association with that name. Which again, and that's very unfortunate to see.
I went to see a client a couple of years back, four or five years ago and I went in doing the usual consultant dance. He's like, well, let me interview and talk to everybody first and see what you think. So I met with the team leaders and said, what do you think -- they've been doing Agile for about I guess six months or so. I said, "What do you think of Agile? When I say, Agile, what does it mean to you?" The team lead said, it's management's latest technique to kick our ass. I said, "Really? Now, tell me what you are all doing because I'm thinking something is not right here." And it wasn't...
15. It’s being forced on them.
Yes. They were using the name and they weren't doing things what we would recognize or recommend in an Agile way. The name without the content.
I could tell you but I’d have to kill you. But what I can say is to see what we're up to for Pragmatic Programming, in the Bookshelf, in the magazine and all the stuff we're into is really simple pragprog.com. We have a newsletter that goes out every week or every other week that tells you when the new issue of the magazine is out, what new books are coming out, where our authors are speaking and appearing, all sort of news the world that we think is important. And follow us on Twitter at @pragprog.
Yes. And that's actually -- that's a really nifty thing because if you can read it online, it's in plain HTML. If you just want to surf, if you want to go read it in the mountains or someplace where you don't have Wi-Fi, you can put the PDF on your laptop or you can put the MOBI on your Kindle, the ePub on your iPad/Pod thing, the iTouch, whatever you have.