 Thank you very much big tiger, you know What Jim does for the community is really amazing and it's really deeply appreciated by everybody who you know works with him in any capacity Brian Lyle asked me whether or not I was gonna be able to live up to the title of this talk I have to admit something the title of the talk is a trap Because the real point of my talk is not to show how rails can compete with Or can help enterprises compete with startups the real point of my talk And I hope that you'll agree with me at the end of this is that we make too much of a big deal about the differences between startups and Enterprises and that as a community we should be making active efforts to move into both communities equally. I Also apologize because I have an academic background and this is gonna be a little bit lecture style So forgive me if I'm not making eye contact except for this first dynamic bit You're gonna have to I'm gonna have to coast on that for a little while I also work for a big media company. So there are some pictures that will hopefully keep you occupied So my name is Jonathan Broad as Jim mentioned I'm a vice president of application development for Getty Images It is a pretty big company although pretty small by enterprise standards, which is my subject for today There are about a hundred other VPs in the company including another VP of app dev who runs the back office Development and asset ingestion and data migration teams My organization's niche is focused on creating websites that our customers use to find stuff to buy And that our contributors use to give us the stuff to sell External stakeholders in the language of my people We build and operate about four major sites and a number of smaller sites and a few portals whereby folks upload their stuff to us In addition to stock photography. We are really into news Sports and entertainment photos as well second only to the Associated Press in the US at present There's about 150 folks in my organization including quite a few in this room And I can't say I can't say exactly how much revenue we collect the all these sites because at the moment We're a private company, but I'm pretty sure that it's more than Twitter So how many of you wanted to be a middle manager when you grew up? It is it is Does anyone know why I can't there it is? Why can't I see my my pointer? Oh? Thanks. I'm good. I'm good. I've got it got it So The truth is nobody wants to be a middle manager, right just about 13 years ago Which is not a long trust me not a long time ago trust me on this I just moved here to Madison and I was driving for Union cab while putting myself through library school and volunteering part-time for the rainbow Books are cooperative if you're familiar with the politics of the institutions I'm sure you'll believe me when I say that this isn't exactly how I thought things would turn out My intention today isn't really to represent my company But rather to chat about what we've done and observe and what I've observed over the last five years from my own point of view Working for Getty I'm gonna start with some background to frame things up This whole thing is a Madison story through and through and wouldn't be possible without a few of you in the audience So I feel like it deserves a solid retelling here Then I'll talk about some of the problems that I found in my current position in the company and how reals is helping me solve Some but not all of them. So now we absolutely have to start this wonderful movie Now the sound is important. Okay So a while back I was a librarian or at least I graduated from library school The last library I actually worked out was the tech library I do it during library school where I was given a budget to buy books and teach myself Everything I wanted to know about technology. It was like a degree within a degree I walked out with my diploma and went on to work as an information architect and UX person for the state of Wisconsin That experience could be the subject of a whole another talk So if I sit to say that there are worse places to work than enterprises, but seriously never Never underestimate the value of terrible experiences because they make everything else seem awesome by comparison a Company in town named punch doc was looking for a redesign of their sites search experience There were local startup created by a guy who had sold a previous business in the stock illustration industry to Kodak Which then sold it to Getty actually After I left the state job I had been doing some contract programming and PHP and Java and a bit of Python I was also teaching some classes part-time back at SLIS UW's Library school down the way and this guy whose name was Miles Gershty and his wife was also getting her PhD there I had a reputation for knowing a thing or two about search and information retrieval So when she heard what her husband was looking for In that in that area she hooked us up. I Joined punch doc and went about went about redesigning the search experience Recommended a new search engine led the development of a controlled vocabulary and created a process for playing this vocabulary To externally key worded images We're the first in the industry to use a faceted search and browse interface and a lot of competitors copied us including Getty There's a lot of fun getting it all set up, but there are parts of it that's really started to grind Punch doc at the time was running on top of a custom e-commerce framework built by a local company Burby Networks bought by CDW Now to funk some of you may know it on top of their own proprietary Framework which in 1999 they'd intended to try out on us and then resell to the booming tech industry at the time Stop me if you've heard this one before Needless to say that didn't pan out and we were left maintaining a custom pre struts model to ask Kids they call it server-side MVC Java framework whose lines of code dwarfed the applications as the world slowly moved on around us We were stuck with a very over engineered application Although we did manage to push the research out it was a close shave It was pretty clear to me that we needed to get off our stack if we needed if we wanted to keep making changes Efficiently so I was in the middle of researching the relative virtues of tapestries struts version one web work and a few Python frameworks I'd worked with when I saw it DHH is build a blog in 15 minutes video It spent some time with Ruby previously and admired a strong object-oriented characteristics and its interesting block constructs I went so far as to write a Python library that mimicked Ruby's innumerable methods, but then I'd moved on So that video really blew my mind especially having spent a few years wandering the wilds of the framework was PHP lands and On top of a bespoke Java stack Immediately set about building a proof of concept where I took a fairly peripheral part of the punch-tox site shopping cart like thing called light box named after a thing photo photo editors use to look at negatives and Implement to the same experience in Rails using the same Oracle database as our Java app talk to Despite being brownfield and requiring some hackery to get the Oracle drivers working over Christmas break I'd done the work and I was hooked I Convinced the CTO at the time to keep to let me keep rolling and I hired some more people Dave Heffler Matt Margolis and James Redder all still at the company to help me convert our aged Java application to Rails We approached it incrementally converting one website function at a time. This is something of a theme in my life as you'll see This is a more professional promotional video for getting So no sooner had we gotten a good head of steam going on that project and punch-tox was acquired by Getty images They had hundred pound gorilla bar industry punch-tox had 60 employee employees by then I was the 12th or so Getty had over 1500 Interestingly, it was the first time Getty had ever acquired another image retailer. Usually they just picked up content companies like the CEO's previous business Getty's interest in our company was probably mostly in the customer base I've never actually asked because I prefer to believe it was my awesome team in the search experience we created Nevertheless, they were interested in using our business to experiment with a new IT architecture They were thinking about a service oriented one that would let them run multiple independent store funds while reusing their core platform To ingest search and sell images and other media So my team and I proceeded to shift gears and instead of integrating our models with the Oracle back end We rebuilt them to talk to the soap web services the teams in our new HQ in Seattle were building Soap is of course not something that rails normally integrates integrates with then or now Although if you go back as far as I do with it, you may remember we it used to provide soap endpoints Matt Margolis and I spent a week looking at using soap for our as a client before giving up and writing our own version of Saxon to treat The end point is a dumb HTTP service and extract the content with live XML In the end we did get shit to work and without this architecture and those endpoints I never would be telling you this story right now We launched the new punch doc after a few months. The first few weeks were rough The web services themselves were totally new and broke or slowed down quite a bit Working out how to deal with an unstable and relatively so web service back end and cope with rails as a lack of a good async Or threaded deployment option at the time took some doing But soon enough we were running smooth after the acquisition and integration was complete Everyone in the company was laid off except for me and my team from Getty's perspective. It was a big success To me it felt a little bit like watching your house fall down around you while you stand safe in the last remaining upright doorway After punch doc getty acquired another stock photo retailer Jupiter images And we got assigned to convert their photos comm property to use a web service back end as well The team in Madison also developed a framework for building white label sites rather quickly and built three sites for several sports leagues Like the NBA and PGA tour as well as several internal tools Elsewhere in the company a few more websites were built using the same approach including think-sock, which is growing quickly Currently Madison has 10 engineers managed by Matt Margolis Including Chris Johnson Jeff Carly James Redder Damon Butler John Rebar Joel Andrich Mark Anderson Josh Swan and finally Martin Marty Stitt who's actually been working with me Who's actually been working with me since the search project days? It's been a great team and I just wanted to recognize their accomplishments so Here my story diverges from the Madison teams a little bit The SOA experiment had gone very well for the business They were able to acquire and fully integrate new properties without having to shoehorn their entire custom base into the flagship Getty images site They were also able to enter new lines of business pretty quickly using the same approach which happened a year So later when we launched the think-sock site At the same time the architect of the SOA idea was promoted to CTO of the company and my responsibilities grew to encompass the web Services teams working in Seattle Eventually I was offered a promotion my current position overseeing all the web application services development including our search systems as I mentioned earlier This also required me to start spending half my time in Seattle Which I've kept up for the last three years for reasons that sometimes escape me Actually, it's really just because my wife is incredibly awesome in the work that she does here for the community in Madison is more important than mine Seriously, she was awarded awarded a human rights award from the city this year. I really don't know how she puts up with my corporate shenanigans What I found when I arrived in Seattle Taking on my new role with complex and I use that word advisedly So basically I found a lot of technical debt as you might imagine I found an enterprise monoculture and I found an organization that was coping with constant organizational and business change I'm not going to spend a lot of time talking about technical debt as a concept because I think others have covered that base pretty well I also understand that there's a difference between deliberately acquired technical debt and just messy crap But I'm not going to differentiate Calling systems messy crap hurts people's feelings and the main point is that regardless of how it came to pass Bad code is on the books and in production and has to be measured as an ongoing operational costs to the business But I did want to say a few words on monolithic applications sex related to the talk that we saw earlier today in the sandboxes Which is that although they are petri dishes that have cultivated all the technical debt that I personally had to wrestle with over the years And by the way what I mean by monolithic in this case is just a web application that manages all of its external concerns All the external concerns of a business usually talking to a single database and there's bonus points if stored procedures or sprocks are heavily used over time these monoliths become a surefire way to Accumulate a lot of technical debt very quickly because if you're growing rapidly and a lot of compromises are because a lot of because you're growing That rapidly and a lot of compromises are being made to chase dollars It's just too easy to take shortcuts and break down any half-hearted attempt at information hiding and proper modularity It's really a sociology problem. Not so much a technical one But I do feel like monolithic apps are getting something yet something of a bad rap I've seen more than my fair share of them as we all have I'm sure and one thing to keep in mind is that the Reason you're looking at them and having to maintain them is that they survived the larval stage in some startup somewhere What's more one of the reasons? It becomes rather hard to work up the courage to change them Is there's a lot of money is flowing through them every day presumably because some somebody somewhere is finding them useful Although so I had bought Yeti some more time It had not solved the underlying problem as I hope I'll explain presently but it's worth noting that I've seen the code bases of quite a few of these sorts of applications over the years and The one thing I they're all basically monolithic in the sense despite being grown in complete isolation from each other and on diverse platforms I'm sure that there are similar to many many other applications out there solving similar similar problems for different industries than ours If left unattended rails will grow effortlessly effortlessly into one Although they have the same problems. They also have the same successes and it's hard to argue with that What it means in this context is that what get he had was a very successful monolithic application It was becoming root bound like a plant. It's left too long in a small pot What had made it successful so far was now hindering its further adaptation. So so it is great It's a great great pattern and in some way shape reform. It's a wonderful way to grow software It's basically the idea of the lots of little hills. It was being discussed earlier By so I don't mean whistler soap necessarily or the official according to Hoyle or Thomas Earl Enterprise architecture strategy We're currently using plain RPC endpoints with adjacent serialization Not everywhere, but mostly It is it is a wonderful way to keep applications cohesive and minimally coupled in a way that any rapidly in a in any rapidly changing Environment that's already running in important services for the business and tunneling a custom RPC protocol through HTTP Gives you some independence in terms of design and the stack of the applications talking via that channel But implied in a true service architecture some well real isolation between the code and the data behind a given endpoint When I arrived on the scene this had not actually happened And I spent a good deal of my time in the first year or so drawing attention to the problems that this was continuing to cause What made solving this problem particularly difficult is our flagship site was also directly sharing the same code DLLs It's all C sharp and the same databases that were being managed by the web service layer That meant then that meant that until it also started consuming the web services The protection of the service boundary would not allow us to change the underlying implementation or to extract and isolate the data Yet alone doing do a serious refactoring of it. We couldn't really start until we had already finished, which is a big red flag. I owe quite a bit to the flexibility the SOA strategy did give us personally But being able to rack up more technical debt is not a great thing if you don't have a plan for paying it down Let me pause and share with you a wonderful diagram from a wonderful book by Stuart Brand who founded the whole earth catalog in one of the first And which was and one of the first serious online communities the well and also the long now foundation It's kind of a big deal and his book how buildings learn is the best book on software design that has nothing to do with software design that I've ever read He talks among other things about the shearing layers that exist in buildings and the way that they buffer buildings from things that change at different rates For instance furniture and other stuff can move on a daily or weekly basis constantly adapting to human needs space planning non structural walls or partitions and such may change Every few years as tenants turn over Core services like heating and plumbing change maybe every 15 years or so depending Structure may or may not be altered or extended at all during the life of the building and at least in the physical world The jurisdictional site is more or less permanent often outlasting many buildings Although it might change as the laws of the land change and governments rise and fall a great book from a great quote from the book is Architecture we imagine is permanent and so our buildings thwart us because they discount time. They misuse time One of the themes of my experience has been that the way that is has been the way that our visions of software mislead us Both as they are being built and afterwards because they don't take into consideration how quickly or slowly changes will flow through them so I need to make a Couple architectural terms clear James Copley and actually makes a similar point to Disturber brand and his book lean architecture, which I also highly recommend He's the the person who came up with the DCI architecture. It's a lot of people in the rails community. You're talking about currently The most basic basic shearing layers that he identifies Specifically in the context of software. He describes as what a system does for customers versus what a system is Which means how it is organized to do the business of the customers What systems do changes more frequently due to market changes and opportunities? While the while what systems are changes much more slowly with the evolution or addition of new businesses and fundamentally new business models into the enterprise We call our web service dependent web app sporkles for historical reasons My boss basically spoke up at a meeting and said it's like us a portal and a spoke together the web services at the hub He lived to regret that I Think they're actually I've done that myself. I'll talk about that later I think they're a best understood as our user experience systems What we actually do for our customers in an interactive sense our web services fit Copley and idea of the services So here's another problem Even if we did manage to complete our SOA strategy and build a set of services around our core processes I was also increasingly alarmed at the duplication inside the sporkles. We were building on the SOA platform Even if we moved get images comm on to the services a lot of the work That our e-commerce business wanted us to pursue required parallel changes across all these different sites that each brand Had increasingly they were being unevenly applied because of the time constraints and therefore It was becoming even more difficult to coordinate these changes across teams leading to even greater inconsistencies between the applications for no reason The SOA strategy had systematically discounted the amount of sheer effort that was required to build and maintain these sites And also the volume of ongoing changes that the business required Also the fact that the ongoing changes the business required contained a predominance of work in the user experience side of things Not the core services Even if so has succeeded its effect would be blunted by this fact In a complex system you must optimize the whole and constantly seek information about the true constraints holding your performance back It's not enough to have a vision of the future Like Stuart Brand like that Stuart Brand quote about architecture in the physical world often our business It's all too easy for vision to miss or misunderstand the dimension of time applied to systems how they grow adapt and die Architecture both physical and virtual is ultimately a visual art and find its most natural expression in the diagram Visions of the future should be accompanied by stories about how we'll get there because stories enter our bodies through the ear and The ear is the organ that we have that is the most sensitive to time as we repeat the story to ourselves We will notice a problem much sooner than we will if we rely solely on an architectural diagram In short as we added the story of our experience building sporkles to the map of our service architecture We'd found a gap in it. It was incomplete in two senses both by being incomplete in its execution and in its concept because it had Underestimated the effort that the sporkles were taking to maintain One more Stuart Brand quote, which I just love Books on the history of architecture outnumber books on the history of real estate 1000 to 1 yet real estate has a vastly more influence on the shape and fate of buildings than architectural theories and aesthetics Well, I'm talking a lot about architecture. Currently what I'm really talking about is real estate So this is the second problem that identified when I moved to Seattle It's easy to look at enterprises as a class and point out that they tend to be insular as they grow the value of sharing information With the outside world decreases as they try to become more efficient the gap between what the systems do and what they are Grows wider and more complex mappings between them Are built to try to bridge the gaps? This insularity I've come to call the autism of idiosyncrasy It's a kind of natural Galapagos syndrome named after the islands Darwin discovered To have diverged quite a bit from any mainland flora and fauna due to their genetic isolation Startups have a very different problem, but display a similar malfunction They are under constant pressure to prove themselves. They share information with their communities in an effort to get noticed and survive Because so many of them are fated to fail. They magnify the differences they find between themselves and their doomed competitors Freud had a phrase that captured the syndrome well. He called it the narcissism of small differences It's also called bike shedding getting hung up on small details rather than big problems. I Lumped the programmer and hypermasculine side of startup culture under this label as well The stereotype of developers in this environment captures it well the rock star narcissist extraordinaire Underlying this narcissism is a fear of failure, which is compensated for by an aggressive by aggressive status-seeking and that is also monoculture So that's one way of describing a problem that I saw and struggled with Another part of the monoculture in our enterprise was the influence of a tool and technology vendors such as Microsoft Such companies sell you solutions to all your idiosyncratic problems comforting you There was just a little bit more with just a little bit of configuration unique to you these solutions will save you money This isn't actually totally impossible and for a certain segments of business problems that probably is the most appropriate way to go I Think that the total surface area of that sort of problem in most industries shrinking rapidly. However, and in the area of technical Problems that can only be solved by empowered and skilled engineers given a wide latitude on their tool chain is growing More and more technology is contributing to the top line of the balance sheet revenue growth in addition to its traditional place in the enterprise Saving money through automation aka shrinking the bottom line In short monocultures can feed monolithicism and degrade the system's overall usefulness for end users pretty rapidly due to low barriers for bad ideas and approaches to be accumulated The efficiencies of the monoculture turn into pathways for contagion Back to stereotypes in my problem at Getty my private archetype of the enterprise developer is a Roman legionnaire They can and will use whatever tools available to build a bridge and so the tools themselves have become less important They value the homogenous and disciplined environment that recognizes their skills and treats them with respect They're not really attached to a particular mission or purpose and don't care much who they are fighting or why What they love is a challenge and the opportunity to exercise their skills to build or tear down effectively and efficiently They want their stuff to run well and to be recognized as excellent by their peers Balanced with peers who are passionate about the user experience that can build amazing things in short order However, when combined with a monolithic app and a typically successful enterprise is isolation from the realities of the market and customer life This archetypal attitude starts to cause problems internal debates about design patterns and problem-solving styles spill out into the code base Although I have no time for startup rock stars the sort of developers who really care about the user experience are discouraged to give up trying The UI enters a negative feedback loop of neglect and frustration So I found my team's skill and delivering consistently great user experience is lacking The feedback I got from our user experience group was that they had to keep things simple for my teams to be able to reliably execute Their designs and I couldn't blame them. The front-end code was unorganized and hard to change They were actually many developers. There were actually many developers who cared about this and were top-notch engineers But they there weren't enough to keep to keep things consistent yet alone to Get together and actually improve things Many of the most passionate people working to improve our UI left to join rail shops Which you can imagine I found particularly annoying It's easy to poke fun at the oddities of these idiosyncrasic Organizations and their susceptibility to being sold a bill of goods by tool vendors Keep in mind though that the corollary to this in the startup world is architectural masturbation and that desperate That desperate need to differentiate yourself from your competitors by using the stack to juror and the latest no sequel persistent strategy Enterprise naval gazing is just the flip side of this attitude once competitors are no longer an existential concern felt on a daily basis Eventually naive optimism and ironic narcissism and in the same place, which is cynicism naive optimism ignores difficult realities that will be encountered along the way to the promised land and Cynicism ignores our ability to plan and aspire to change and the need to choose new paths despite encountering obstacles Monocultures both enterprisey and entrepreneurial breed cynicism because there's always a gap between the way things are supposed to be and the way that they actually are Think critically and strike at the root of your problem with conviction Then on the theme of constant change I'm going to quote Michael Nygaard in length, and I really recommend that you watch his His lecture called architecture without men's tape because it's pretty brilliant In every organization of any size the steady state is always Superposition a superposition of many different waves of change originating at many different places and sweeping through the organization at different speeds Some of the waves are technological and some of them are market-driven The waves of change travel slower than the structural change of your organization itself You will never reach the end of that series of changes Obviously I and the rest Well, this quote really says it all in my opinion. I've seen acquisition after acquisition including the one that I wrote into Getty I've seen major new lines of business launched and new business models added I've never seen ever any business model taken away though With all this change new code bases are added and stripped away people enter the organization and people leave Revenues grow and falter careers are made and destroyed and Thus evermore pressure put on these core monoliths and their monocultures and their roots deepen and push against their containers a lot Of value is left on the table when people code and ideas enter the business, but find no place Obviously I and the rest of the Getty Madison team are an example of an exception To some of this process of change in that the architecture of the organization extended itself to provide my team and I an Opportunity to try some new things This therefore isn't so much a particular problem that can be solved as is a constraint on any solutions that come into the enterprise I wanted to build a path for others like me to follow me into the business So I'm gonna talk about two solutions to the problems. I just described that I've been pursuing one is my own coinage called the Unisporcle and the second is the use of rails and other open source projects to try to Strike at the heart of the monoculture that I found a destructive So what the hell is Unisporcle? Basically instead of n number of brand named web applications which change rather often are theoretically unbounded all talking to each each one Talking to each one of the services We invest in web applications focused on one particular part of our overall function and functionality That n is much more constrained than the brands and most of the web apps that we've been building are similar enough that variation Within a single application is minimal Each Unisporcle becomes slightly more complex to be brandable, but that's more than compensated for by the reduction in the overall responsibility and increased cohesion In addition, we've been pursuing a rigorous standardization of our CSS HTML patterns and JavaScript in pretty much exactly the way that Roy the speaker Following me will describe as I know his work well, and it's inspired us directly Overall this change was targeted squarely at reducing the overall complexity of our e-commerce applications We can execute functional changes in a single application test it out on a minor brand for statistical impact and then deploy it across all of our Experiences of the flip of a switch Additionally, and this is really important We don't have to wait for getty image comm itself to be completely moved on to the web services to start refactoring the services Once part of getty images comm has been moved over we can have a rolling wave of change by replacing parts of that site with this new implementation and then Being able to extract data and refactor our implementation while other parts of getty images and the services remain bound up together One of the nice benefits of the services sporkle split was always the promise of being able to provide an opportunity to focus more on the qualities particular due to technical domain and this remains a benefit and then as And then adds additional focus on the particular part of our domain not spreading knowledge of Subscriptions or registration light boxes across a number of otherwise unrelated brand applications branded applications Instead of dedicated Service teams and diverse disconnected sporkle teams. We can have cross-functional teams that become more deeply familiar with a particular domain It provides another seam to decouple teams geographically too if we can collate both services and web app capabilities and minimize the coupling between functional areas By avoiding monolithicity in the web application area We also provide some opportunity to vary our stack framework or language as appropriate Just as the service boundary gives us a contract that can be met by different solutions This isn't an original architecture or anything I cobbled together the beginning of it from a variety of descriptions of other company systems including Amazon's In addition, we've been making key decisions about the design and integration points only as we need and we will continue to do so Continue to do so Nor is this just another Architectural fantasy the first of these applications is due to launch next month and we'll be starting to parallelize the work across multiple themes from there when complete perhaps by the next mad ruby conference I'm pretty sure that we'll have the highest revenue rail site out there. I think that's pretty cool Sites, I should say so let me mention some other stuff that I've worked on to solve some of the problems I mentioned particularly particularly the monoculture problem One of the nice things about open source is that it is not just It is just not homogenous in addition to rails which is obviously the subject of this talk I found that my most die-hard enterprise developers on my search teams are absolutely loving a recent change We made to start using the solar search engine and the Hadoop ecosystem This is an example of the true benefits of so whatever however you describe it and our ability to explore a new solution Domain safely below the service boundary We're also starting to get involved in submitting bug reports and I assume and I hope soon patches back to solar Just as we can use a best-of-breed solution in search even though it is not a net product I argued the benefits of using rails to build the unisporcles. I argued that it is more productive When we looked at the facts because we had a couple of rails teams to go by turns out that it does not It is not faster in our enterprise To use rails in terms of the kind of calendar time that it takes to to build a sparkle But it is more efficient and then it takes less people to do that which I attribute to leveraging all of the frameworks and what not that rails provides Obviously being able to do the same amount or more with fewer people is something that appeals to a lot of business folk Of course, it is a good framework and has many libraries to address common web application concerns It's easily learned by web developers of many backgrounds, which we've kind of proven at this point We've taken a lot of the dot-net developers that were very familiar with MVC style applications and I'm honestly astounded by how quickly they've taken to rails It took you know, they were basically affected within eight weeks with a little bit of help from Jeff Kissinger's Company and Jim Weirich It's also a great and dynamic community not just flattering you guys And I think that's really important because A community is really what gets you out of the trap of the sort of the autism of idiosyncrasy as well as the narcissism of small differences By choosing to use rail rails inside of Microsoft shop within the same within the same cross-functional team. It's a little odd In this case, I decided was okay because I had the support of those programmers who enjoyed the heavy contact with customer problems Those who don't like that are free to work in the services layer only Anyone who can and cares to you can move freely between the layers That's sort of the value of a cross-functional team that's focused on solving problems and not, you know What part of the stack that they're most affiliated with Then result is that we have a home for multiple types of developers where they can pursue their own vision of quality as They seek to add value to the business without compromising due to technical boundaries Generally open source is a great strategic antidote as I said to both the autism of idiosyncrasy problem and the narcissism of small differences We can all talk about the problems that we face in common without compromising on effect on Compromising our competitiveness the benefit of open source to startups is obvious But I believe we've only just begun to see the true impact of this on larger companies The future is a more open place of platforms protocols and communities by linking many firms together We've also gotten more involved in meet-ups around software craftsmanship and of course rails by sponsoring conferences like this one Overall open source combined with our SOA and unisporical strategy give us a lot of Room to acquire new teams new technologies and new businesses without relapsing into monolithism monolithism and monoculture too many monos so Despite kind of setting up Unisporical conversation and pointing in the direction of rails as a worthwhile stack I have to say that when I came down to it It was only the sudden influx of dozens of PHP programmers into my organization due to an acquisition and integration and Two conversations from my boss about my plan to use this opportunity to shift the web development focus Of my organization towards rails and away from dot-net for any of this to happen The integration of the developers happened at just the right time as we were just in the middle planning our approach to building the unisporical And I totally changed the economics of our ability to shift gears and focus more people on the unisporical in rails because I rightly argued that it would be quicker to Retrain PHP developers on rails and it would be to retrain them on dot-net or replace them The first time I brought this up was at the worst possible moment after a long and difficult conversation with my boss about a different matter I mentioned the opportunity and immediately regretted it because the flow of the conversation had just given He had in the flow of conversation He'd just given me a big concession and so he would want to take something back to compensate Which he did he closed the door on the possibility What I was arguing for would require his strong support and a lot of effort and at that point in time He decided it wasn't worth it. I Was crushed that after all my careful planning. I shot myself in the foot So much depends on timing and keeping options open until the last possible moment But 20 minutes after I left his office. He texted me and asked me to argue my case again for him next week I did that and that conversation went better. I Mentioned this so you can appreciate that despite all my plans and goals and desires The building of valuable things come down to loyalty trust and teamwork In closing I'd just like to say that even though nine startups in ten will fail and 99 and 100 enterprises might be terribly dysfunctional places to work That's no excuse That's just a small difference if your motivation is to make the world a better place for as many people as you can using whatever means necessary Find real problems look for every opportunity to solve them and above all be patient and stay positive but critical I found this great expression of the sentiment a while back and I'll leave you with it We have no choice but to go out among these alien powers which we create and to try to direct them to human ends