 Y 4waffa is is peer somebody behind the back, so now that the 18-years experience in commercial corporate forums he's worked at senior, gutes, lead and technical director level for the likes of ginger media group, Timing and Tiorconf. He's also built with online present friends such as MTV, ENEMY, that comedy central, Czech revolution. TGL has a quote for us, hasn't it, there's quite a few here. TGL is a friend, a paranormal and I noticed him best for his headline, As I found out last year when we had a drink at the pub, so what's the name of the brand you're going to go for? It was called Paris Motor. Oh it was called Paris Motor, but they're very good. They're similar to Spotify. And one of their tracks is featured on Trudeau Tech. No, it gives us Walking Dead. Walking Dead? Can you believe it? Anyway, that's about that. He's also very good at groove stuff. So let me defer the delay. I will hand you over to Paul Reed. I was going to do a brief introduction to myself, but there's been one done already. I kind of fell into web development around about the late 90s, just through someone I knew that worked in media. And I seem to have been kind of, I guess, lucky that I've sort of moved around the industry just as the particular company that I was working for was going through digital transformation. So the earliest example was Virgin Radio, which is our first employer. That was sort of, you know, 98 that I started there. And that was just at a time when, you know, we would start to do online streaming and people were moving away from, you know, FMAM models and moving into digital, you know, listening online and stuff. And then, you know, around 2001 I moved into publishing of IPC Media, which is a part of Time Warner. And they were obviously going through a whole, you know, print was dying, you know, people weren't buying magazines or newspapers anymore moving online. And then I took a few years off to do music and pretend to be a rock and roll star. And then I joined Viacom in 2007. And so that was when, you know, I first sort of started working with Drupal, but also they were going through the digital transformation there as well. You know, more and more people were starting to watch, you know, video on their laptops or, you know, handheld devices and moving away from watching TV. Obviously MTV had its own transformation and moving away from music and stuff. But I'll talk about that. So I wasn't really sure what I was going to talk about today. And I thought, you know, I'll kind of talk about some of my experiences with Drupal, I guess. I don't think many people have reminded me just about Drupal today, funnily enough. But as it turns out, you know, I'm very spiced to talk before me about collective stupidity. My talk seems to follow quite nicely from that. I will be talking about some of the mistakes that have been made throughout my time working with Drupal. And I guess that collective stupidity within large organisations is particularly appropriate. And I will take credit for some of the stupid mistakes that have been made and silly decisions and stuff. But yeah, so that's quite a long time for a talk. So I went with Drupal and I. And it's just, obviously this is purely subjective. It's from, you know, my personal viewpoint. So actually, Falcon can't sack me anymore, so I can see what I like pretty much. So 2007 was when I first met Drupal. This was MTV Flux. So this actually launched in 2006. So about a year before I joined. It was built by an agency who was relatively small agency Lullabop. Back then, we obviously went on to bigger and better things. So this is quite ahead of its time really. MTV Flux was an interactive TV channel. So it was kind of, I think it was built as the next MySpace or MySpace on TV. It suffered pretty much the same fate as MySpace. But the idea was that people could log into the website and create their social media profiles and this would then feed back into the TV. They could upload, they could make their own music videos. This went through various sort of transcoding work streams and ended up on TV. So they were building their own TV channel. I hated Drupal. I'd never heard of Drupal before I joined Falcon. I hated it with a passion once I met it. And this is, I think primarily because my background was in building my own applications. So I was a coder, I loved to write code and build things. And the idea of using a platform that someone else had built was that it would help this possibly work for me. If every situation is unique, how could they possibly understand the needs of the business that I work in? Which was incredibly naive opinion to now at the time. So I spent a lot of time looking around at how can we move away from Drupal. The version of Drupal that we're using, I'm not going to badmouth Llywodraff for the work that they did because it was incredibly ahead of its time. But this was around Drupal 4.6, 4.7. There were lots of performance issues with running at the sort of scale that we were attempting to write about. We hacked it to pieces, which subsequently meant that there was no upgrade path for us. We couldn't take advantage of improvements to the software and to the system. So we were stuck with this version of Drupal that we had set in stone around 2006, 2007. So then there was a kind of turning point for me really in 2008 when I went to a Drupal pod busking. That was the point really that I was sold on Drupal. It was partly because of seeing the improvements to Drupal 5 and how much better the system it was. There were a lot of improvements to Drupal that Viacom had actually contributed to Viacom. A lot of them went into Drupal 5. Performance was much better. The thing that really sold me was the community, meeting these hundreds of thousands of developers who were sharing their knowledge, sharing their experience, all contributing to the greater good and that kind of stuff. It made me feel less like a corporate bad guy. The community aspect really sold me on it. So we went back and started working on Drupal 5. This was around about the time of the Drupal 6 release. It wasn't quite ready, production ready. But this was our first Drupal 5 build that we released. I believe it was around 2009. It was about a six-month build with a purely internal team. We made a lot of mistakes. But we were learning and we were actually starting to understand the power of Drupal, how it can actually work for us. We had a few builds on the way. I think I've just realised that my talk is going to be really short. We had a few builds on the way, so a couple of other channels that we were building websites for. Feeva, which is running on Drupal 6. We built an on-demand, anything on-demand on Drupal 6 as well. As we started going through the versions, we realised that the core of Drupal was progressing so much that we didn't actually need to do a lot of the custom work that we had to do before. During the Drupal 5 build, probably about 50% of the build was actually spent on improving the admin and editorial experience and building those custom modules for drag and drop and all this kind of stuff. Once we started using Drupal 6, it was like, I get what it is actually. We probably showed months off the complete site build by upgrading to the latest version. There were different solutions to these problems that other people have already found. We were using Drupal on TV as well. Drupal was primarily an admin interface, putting metadata into a system, which would then spit out on TV for running little quizzes and fact lists of our brand albums. Right up at 2011 was when we started working on Drupal 7. This was our first good decision but kind of bad decision that we made into, like, you know, the rods of my bar and tablet and everything was starting to accelerate. So we needed to actually better cater for this. We couldn't get away with just greting desktop sites anymore. So this was a really good project for us. We learned a lot for it, but one of the fatal mistakes that we made was actually building three separate versions of the site rather than, you know, the single responsive version. And I'll probably cover that a little bit more later. 2012, so this was afterward done our first Drupal 7 build. When we started, these statistics here were the share of mobile users during 2012. And you can see the rise. This is just, you know, across a four month period, 1% increase, 3% increase, 4% increase. So we were seeing this kind of steady rise of mobile share. So we really, we were still running on Drupal 5, which was a desktop only site. And we were supporting, you know, sort of data feed into apps, like all the classes and stuff as well. But really, you know, our bread and butter was with the desktop site still that was years old by this point. Combined with that, the responsibility of the team had grown. So when I joined Valka, we were really, we were just looking after MTV UK. It was pretty much just one website. By 2012, we were looking after multiple brands across multiple territories. But we were also working on multiple platforms as well. So even though, you know, Drupal was our main focus, we still had to support .NET websites, Java websites and then frame across all the different brands. So we really needed to kind of try and standardise, you know, our platforms, you know, across everything. Obviously, Drupal was the answer to this. I've recycled some of these slides from previous talks. So this is almost to be like a postmortem of some products that I've talked about before. But so this is a kind of a solution that we come up with, which ended up looking really good like this. So we'd built a hub-spoke content network. I guess it was. By far the biggest challenge we had was data migration. So we probably spent maybe six, seven, eight months just migrating all that data in from all of these other sites. But the idea was that there would be a single CMS, which was running on Drupal, that all of our editorial stuff could use and then we would push content out to all of the separate Drupal websites. So this really sort of helps us because even when we were using Drupal across different websites, we'd be running on different versions or we'd build something for MTV UK and then the Viva guys would say, oh, we really like that feature, you're running on MTV. Can we have it please with that? We'll know you can't. MTV's running on Drupal 5, you're running on Drupal 6. There's no kind of portability of these features. There's no sort of parity between them. So the idea was to standardize our whole network and still have a different look and feel. But we'd have a Drupal distribution with a global base theme and then we could have brand or language sub-themes. So you could have a core Drupal site but it would actually look like Comedy Central and look like MTV or it would look like Parallel Channel. So previously we'd been looking at six month build times at the minimum for a new website and that'd be the usual working on all the admin tools and then working on the front end of the site. We were starting to get to a point where we could actually bring a new brand on board within weeks or sometimes even days if it depended on the complexity of the requirements. So we had this huge acceleration that we had rather than having a six month project for a complete rebuild. To get that down to weeks or days was incredible. Once a brand was on board we'd get to a point where we could have a new site like sometimes within a few hours and there was still a lot of manual work that was going into this. If we would have had automation in it it probably could have been a self service click of a button and there you go, you've got a new website. But this was incredible. I think the overall build time to get the foundations that this was probably around 18 months. So it was a significant investment and especially given that we were only given about three months to build this initial platform and a budget for about three months of work as well. So we went significantly over budget and significantly over time we probably worked about this close to being sacked. But you know, very quickly, I think the business started to see the benefits of everything that we put in place and it actually started paying dividends. So before long the network actually started to look at this. You know, we had obviously the comedy central Paramount channel in Romania and Hungary, Nickelodeon used it for some of their smaller sites out in Australia. We still had the occasional site in Java that would be supporting and a lot of Nickelodeon stuff was still running on Java. But across the international we started to spread this Drupal distribution out across the different brands and the different regions. I think at some point we had six brands and ten languages in 29 countries I think that were running off of a single distribution. And this was managed by a team of, I think we averaged at about five or six people in the internal team. We did have some help along the way, so Brightland helped us within the early stages of development. We also had agile collective come in and do some fantastic work with the multi-lingual stuff and wonder, wonder group, wonder crowd, wonder. Spend probably about a year with us working on the comedy central rebuild. A name that really helped us move away from that. You know, desktop, tablet, mobile versions have decided into the fully responsive themes that were still running on the network today. But touching back on that, the responsive versus device specific, I think when we did an audit for the MTV redesign at one point and we were trying to do a component on how many actual individual components that we were going to be building to achieve this. And we realised I think there was like 150 or 160 separate components that we were trying to build in a three month time period, which was insane, you know, and you'd have like exactly the same little block that would look very slightly different if it was on tablet and very slightly different if it was on mobile and then different again if it was on just, you know, a different section of the website. So it was really kind of streamlining what it was we were trying to build, you know, the core of the platform streamlining the components but also making them fully responsive. So rather than building three versions of, you know, 50 different components, it was more like actually one version of 20 different components. So it made the whole platform much more scalable. But a key role in this was the product owner. I'll give it a point of view. So our product owner really played a key role in the development of this entire platform. He was that kind of... I hate to call him a middleman because he has sort of negative connotations, but really he kind of sat in between the business and the technology teams. So he understood the business needs but understood the capabilities of the technology platform and what it was that we were trying to achieve. And we found that that role was kind of crucial to adoption within the rest of the business. We tended to do much better with the smaller parts of the business that didn't necessarily have the budget to fund their own development. So Viacom is kind of a strange beast of an organisation in that, you know, obviously it's a global organisation. And a lot of the local regions have a fair bit of autonomy. You know, so MTV UK can historically do a lot of things very different to what MTV US does or MTV France, Germany, Israel, you know. And it wasn't like kind of warring factions or anything like that. But each individual market had its own needs. Some markets were sort of paid TV, some were terrestrial TV. So the idea was that even though you had these global brands, the local teams could really adapt those brands to fit the business needs of the local market. And this resulted in the markets or the territories that had, that were generating more money tended to have their own tech teams. So the guys in Berlin were using Ruby on violence. The, the Milan team were using, I think, a mixture of WordPress and then later Symphony 2. And then all of the guys in domestic were even, you know, even though that was North America, you would have Nickelodeon who were using Java who later moved on to Node.js. You'd have MTV that were using a mixture of Java and WordPress. And Comedy Central was using a bespoke PHP framework that had been homegrown and, you know, developed over about eight years or so internally. So you had this real mix across the entire network. There was much more of a move towards globalization. We wanted to kind of standardize willing to be able to share things, not just within, you know, local reasons. You know, we've already seen huge benefits like we've developed a feature for Comedy Central in UK. And the MTV guys have said, that's brilliant. We really want to be able to use that. And we'd just be able to enable it on their profile. So suddenly, you know, rather than having to, you know, have a small team of four to six people who had to prioritize, OK, this month we're working on MTV. Now we're going to be working on Comedy Central next month. We could say, well, hold on. We're going to, developmentally speaking, we're going to be able to roll it out across the entire network. So we were seeing huge benefits for standardization. But I would have plus the business to sort of more difficult, I guess, to try to persuade into our way of thinking. And so this became really evident when there was a change within the organization to make it more that we're going to have a global engineering structure and a global, you know, IT structure across the whole of Ireland. And so all of the different systems, all of the different regions were kind of, you know, evaluated. There was the Drupal system, you know, Ruby on Wales. Some of the Java systems were sort of evaluated as well as that. OK, what is going to be the standard platform that we use across the entire organization? And this is when one of the things that we found that actually what we ended up creating was this monolith, this, you know, even though we had this kind of network of sites and, you know, we had this separation between the front-end and the content management systems, it was actually that the dependencies between everything was incredibly complex. We had a severe lack of documentation, which is, you know, one of the, I guess, downsides of being such a small team was that, you know, it was all hands on deck to roll out new features, get new things built. We very rarely stand any time of documentation. And a lot of time we felt that we didn't need to because we were just talking amongst ourselves. If you didn't understand how something worked, you could spin around and say, hey, how does that work? And he would tell you, or he would pick up a task for you. But it was also a lack of automated testing as well. I'm looking again at Luke because we had several fights about automated testing. But early on in the sort of lifecycle of the platform, you know, we could get away with doing manual releases and it might take us a day to do a manual release, but we could get away with doing that because we were working on a handful of sites. But we'd be, you know, relying on someone noticing if there was a problem. So because we had this kind of shared platform that was going across all of the different brands, you know, what tended to happen is that you might be working on a feature for MTV Australia and then accidentally that feature would go out across only central New Zealand, you know, and no one would notice maybe for days. And then someone would pick it up and fix it and work around it. But really kind of automated testing would have played a vital role in actually stopping those mistakes from happening. But the other sort of downside of the monolithic architecture that we created is it may be very difficult just to work on one part of the system. So, you know, if you were working, because there was shared code between the central CMS and all of these front-end sites, if you were working on, you know, have a new feature or an issue on the CMS, that could accidentally leak out into the front-end as well. So you really needed to understand the entire monolith to actually just work on a very small part of it. That became a huge barrier to adoption as well, you know, so you'd have non-drupal teams that would come on board that wouldn't just need to learn how to use Drupal, but also then need to learn, you know, what it is that we've created, this piece that we've created with Drupal. And also from a support and maintenance perspective, this resulted in, you know, the core development team handling most of the support. There were, you know, teams that were set up within the organisation to handle front-end support for you, but you'd have to give them a run, but you'd have to say, if this is this problem, this is how you can diagnose the issue. And to do that, you needed to give them the Drupal manual, and then the Viacon Drupal manual, you know, to kind of debug any issues. So it meant that the core development team actually just got done doing the support stuff and day-to-day running of this entire network, which, you know, it kind of resulted in not necessarily, it wasn't necessarily a stagnation of development, but certainly meant that we were spending a lot more time sort of debugging, you know, small issues, but we actually could have been, you know, refactoring or, you know, improving the entire system. I'll use this slide because it's probably one of the most used Drupal slides. This is the Drupal learning curve. I don't know how many of you know this Drupal already. So this is in comparison to other kind of CMSs and you've got, like, Joomler and WordPress, and Drupal learning curve is somewhere like this, and a lot of people kind of suffer a horrible death when they get near the top, which is a real shame because actually Drupal as a platform is built in such a way that you can actually be productive at any step along this way. You don't need to necessarily learn all of Drupal to be able to be productive with it and to actually have an input with it. You know, you can have, obviously, your editorial team, they don't need to know how Drupal works to be able to use Drupal as a CMS, but you can also have site builders as well who are using, you know, drag-and-drop tools to actually reconfigure site. Our product owner wasn't the developer, but he often used to help us out with site builds because he knew how to use panels which is the drag-and-drop interface for site building. So that kind of... It meant that you didn't have to have all of these Drupal rock stars and ninjas who knew everything about it to actually still roll out new sites. So, as I said, this became the real barrier to adoption for non-Drupal teams. You know, you had guys who were used to using, you know, Node.js or something, and they were very front-end developers that just used to work with templates, maybe some JavaScript. All of a sudden, they needed to know how to spin up a virtual environment for local development. They needed to then know how the local CMS worked before they could start creating content and that's partly due to a way that, I guess, a flaw in the design to the HubSpot model is that the Hub was responsible for pushing all of this content out to all of the spikes, to all of the websites. But there was no real way of you getting a front-end website saying I want to pull this content. So a better way, I guess, for refactoring that, would have made it more like a sort of a pub-sup, what's called a pub-sup model where you have publishers and subscribers so you can have front-end sites that actually pull the content that they need from their central hub, you know, central content hub. So, yeah, it became really different or even for Dupal developers to work within our system because suddenly they needed to know how does the CMS work. You say, I don't care how the CMS works, I just want to work on the front-end, but you need to know how the CMS works so that you can push the content easily on end and so you can do all of this development. All of these other teams, as I said, they were still running on different technology stacks. They were running on Symphony, Node.js, Ruby, WordPress, so that bespoke PHP framework. And they bespoke PHP framework that they were running in a company central out of New York. Even though this was kind of eight years old, they continually evolved this. So they had moved away from their procedural code and started using object-orientating stuff. They had moved into more of a sort of service framework rather than building these models. We were still running Drupal 7, which at the time was approaching about five years old or five years since its official release. So we were desperately trying to sell Drupal and the technology. Not just Drupal as a product, but I guess the ethos behind it and the whole collaborative platform versus a silo platform, collaborative approach to solving problems rather than just keeping it within your own team or within your own head. The solution was presented to us in a dream. So Drupal 8 really became this kind of solution that we that we wanted to adopt in that a lot of the difference between Drupal 7 and Drupal 8 is that Drupal 8 is kind of built on a Symphony framework and it's more about interoperability between other platforms. So you can have some PHP components that work with Symphony as well as Drupal, and it's not just you don't you don't just need to know how to use Drupal to be able to use Drupal but you can come from other PHP frameworks and it's a little bit more open to outsiders coming up. Here's a lot more complex but in different ones. So this solution really was a little bit too late we never actually got around to building Drupal 8 unfortunately but while we've still been shawing up the issues that we'd had with Drupal 7 a lot of the time it was spent debugging and keeping the system running we didn't actually because we moved to we were too late to make this move to Drupal 8 so ultimately the bespoke PHP framework and I think Node.js were the platforms that ended up winning out across Drupal Drupal is still in use across VARCOM International and it's still the same platform that's running up, it's about a year now since I left but a lot of the stuff that we've put in place is still running but it was a little bit too late so I'm trying not to be too negative I hope that the person who sits in the room and finds the problems and everything the slightly negative one I tended to be that one in my previous role but I do think it's important to be reflective and to have to look back on are you making the right decisions here rather than having that confirmation by us that goes on so being slightly positive so a few conclusions from all of my experience here document everything and don't just document what it is that you're building document why you're building something document decisions that you've made because there's so often you come back to something so I don't understand this why has it been built this way and once you spoke to the person who built it three, four, five years ago you'd maybe understand that this is why they've done that if that person was left in spirit and you haven't got an idea and you're going to end up deleting that you're just moving on automate everything that you can so repeat all tasks you should try to align this build day for us which we used to happen once a four it was one person who used to sit there for an entire day probably ten hours doing a release across the entire network sitting there waiting for a a build to finish by hand making sure there are no errors and then move on to the next slide once we automated this integration model and developers became responsible for doing their own releases and it was just a huge saw in productivity avoid monolithic architecture I'd say it's a it's a huge thing especially if you're building large complex systems large complex systems break them into smaller much more manageable charts ideally you need to get a point where you don't need to understand the entire system to still be able to contribute to that system so there's a lot to about Headless Drupal this is a prime example of it separating your presentation layer from the content management side from the back end which enables doing something like that enables non-drupal developers to still contribute to the platform that you're using they don't have to understand the guts and bounce of everything that's happening there they're just working with these front end templates and that kind of stuff make data migration a first class system I probably didn't talk about that enough earlier but data migration has always been the biggest headache in any kind of rebuild project or any onboarding project it needs to be a first class system you need to be thinking about this upfront doing your content modelling right at the very start and start your data migration before you start building any features that are going to be used in that data you have to get that update and making sure you can do top-up migrations as well investing your team I think we were actually quite lucky within MTV at the UK and we had a lot of support from our local senior management and it's not always about hiring rock stars and ninjas and that kind of stuff it's about hiring the right people for the job hiring people who are going to analyse the problem and find a solution to fix it rather than, as Andrew was saying about that sort of the instinct to just throw a solution quickly against something trying to find people who aren't necessarily the most experienced in terms of skill they might not have been working on PHP platforms for 10, 15, 20 years or whatever but having that rock kind of attitude do ability to analyse a problem and find solutions is crucial and giving them the space to learn and grow and experiment as well allow people to make the wrong decision and using this sort of agile approach makes it much easier to make the wrong decision and hopefully recover from it because you're doing small iterations towards platform and if something goes wrong you can change course it's important to be able to make mistakes like anything right first time sometimes you do get lucky but if you become scared of making your own decision you have this decision paralysis and then you have that tendency as I have to say I keep referring back to his talk but you kind of foster that culture where people don't want to point out mistakes what is the conspiracy of silence that kind of happens and I think it's important to involve your team in decision making as well even though I talked about some of the reasons why I thought Drupal 8 wasn't adopted across Viacom as an organisation there were probably much bigger decisions in play that I just wasn't part of I was relatively down the food chain in terms of those kind of decision making there were probably factors that involved the fact that it was a broadcast corporation that had enormous systems that were running all of the broadcast infrastructure and legal and finance kind of structures and everything that all of them needs to be integrated with I think partly as well there was a certain culture within Viacom US of building their own things as a broadcast company they used to build their own play-out settings which to me sounds insane but I'm kind of sold on using community software I think involving your team in those kind of decisions at least means that they understand why you're making these decisions rather than people are crazy I don't understand why you're doing this which used to happen quite a lot and finally I'll say contributions to the community I think is key really contribution is a really good way to learn a system rather than just using it going back to Drupalcon Boston 2008 when I first became involved with the community that to me was invaluable as a learning experience because it allowed me to talk to core controllers and end users of Drupal as well all of the different people that we use in Drupal in slightly different ways that had all of these slightly different use cases to how they wanted to build something it meant that I'll use an example from VACOM there was an internal content management system that was all built on Adobe Flex which I don't know if anyone remembers this is kind of a Java based browser sort of thing terrible but when we started showing the Drupal 5 tools that we were using in this kind of functional and everything they were kind of amazed by this and they come back a year later and say ok we've done some upgrades we've got that drag and drop thing that you've asked and it was kind of a little bit alien to us because we've got so used to doing a whole lot how do we solve this let's look on Drupal, is there a module for this or yes there is, chances are probably nine times out of ten if not more that you will find a Drupal module and you can solve that particular problem for you you may need to customise it a little bit for your use case but if you look at Drupal.org there's tens of thousands of contributing modules on there and they're not just modules of code, these are solutions to problems that other people have found and said I've solved this problem, this is here you go, you don't have to resolve this exact same problem again so contribution could be really great for learning as well as an example just a final example about two days ago I was working on a Drupal site for one of my clients and I ran into a problem where the database would start crashing every time they tried to insert an emoji it might have even been the poo emoji I remember so I spent a few hours trying to diagnosis and try and work out what was going on I've solved a sort of worked around the problem wouldn't say so I worked around the problem when I was a varchon just by stripping out all the motifs but I did some hunting around the site I'm going to try and solve it this time I spent a few hours googling and looking at different forums and all of this kind of stuff and then I finally found the solution to it in a thread that I created two years ago on Drupal.org which is the first issue that I contributed to on Drupal 8 and it was to do with UTF 8 MB4 character set so the ability for the database to support multi-byte characters which is what the motifs are so yeah it turned out that I'd actually found the solution two years ago contributed to the community and then found that same solution for myself two years later so I think that in a nutshell really is how contributing to community can really help actually help in yourself if you build your own platforms and your own software within a silo once you don't need that anymore that's rn-rf that is going to go straight into the delete bin and you're never going to see that part again but actually contributing out to the community it will even give back to yourself in a few years time when you need it I think that's about it so if it is a little bit disdain to do that any questions Thanks so much Paul So I will do the road here Thank you very much Paul If you could go back in the time machine to 2008 what would you tell the previous version of yourself based on a 50-year-old Definitely don't hack the core never hack the core I think it would be I guess collaboration was the key thing because I'd spent so long being the one who builds your own systems and not really working with other people and being the one who comes up with a solution to a problem I think collaboration would be the main thing that I would have told myself back then make sure you're collaborating with other people make sure you're working with people who know vastly more than you do which is what very happens when you get involved in a community like Drupal it's incredibly smart people there who know so much more than you do and you can learn by day you can learn from some of the mistakes that they've made but also amazing solutions that they've had to problems so definitely collaborating So you're just interested if you could look back when should Drupal have not been the answer because we've got some about 1700 Drupal sites some very complex distributions in there as well and we're in the picture of Drupal being the answer to everything when I know it shouldn't be I've been in that exact same position before and in fact in Barcom I think I'm pretty sure there was some senior management at Barcom that were just saying please just stop talking about Drupal because we used to use it for literally everything we had it for powering TV systems and graphic systems and that kind of stuff I guess if you're managing content then Drupal is a perfect solution I guess if you're not managing content then maybe that's the point we should say should I be using a content management system things like static sites and microsites if your content is very rarely if everything is going to be changed I would question using any kind of any kind of content management system for it and I think that was the idea behind the way that we wanted to move within Drupal is that we wanted to build this ecosystem of components that could work together to solve the problem rather than having this a normal sledgehammer and everything if you love the name you would have this kind of toolkit you can have a front-end sort of theme that isn't necessarily dependent on any particular platform you might be able to use static sites, microsites or whatever but then if you wanted to have some more complex application logic you might actually use that front-end theme with Symphony or Laravel or something like that and then you could upgrade it again so if you want full content management you could use that same front-end theme the same components and the user within Drupal in a fully managed content management environment so I think specifically talking about Drupal for sure if you use a content management system or if you have some sort of administration system that you can be building that's storing that storing configuration or something then Drupal could be a good candidate for it but I think if you can move towards that sort of interoperability it means you haven't got to suddenly completely ditched Drupal and use something that's a bit different you can still have these familiar terms and use the right one appropriately does that help? You just write a lot of websites across languages, continents and it looks like a really complex task for sort of price for what were the biggest challenges that you have that is not related to technical difficulties like for example content introducing or hierarchising organisation what are the biggest troubles that you have when working on all of these projects and what were the solutions or lessons that were learned? From a technical perspective it was definitely data migration as I said before during the initial build of the platform we were only migrating one site over to this platform which was NTMUK ended up in an 18 month product at least six months of that was spent working on data migration and we found that we'd built things and then we'd migrate data in and actually the things we'd do would have to go back and do it all over again so data migration for sure the multilingual stuff ended up being surprisingly easy to work on you know, Ducall has excellent multilingual support I think we were one of the more complex ones working with NTV Israel which was all Hebrew right to left, none of us read Hebrew and so that became quite difficult to actually work out what the hell it was but we were building if everything was actually working the way it was supposed to so, but yet for sure at a technical level data migration was quite fine at the end I mean, star guide driven development I think is exactly the way that we wanted to go we never quite got that with it we were working towards it and we started iterating towards this but using star guide driven development I think is key to having this building a large system I think I think I dread the day when I ever have to work on another project where I get presented with 20, 30, 40 five shots of complete looking pages when you're designing a platform you're not designing pages, you're designing a system of components of how your plan is going to be presented and having a final PDF of what a page is going to look like I think is no way to start a project for sure Do you have seen some of the stuff you talked about from using the ASS to try and promote that process? I don't have an personal experience but I'm afraid so it was a ways that we knew that it was the place that we wanted to be at but we unfortunately didn't quite make it that far I know we've done it with the hashtags I think they're just about up at the moment Yes, if you can read the tiny writing please use the hashtags and continue the conversation online but thank you so much for your time Thank you