 Good afternoon. My name is Glenn Vanderberg. I am playing the role of the Enterprise guy today. I decided to dress the part. So Rubyists have an awkward and strained relationship with the Enterprise. Well, actually, before I get into that, I want to quickly get the blatant self-promotion stuff out of the way. I work for Relevance. We do a hosted program called Run Code Run. We think it qualifies as not an enterprise-y tool. So Rubyists have this awkward, kind of strained relationship with the Enterprise. And some of us want, and in fact, quite adequately, want nothing to do with it. And others want to break in and sell to the enterprise market and sell our services there and cutting in and out. I've noticed some clicking and stuff, I guess. You don't touch my side either. So someone to break in and sell to the enterprise market. Some want nothing to do with it. Some of us in the Ruby community are in the enterprise and want Ruby to break in and be able to play there. And it's happening to a greater or lesser degree. And some of us are outside the enterprise, but we would love to be the saviour and help our enterprise brethren throw off their chains and be free within their environment. So a couple of years ago, there was Joe O'Brien, who I don't guess is in this room, and Edgecase hosted a conference in Columbus called E-RubyCon that was focused on Ruby in the enterprise. And I gave a keynote there. Why is that relevant? Well, the talk I'm giving today, I actually gave there earlier this year as a sequel to that first talk. And so in order to set the stage, I need to talk about the first talk for just a little bit and kind of let you know where I was coming from. The first talk was called Enterprise-Sham Enterprise. And the thrust of the talk, the conference as a whole was, is Ruby ready for the enterprise? And so, I'll stand just like this. This is why I don't like microphones. So the talk was called Enterprise-Sham Enterprise. And the conference was about, is Ruby ready for the enterprise? And I had developed this idea that the problem with Ruby in the enterprise, the mismatch between Ruby and the enterprise, is not Ruby, it's the enterprise. And furthermore, maybe even that's not the case. Maybe it's that the enterprise, maybe it's that the enterprise doesn't really know what they need. And they've been sold a bill of goods, so to speak, about what enterprise software is and what enterprises need to build software. And so that was really the topic of my talk. And so the enterprise tool market summarized. Here are tools that will let you build software quickly, cheaply and with below average developers. That's a bit cynical and overstated and oversimplified, but that's not too far from the truth. And, but really, if there's anything that enterprises need to know about their software is that most of the challenges of enterprise software are about the enterprise and not the software. And if there's anything, you know, big enterprises or more commonly big enterprise tool vendors, when they talk about enterprise software, they talk about high volumes and scalability and manageability and this and that and the other. And, you know, none of the stuff we work on has any of those problems, right? In those respects, enterprise software is generally no worse than little startup software or some of the kinds of things we do. And in often case, the challenges are much easier in enterprise software when you're in a constrained environment building intranet applications and things like that. So the common enterprise idea of what is different about enterprise software I think is dead wrong. And really, if there's any one characteristic that enterprise software has that the rest of the software we build does not, it's that if you're writing enterprise software, you have to assume your code will still be in production in 30 years. You'd like to assume it won't be, but you have to kind of assume that you're gonna write that and stick it out there and who knows what's gonna happen and who's gonna have to be maintaining it and keeping it up to date and integrating it with other things for a long, long time to come. And maybe 30 years is an exaggeration, but I think you get the point. And if there are tools that are really well suited to being enterprise tools and solving more problems than they cause, then those tools need to help us solve that problem and not the typical problems that enterprise tools are aimed at. And finally, I closed with this great quote from Kent Beck that I just always pull out. Listening, testing, coding, designing, that's all there is to software. Anyone who tells you different is selling something. So then, now it's time for this talk when I'm talking about existing enterprise tools and big tools for the enterprise and exactly why they are bad for the enterprise instead of as they are sold being just what the enterprise needs. I'm gonna talk about the enterprise tools. This isn't a particularly Ruby heavy talk, but those of us, well, in fact, it's a Ruby agnostic talk more or less, but for those of us who are doing Ruby work and working in enterprises or trying to sell our services into enterprises or in some cases trying to build libraries and tools that help Ruby meet enterprise needs, I think this will be valuable. I think most of us are in a position to care about the relationship with Ruby and the enterprise even if we don't actually want to be playing in that space. So by way of giving credit, a lot of this work came out of a project that we did with Verizon Business, which boy, if there was ever a big enterprisey customer, that's it, and we learned a lot from this project and I wanna make it clear. The way we learned this was not by watching what Verizon Business did and saying, boy, you wanna do anything but that. They've actually been a really good customer force in a lot of ways and the group we're working with is not very enterprisey, but they have a big concern about how their enterprise works. They see how we work compared to the way they work and they wanted to talk to us about how maybe they could learn some lessons from the way a small Ruby shop develops software and improve their efficiency and responsiveness and things like that and we worked together with them to think about it. They actually, there've been a lot of companies that have looked at bringing agile methods or agile tools or lighter weight tools or whatever into big enterprises and they tend I think to usually have the wrong focus and Verizon had just the right focus which is, which was, they didn't come at it as how do these tools and methods need to change to meet us? It was how do we need to change to meet them? So I wanna tell you a little bit about what we've got and part of it, one of the guys we were working with there led me to learn a lot about the way American manufacturing changed in the 1970s and some of the roots of that movement and how we might apply it to not directly to software today but to thinking about software today. And of course a lot of people are doing this but I'll give an overview. This is a picture of the United States factory in the 1970s. Well maybe not, but so manufacturing in the 1970s was in the doldrums in the United States and our butts were being kicked by Japan and Germany and other countries that kinda had a better view of what manufacturing was all about. And a lot of things and a lot of people went into kind of changing this to the extent that it changed and it did changing it a lot better. But one of the key insights was a complete change in the way inventory was treated for the purpose of accounting. At that time inventory was treated as an asset and it's easy to see how this might be, right? You had raw materials coming into your factory and you were assembling them and thereby adding value to them and the inventory was a completed product ready to sell or in some cases a partially completed assembly that was much further along towards being ready to be assembled into a completed project. Therefore it was farther along the line from raw material to generating value for the company and it was treated as an asset. What people began to realize is that, or was, that that way of thinking about inventory put a lot of the wrong incentives in place for people in a manufacturing business. If inventory is an asset, we want more of it. And so we'll ramp that up and there are all kinds of hidden costs that go and as I'm telling this story, I want you to think about software development in enterprises. There are all kinds of costs that go along with having a lot of inventory and some of them are obvious and some of them are not so obvious. The obvious cost is storage of this inventory, warehouse space. A less obvious cost is sort of clogging up, especially if you have partially assembled inventory, clogging up your factory space and making it difficult and more time consuming for raw materials to move in and out and people to get from one place to another to get assemblies from one part of the line to the next part. An even less obvious effect of having a lot of inventory is that it really puts a negative pressure on your R&D department. If we introduce something new and improved now, everybody's gonna want that and nobody's gonna want these last generation products we have sitting in the warehouse ready to be sold and so that'll mean we have to take a huge loss on that eventually, so we've gotta hold these new developments and new products back and not announce them until we can sell off this inventory. But meanwhile, the factory's still generating more of that inventory because the incentives are made on a departmental level rather than on a whole company level and your competitors perhaps are going full speed ahead with their research and development and introducing new products. And so, shockingly enough, some people were able to get this idea across and generally today, inventory is treated as a liability and there's been a lot of work put into just in time kinds of inventory management and supply chain thinking and completely retooling factories, but not just factories. The entire enterprise, the manufacturing enterprise, including the bean counters and how they keep track of things on the books and which part of the balance sheet inventory goes on in order to set the right incentives in place and change the way manufacturing works in manufacturing enterprises and make them profitable. So, we started thinking about how Agile would work in large enterprises and tools like Ruby and things like that. And we looked at it in both ways. How might the enterprise change to meet Agile methods and lightweight tools like Ruby and faster ways of building software? And we started with the Agile manifesto, which is always a good place to start when you're thinking about these things. And we noticed something kind of interesting and I buy this and I strongly suspect most of the people in this room buy most of these values made of gesture. We noticed this interesting thing about the very first, notice this very interesting thing about the very first thing here, which is we value individuals and interactions over processes and tools, which is a good point. But we love our tools, don't we? We pay a lot of attention to tools. I'll go with the hand mic. We pay a lot of attention to tools. We love our tools, we're devoted to our tools, we're passionate about our tools. To say that we don't value tools is ridiculous. So there's something deeper going on there. And as we went into this effort, we considered the fact, the kinds of Agile practices that we follow in most of the small businesses and startups that a lot of us work for are sort of how these principles get manifested in a particular environment, in a particular context. But maybe in a large enterprise, these principles are going to generate slightly different practices. So Agile might reasonably look a little different in that context, but at the same time we wanted to think about how the context needed to change to meet Agile tools. But we focused a lot, there were a lot of insights that came out of this project, but we focused a lot on the tools aspect. And we focused on why it is that many of, or if not most of the best and most passionate developers in our industry care a lot about little tools like this and big enterprises are very skeptical and don't like to touch them in general. So I want to talk about several different ways that enterprise tools turn out to be not just less effective than these tools, but in fact downright harmful for the enterprises in which they're used. First thing I want to talk about is context switching cost. And when I talk about context switching, please don't get this confused with multitasking, right? Multitasking has big downsides in a lot of ways, and the idea is not to do a lot of things at one time, but the idea is that we do have to switch from doing one kind of thing to another and we want to reduce that context switch cost. People have done psychological studies of programmers and one of the characteristics of good programmers is that we tend to be able to mentally switch gears quite easily both from low levels of abstraction to high levels of abstraction and from one aspect of our system to another and from the activity of coding to testing to debugging to going and reading a spec and finding out how that API call works and all those different things. So one characteristic of tools that are good for good software developers is tools that help us to context switch very cheaply. Tools that start fast, tools that allow us to drop in, do one thing and get out and switch back to a different tool. Most of the good programmers I know have pretty heavily worn alt and tab keys on their keyboards. And big enterprise tools tend to be take a long time to fire them up and once you do fire them up, you have to get in and click here and click there and click there and then it wants you to do more and stop and write documentation here please and also it tries to do a lot. I want you to stick in this tool and use this tool for a lot of different activities even though it might only be good for one or two of them. Another way to think about this is you want tools that are very easy to just hop into and hop out of. A vehicle like this is a good model for the kind of software tools that are really good for rapid software development. They're specialized. You hop in and you hop out as compared to a different kind of vehicle that getting into and getting out of is quite a chore and in fact once you're there you want to stay for a while or you've sort of missed the point. Good software tools tend to do one job at a time and big expensive costly enterprise tools try to do a lot. I'm not particularly happy with this picture because the intent is to show something that tries to do too much and is a bad idea and frankly I would love to have that tool but I think you get what I mean. I actually found a lot of pictures that illustrated my point better but that one was just so beautiful I had to go with that anyway. We have a design philosophy in our code of do one thing well a class, a method, a test or tool should pick one thing and do it well and you get multiple things that do one thing well and you put them together to work together to do a larger thing well and that philosophy works really well for our tools as well and enterprise tools tend to try to do a lot all at once. Why is that do you think? You can charge more. Yeah, I think that's the big reason there are a lot of ancillary reasons that support that but I think that unless it does a lot you can't charge much money for it so let's bundle some more things in. The feature checklist one illustration of the right kind of tool is it's often very hard to explain to for one of the better words enterprisey types why we need both RSpec and Cucumber in so many ways they seem like they're attacking the same problem but we like them both and we use them for what to us seem like very different things and one excels at one kind of testing and one excels at another kind of testing and they use different vocabularies and this is a very fine granularity I think of tool specialization but it doesn't feel too fine to me it feels just right and enterprises would prefer to have just a few tools that each do a lot than a whole bunch of tools that do one thing well and yet I think that ultimately a few tools that do a whole bunch is a harmful strategy I want to talk about two kinds of craziness typical enterprise tools if you read the sales brochure about what they're going to do what they will do for you what they allow you to do you'll almost always find something in there that's like oh cool but why would you ever want to do that and I'm not sure it's a good idea and in the effort to throw more and more features in and build up that sort of sales checklist you end up with do everything tools that try to do some frankly crazy stuff and we all know how businesses are once they've spent money on something they want to use it it's a bit facile to blame that for the fact that when given these tools programmers do crazy things because when we have a tool in front of us and it does something we like to use it to but there's another kind of craziness and it's a craziness that's actually good and that enterprise tools usually prohibit which is the craziness of completely stepping outside the box and look at things that have happened in just the ruby part of our field over the past few years and the changes that have come about and some of the, you know what a lot of enterprises would see as really complicated deployments with you know Nginx and Thin and then Rails running behind that and Redis server out there and the database and you know a solar instance running that you push indexing and search requests to and stuff like that that's the kind of crazy things, crazy things that developers need to do to solve problems quickly and efficiently and yes it's a little complex but in every case it's you know picking a little tool that'll do the right thing instead of having to implement it all yourself or integrate it all into one big thing and integrating those tools together in lightweight ways and you end up with something that's actually really powerful and flexible and in every case or at least in most cases we're trying to use the right tool for the job and the typical enterprise software development tool actively prohibits that kind of branching out and experimentation and grow and using small pieces loosely joined so to speak. There are kinds of craziness that we'd rather not be pushed into but at the same time we'd like to reserve the right to be a little crazy sometimes when it seems appropriate. Not long ago I probably shouldn't even start this unless I'm sure I can remember the whole story but you know every now and then there's media outlets and media companies, newspapers and music publishers and everything else realize that boy they should really try to get control of how people distribute and use what they produce and not too long ago I think it was Reuters and I heard somebody say something it was the AP made an announcement of they were going to start putting strong digital rights management in all their wire articles and they had this vision this power pointy slide kind of vision for how this was all going to work and anybody with a dose of technical chops knows that this is lunacy and it could not possibly ever work and so some technologist somewhere had told had sold the AP something crazy something that could never possibly work and John Gruber at Daring Fireball I love this line he said AP just got sold some magic beans a lot of enterprise tools I think are selling magic beans Enterprise tools often have impenetrable shells they might do deep magic inside but in the effort of being easy to use or perhaps easy to train people to use because that's one of the things that vendors are on the hook for is to train developers to use their tools they have a simplified API or a declarative API or configuration checkboxes and a tightly constrained list of things that you can do it might be a big list but nevertheless it's not extensible this is what this tool will do and you can get it to do this and that and the other and this list of 50 things but what if it's what if the one thing you need today is not on there most of the tools that we tend to know well so one example of this is plotting and reporting and charting packages there's a whole family of them and they're usually declarative in either through a graphical user interface or through some sort of language you declare what you want this chart to be and where you want it to get the data and how it should be plotted and things like that and as long as you are happy with the different kinds of plots that provides you're in good shape but if you want to do something a little fancier you're not and there are tools and they're more programmer oriented tools and they tend not to have as fancy sales brochures but there are tools with what I like to call an onion skin API where there's a nice simplified constrained outer layer but then there's an escape hatch and you can peel that back and get to the next lower level API that that outer API is built on and that's documented too and so you can take a little bit more control if you want to and then you can peel that back does this sound like anything that people in this room know? Coco? Active record? That's my favorite example Active record you can peel back as much as you want and get down to the level of just throwing raw sequel in there you want to do that all the time? No but on every project I've ever worked on with Active record there was probably at least one query where we ended up throwing a reasonably complicated sequel fragment in but to use Dick Gabriel's words it's not the right thing it's not clean and pure and nice and architecturally pleasant but it's extremely pragmatic and it lets developers move fast and get what they would need to do done in a reasonably clean way and it doesn't take the power away from us which is the most important thing they'll come at you sideways it's how they think it's how they move sidle up and smile hit you where you're weak sort of man they're like the scent leaves hard kills you never ask a lot of enterprise tools force us to come at problems sideways integration tools are particularly like this I want to communicate with that thing over there great! and we've got an API and it's got a data format and we've got a data format and if you'll just buy this integration bus that sits in the middle all you've got to do is make that tool communicate with the integration bus and then make your thing communicate with the integration bus and you're set okay and the beauty of it is if you ever need to get other things to communicate with those two things it's already there and you have this one common format that you can use across your enterprise the problem is that right now we just need to get from here to there and sticking this integration bus in the middle takes us sideways and really it doesn't simplify the problem at all it just doubles it now instead of making A talk to B you need to make A talk to C and B talk to C and in my experience and I've worked in a lot of enterprise software situations that that future scenario of you need to make other things talk to all of these things somehow doesn't really ever come to pass not enough to make it worth all this sideways effort some tools come with their own ecosystems so let's talk about finished robot overlord tools name an enterprise tool that sort of accretes its own ecosystem within an enterprise all of your familiar with them web sphere oracle active directory Ruby on rails we'll take this outside what? unicenter clear case yeah you don't have to convince me and this is one of the things that we really recognized a lot I want to show you I have permission from Verizon to show you this I want to show you something we did a model we built we started building a model of incentives remember I talked about the the whole I think it's probably over here we talked about the whole story of manufacturing inventory being counted as an asset rather than a liability and I think there are a lot of similar stories in enterprise software situations where the way people account for things the way budgets are controlled and the way results are evaluated and performance put all kinds of negative incentives in place and we started trying to model this using an interesting tool called flying logic and there's this giant awful model I can't figure out how I've got a new laptop it used to be just a key so we started modeling this and this is a giant horrible model and we think we're about 10% done with modeling incentives and dependencies within large, typical large IT organizations and so I want to collect some of this and throw in on this one box called tools and blow that up so let me just do it this way so in the back you won't be able to see a lot of this but I'll point it out to you so there's all kinds of different different things we plotted out here and there's one I want to focus on of how tool enterprise tools cause problems and we're particular talking about really expensive ones that have their own ecosystems volume purchase agreements have price benefits for the enterprise we like to think of this all happening because the the CIO likes to play golf and the Oracle salesman goes out and plays golf and buys him drinks and sometimes that happens but it's not always that nefarious I mean people who control the purchasing for large enterprise groups fall prey to the same kind of marketing baloney that we do when you know it's like hey it's on sale I could save money I didn't know I needed it five minutes ago but you know it's on sale I can save money so you have things like you know well we can use MySQL for free or buy Oracle and save a hundred thousand dollars right what are you going to do so what this means is that companies buy these enterprise licenses and they buy they get a site license and but that means that the IT departments have to create groups around those tools because they require this kind of support structure and so again we like we typically think of it in a simplistic way as well it's a sunk cost and the company wants to make good on that cost and somebody will look you know really stupid if we spend all this money on Oracle and nobody uses it but again it's often a lot more complicated than that and so they create these groups around the tools and it has all kinds of other negative effects getting results from the tools requires engagements from the tools group and if people don't want to use it it's more than just the guy who is responsible for the purchase looks stupid the people who are controlling the tool start to fear for their jobs right and they're agitating for wider use of this so that they can stay employed and so there's a whole bunch of other things here and I won't go into all of it because you probably don't care that much but we really found that tools that have their own ecosystems are a horrible cause of inertia in large organizations and tools that are sort of human scale and that programmers can understand and install and deal with and manage and control themselves are valuable precisely because they avoid the need for tool related groups within the IT organization and all the bad things that come with those a lot of enterprise tools treat the symptoms and I'm going to speed up here a little bit but I'm going to just give one example which is near and dear to my heart which is rules engines how many of you have worked with rules engines how many of you think they worked really well for the situation where you used them I'd love to hear your story so I think there's a place for rules engines I think they are applicable to certain domains and when I use them I like to build a good domain model and encapsulate the rules engine behind part of that where it really makes sense but often rules engines are touted as sort of being right at the center of an enterprise architecture and so I'm talking about treating the symptoms and the reason rules engines sell as near as I can tell more than anything is because business people want to be able to change their business rules more quickly and by themselves without having to involve the IT group and programmers all of which sounds okay until a few months down the track the the business starts to learn why the IT group has certain processes in place and really these rules represent the logic of the application rules can be buggy and those rules need to be reviewed and tested and their deployment into production needs to be controlled at least a little bit and every time in my experience that rules engines have been really strongly advocated in a large IT setting they were treating a symptom rather than the problem and the symptom was that business people couldn't get changes into the system fast enough but the real problem was that for whatever reason the IT group was not responsive enough and the best answer in that case is to work on making the IT group more responsive bringing the rules engine in has all kinds of problems because basically the business people are now in a sense managing source code and they don't have the tools in place to do that effectively but also it kind of makes the IT group defensive and postpones dealing with the real problem which is that they're not responsive enough enterprise tools end up sticking the IT organization in a time bubble enterprise tools are big and unwieldy usually and the cycle of getting them into the enterprise takes a long time you have to go through a survey to choose a tool and then the purchasing process goes on and then comes training and a learning curve and then the long period where the tool snakes its tendrils into every part of the organization and by this time months have gone by how many different web server technologies have the rails community gone through in that amount of time by the time one tool gets into a sizable enterprise I think we raced through Lighty and fast CGI and mongrel and thin and now we're on to unicorn and so part of the goal of enterprise tools is actually to slow down innovation and slow down experimentation and be more cautious and I can actually see that sometimes that's a valuable goal but meanwhile the general pace of innovation and change in the software world is increasing and IT groups and enterprises are falling farther and farther behind all the time they're thinking they're pretty hot now because they're adopting Java in a lot of cases, those are the worst of them but it's true, there are a lot out there that are like that solving people problems with technology, I don't need to talk about that one too much just aiming for too much control once you get above a very large size at all command and control doesn't work when even the US military understands that centralized command and control is not a bad idea it's time to start looking for something else and a lot of enterprise tools are about preventing people from making mistakes and if you prevent people from making stupid things from doing stupid things that's usually good but the problem is that it usually comes at the expense of also preventing people from doing certain smart things and far better than control is the combination of facilitation and feedback don't make it difficult for people to do things in fear that they might make a mistake make it easy for them to do things and at the same time make sure you get rapid feedback so that mistakes can be seen and caught quickly and corrected before too much is lost obviously there are places in the process where mistakes are more costly than others and you need controls around some of those but in general facilitation and feedback is a better choice and the typical enterprise tool is more oriented towards control so we're back to the manifesto again and I started this with a question about why this is and why we all say we buy that when really we all love our tools and I would like to suggest that when you see this you think about a corollary to that first one which is yes we believe in individuals and interactions over processes and tools and as a part of that since we need tools to make us more effective we value tools that enable people over tools that control and constrain just like these thank you very much