Stefan Tilkov - Why software architects fail – and what to do about it

[Music] [Music] [Music] [Music] Darkstar starting soon please take your seat talks are starting soon thank you [Music] [Applause] [Music] what it has been a stressful day and until the EPROM party there is quite some time to go no I'm gonna wait until the party and you guys also should join the party right there so if Pam is gonna treat us well today with some tequila maybe whiskey lots of beer good DJ's life music all that you want okay I'm gonna one time no what are you guys sleepy come on we still have a couple of talks to go until the party all right so we continue our discussions about human failures or system failures but now we are going to concentrate on the human ones so it's rather a hype topic these days go fast break things fail often learning it but there are some mistakes that could be actually avoided so our next speaker will tell us about all of those mistakes and what you should know about them and how to avoid them please say hi to Stefan till Goff thank you very much for the introduction so yes I'm gonna talk about human failure I will be talking about my personal failures to make you feel a little better about yourself because of course none of you will ever have done anything like the things I'm going to talk about right I'm not talking about you I'm talking about all those other people who make those mistakes right because you folks would never do any of that so I'll be talking about Software Architect and some of the failures that they run into originally or alternatively I had the title diseases of sorry diseases you should know about but then I thought this is a little maybe this is this would bring a whole crowd down even quicker so I thought let's talk about failure as opposed to diseases and then I thought well but disease is probably what it feels like to most of you when you do it so I put in the alternative title as well and if we talk about diseases this makes sense to look at what it actually is we're talking about how that might apply to the things we're doing in our daily lives the software architects or as developers who are tasked with architectural tasks so if you look at the definition of a disease then that is something that is as you expect an illness right some sort of tendency that can be observed by looking for certain symptoms and that's an analogy I'm going to draw on quite a bit it's also in this obsolete use a lack of ease and a sign of trouble which i think is also true for many of the things I will be talking about so view this view these as potential pathological conditions that you might or might not observe in other people and my first one and one of my favorite ones is this one so what I like to call the over generalization drive and I don't know whether any of you have experienced that at any point in time but it's it's observable when you notice that people seek commonality in everything everywhere and they look for ways to solve problems once because then our lives are going to be so much easier now I personally went through a number of phases and tell me whether you recognize yourself and some of that when when when a young developer finishes school and starts developing things they're typically enthusiastic right because this is finally the time where they get to prove their skills to the outside world right this stuff is cool I spent so much time learning about all those fantastic technologies all those methodologies all those programming languages and patterns and now I can finally put them to good use right so you start your job somewhere at a bank or software development shop or wherever and you find out that what you do day in day out looks a bit like this and then you notice that this is actually pretty boring and then you notice that maybe real people have boring problems now that might turn into a problem because that is not what you signed up for right and so you become a disillusioned developer and you're really unhappy about your life maybe you made the wrong life choices maybe you should have you know studied economics or something like that but that sounded way more boring back then but then you discover something you look at this and you squint a bit you see wow wow I'm on to something here actually this is something a little more abstract I can actually solve this problem if I solve this particular problem once with a generic solution then everything's gonna be cool again right because my life is gonna be so much better and that's when you turn into the enthusiastic architect which is a very very critical phase in your life right if you're a developer this is where you can wake and do the worst things to other people and systems around you and you can really ruin people's lives and make them miserable so we have a whole set of things to to counter that that particular set of symptoms right you have things like keep it simple and super keep it simple stupid you ain't gonna need it don't invent something now that you may or may not need in the future because there's a high likelihood you won't right has happens with almost all of those very cool solutions if it's cool then it's a bad sign we have the whole lean movement which suggests that you maybe gather some data on whether that thing you're thinking about is axe a good idea right so you start with a little experiment and once you notice that it's actually being adopted then you do that more often we have this whole concept of a minimal minimal Viable Product right something that you can that you can try out in that particular regard would be something that solves the specific case first we have this focus on stories that deliver user value and those are all very good things if you want to view them negatively you could say you're now in the disillusion architect phase right well you notice that all those cool things that you looked at in the past maybe aren't that great of an idea there's a there's a very old but still very good blog post by Joel Spolsky that talks about architecture astronauts it's sort of the same idea right it's like it's there when you talk to people who are so far away in space they have no real connection to the real world anymore they have you have discussions with them that are mentally they're intellectually very very satisfying and challenging and also completely pointless right because they solve a problem that nobody actually had so hopefully at one point in time you turn into what I like to call the wise architect and the wise architect has a very good strategy whatever the question is there's just one answer right which is also the standard consultant answer right if there is no such thing as as something that matches every particular set of circumstances so you have to look at the actual problem and then make an actual decision and select a solution that matches this particular set of circumstances now related to this disease that I observe that I still observe quite a bit in my environment is one that I like to call the main allergy it's slightly related it's it's related to the fact that many people would really really like to build operating systems or maybe cloud platforms these days used to be operating systems or databases and my day announced probably some cloud monitoring solution right the domain itself is sort of a nuisance right you happen to work at a bank but you didn't really want to look at them banks use cases you wanted to look at something that's technically challenging right so don't waste your time with that stupid business domain stuff and it's related to the generics in because what people end up building or believing is that what you need is something like this it's what I like to call the generics thing machine it's it's this it's this magical solution that that can manage everything and I've seen them in many in many forms it's when you have something that actually doesn't do anything specific and it is it's related to this generic thing but it also has this idea that the you know the the actual the actual domain logic will just be a matter of configuration right once you have this perfect thing then you'll be very quick and you can just configure something so it's 80% of the functionality and built into this into this generic machine and then 20% will be very easy to do on top of the problem of course as the old joke goes is that those 20% will actually take you a lot of time now that is just part of the problem to me the most the more important part of the problem is that there is now this thing standing between you the developer or the architect and the actual customer or stakeholder or end-user right they don't care for your thing they don't care whether you use kubernetes on AWS or if you use something on a juror or whether Google's your choice or whether you prefer in those sequel database to our DBS you know all of those things don't matter at all to somebody who actually wants to use a usable piece of software right so very often we waste a lot of time with this generic thing I've been in projects where there were months spent on deciding which platform to use or build or which ESB or just to be application service and these things just cloud platforms and schedulers and whatever right this is not something that delivers value to actual end users and sometimes I have a feeling that it's pretty good if you have something that takes these choices the way that sort of makes these choices for you right it used to be the case in the Microsoft world I think they're long past that but if you they used to be a day when if you picked the Microsoft stack it was everything was just set up in a certain way and that was the one way you used it it used to be in stills to certain degree to for Ruby on Rails it's also true for it for you know commercial off-the-shelf software where a piece of software may it may just not give you the freedom to debate a lot of things right so you might be you may be forced to use some crappy environment and not saying any of these is you've may be forced to use some environment that you don't like with a very restricted environment but it also keeps you from discussing the structure of the directories in your build system for six weeks right you just start delivering value quicker now I've talked about this the dangers of of overgeneralizing right of building generic things too early but of course there is also the opposite thing and that is that you really really think you need something absolutely special for this particular set of circumstances right if you believe that your problem is so so specific that nobody could possibly ever have thought about it then you're you're sort of in the India on the other side of this of this problem space so there's an old anecdote that I love and that you may have heard me present before which is this little problem here it's a if you look at it's a pretty simple programming problem it's something that you could maybe that that might it might be assigned to you as a and as a class project or something like that right you read a file it has some words in it and you count the the frequency of those words and then you print a list of the most frequent words right that's sort of a pretty normal kind of assignment for a student maybe and these two people who really were not student at the point in time took took a hit took and took it took this challenge and try to to find a good way of doing that now Donald Knuth that's the person you have those awesome books in your on your shelf that you never read right so Donald Knuth is probably the best computer scientist the world has ever known probably will be for awhile and he of course solved this problem by inventing a number of algorithms and data structures on the fly and writing a 10-page literal Pascal program that was a thing and it still is a thing of beauty right it's it's fantastic it's like literature it's it's mind blowing really great and this other person solved the problem like this and you may notice that this is the actual program which has as many lines as the description of the program on the left side now of course this person on the right I can explain of course this is right this translates all the uppercase letters to lowercase letters and then you know at first it it gets rid it puts in line breaks and then it translates upper case lower case letters and it sorts the stuff it counts it using unique sources sort it sorts it in reverse numerical order and then it prints it out in a nice way and that's of course all done using standard unix commands and of course dr. McCulloh is not anybody this is the actual person who invented that pipe thing right so it's it's the message here is that sometimes you can just compose generic things usable things standard things to build something very very quickly as opposed to building a very very specific solution now what inhibits us from doing this is believing that we need a perfect match it's a search for perfection right we want to have the absolute perfect thing that matches what we're doing right now I'm not willing to sacrifice anything but sometimes that's the wrong approach right so between those things between this generalization over generalization over generalization that I talked about in the over specific overly specific approach of course common ground is in the middle and again it depends standard answer I think we've been through that so moving forward something that I see very very often is an attraction to complexity it's as if we as if we want to have stuff that's hard right we're so smart we don't really want to do any of those simple things right simple things are for other people which is really a sad view of the world and this is probably the one where I'm where I get the most negative because I really I'm really not comfortable with people seeing this all the others have sort of a good and abet side this I think has mostly has bad sides because there are benefits of complexity but I'm not really serious about any of them right so maybe challenging work I know that work should be challenging but we shouldn't make it more challenging than it already is we should look for the actual challenges that deliver or that that keep us from delivering value and not invent challenges so that we have something fun to waste time with right it may be a new and interesting experience which I also like so maybe look for interesting challenges out there but don't just invent them because because that's the only reason for doing that self-esteem related to that being only wanting to be part of a community is also a very common and also a very bad reason I think you just want to want to apply this solution because you think the people the other people who apply this solution are kind of cool and you want to be part of the cool kids I don't really think that's a good idea you also may want to create a barrier of entry make it hard for others to do your job also another very good idea because while it may seem as if this creates job security in the end you might hurt your employer you might hurt your organization so those are all not good reasons for doing any of this so I think complexities are a number one enemy we should try to get rid of complexity where we can and sometimes you can't because sometimes things are complex right but that's that's then there's a good reason for addressing diversity there's enough complexity in the world we really don't need to invent any of our own and now the next one to me is sort of a very very German one so I'm German and I don't know about Hungary but in Germany it's very very common to take a long long time to make sure you really really arrive at the right decision it's got to be the perfect decision so that leads to this right sometimes it takes longer to evaluate something then to actually do it or then it would have taken if we'd actually decided to do it instead of talking about what it would be like if we did it one day so my number one thing of this is the vendor selection process and again I don't I don't think any of you work in organizations where something like this could possibly happen but I've seen that occasionally and this works like this right you have some tool or some platform or vendor to choose these days this is probably a cloud vendor right so you you run around or maybe maybe it's a piece of commercial off-the-shelf software even doesn't really matter you go around and collect requirements in the worst possible way which is you have this you have your laptop or maybe a piece of paper and you walk around and you ask everyone and everyone tells you all of their wishes everything they ever considered a possible thing that might be useful someday and you end up with this list of like 2500 requirements and then you do some market research right this is of course takes a while but luckily we have a process for that we've done it before so there's a process on how to do this we conduct some market research and then we come up with a list of vendors that we want to get involved in this whole thing we send out a questionnaire to them and then we evaluate the responses and then we decide to maybe create a shortlist just pick three of them and do a prove the concept kind of project with them and then we evaluate the results and then we recommend the whole thing by now we were like half a year in and then our CEO decides to pick somebody else now again I'm not saying this has happened to any of you but it's a pretty common thing if we started in week zero to just do it with the risk that maybe we'd have to throw it away after six weeks then we'd still have been able to build what four or five of those things in the same amount of time and this analysis paralysis thing really drives me crazy not as much as the complexity thing but I really hated that this happens sometimes you just need to do something so let's move on innovation addiction that is something that I find fascinating and that I observe in really really smart innovative people because what they like to do and again there may be some of you in the audience I don't know what they like to do is they like to play with stuff right they like to try out new things and that's a good thing I think you should try out new things it's really really boring to not do that you should look for interesting new technologies interesting new products you should take a look at them and you should play around with them the problem though is that if your main motivation is this this playing around then things become less fun during the course of a project right because there's a time for playing around and there's a time for just you know sticking with the stuff that you have and learning how to use it correctly and then maybe just build something as opposed to looking for the next day and it's sort of related to this fashion trend in our industry I like to call a conference driven architecture because I think that's something that is is a nice quote to use at a conference it also is something that you can see happening in in actual real life right people go to a conference and obviously there are some trends at the moment some things that are being discussed let's take some arbitrary example let's take I don't know micro-services which is something that I like a lot I like microservices I'm a big fan of micro-services but if your only reason to use micro-services is because they sort of feel that's the thing to do these days then that's not a good reason right so don't use that as an excuse I love this post by Dan McCann late it's called choose boring technology and for some people that is that is the best possible advice right choose something that is boring because for people who never choose something something boring but this can sort of bring them back to - to the idea that it might make sense to use something that's mature and proven and has been used a lot of course again this is one of those things where depending on who you talk to and depending on where you are on that on that scale you might end up having a very very different view on this so I have another anecdote for this one of my colleagues Janet rocket did a conference talk at a conference that was that as well in his talk he said stop looking at Google stop looking at Facebook stop looking at Amazon on Twitter you are not Google Facebook Amazon on Twitter unless you are but most of you are not right stop looking at those people for inspiration stop looking at new fancy technology no sequel databases and that was new back then long long time ago so whatever is new I don't know what's the single-page app framework of the week I don't know whatever it is that you that you think is important and instead focus on learning the basics focus on learning how your database works focus on learning how to use sequel correctly because that's gonna deliver more value than looking at them and that was a very good talk and it resonated well with the audience and then that exact same audience stayed in the room and I came on and I said look at Google look at Facebook look at Twitter stop looking at Oracle or IBM for inspiration sorry IBM right beep that the problem here of course is that depending on who you talk to some people really need to be reminded that there is a world outside your standard vendor and other people need to be reminded that not everything that's done by Google is great automatically right so you have to sort of find a find a way between those things and a good approach suggested suggested in this post is this idea of an innovation token that is the idea that you limit yourself right like you say in this particular project that I'm starting now I'm allowed to do two things differently so I can I can try out maybe going to the cloud for the first time and using a different persistency strategy but I can't also decide to do the UI a completely different way or to adopt microservices just so you get to you can spend two coins but that's about it and that's I think an interesting mental mental model for for limiting yourself to a reasonable amount of complexity within your projects okay this I think this is one of my favorites because I think it's the root of many really bad architectures in practice and that's this fixation on something that you already know which leads you to tunnel something through another solution now that's just for the proc people in the audience let's go over this the ideas that you look at something that's new let's say you pick up a new sort of framework a new sort of library and it's really very different from everything that you've done in the past but that's a problem because the thing you've done in the past is something that you know very well it's also obviously what works right is this newfangled stuff it may be new but it still does things possibly different or differently from what you've done in the past so you might end up trying to force the old paradigm the old model the old way of doing things onto this new thing and we can observe that in a whole number of things like for example when people try to do that thing called web services does anybody remember that I'm not talking about you know what we call normal these days restful HTTP JSON over HTTP kinds of things I'm talking about soap whistle XML web services that was a thing right not all of you are too young to remember that that was a face where people try to force an old model the core of a model the core ba RPC model unto a changing environment the web and let's say it didn't work out too well and we can see the same thing over and over again people try to build desktop apps except they run in the browser now people invent and reinvent the whole the same things they're used in the past always again and again using using some new technology and it's a related thing which is then that something is done by somebody so we'll just have to do it because it's these people who do it right it's like we it may not even be us who are doing this its others who are doing the same thing and now why am i mentioning this here often this is a sort of a second-degree problem it's not use doing the tunneling it's somebody else who does let's take an example there may there when they when the alternative databases came around first or became popular again people were looking for ways to use them and some people decided well we just use our our existing ORM model and just map that to this new technology which is simply not a good idea I mean you're using this you new thing because you want to have its new features if you were happy with the existing features of the old thing then you wouldn't have changed it sort of makes sense right so people some other people typically make those choices people give you something that promises to to keep the keep the change minimal they deliver something that you think will allow you to keep your investment and that is something that especially big companies like a lot so if somebody comes to a big company says well I can use all your COBOL programmers they don't have to learn anything new they can just do the same thing they've always done and they'll magically deliver something that now runs on top of whatever or language you fancy and that's something that you should be skeptical off but if you're a manager you typically aren't because it just sounds too good which again proves that if something sounds too good to be true it often isn't true but anyway I digress let's move on to the next one the next one is sort of again related or on the opposite end of something that I mentioned before it's when you have something that you've invested a lot in and that thing becomes sort of your standard hammer and everything looks like a nail so you become attached to something that you you automatically apply it whether it makes sense or not it doesn't really matter right so you've you've become an expert in let's pick something that nobody likes I don't know I'm but the name company names this is live stream right so I won't do that so let's just say there's a huge enterprise IT vendor who sells a BPM solution and maybe that vendor is red or blue take your pick and then you become an expert using this particular BPM solution and then you apply to everything and that leads to horrible systems where people implement things that could be a 20 line Python script using a clustered process engine environment as the solution right it's it's a risk we all face because we all like our expertise we all like being experts in something and it's a very good thing and it's a very good feeling if you're if people come to you and ask you for help and you can answer all those things it's pretty hard to say well I'll just throw it away it's like it it's like a comedian throwing away all these existing jokes and starting fresh right it's always a risk but it's sort of sometimes needs to be done related to that is this exaggerated risk aversion right we're we're sticking to stuff and sometimes the stuff we stick to is really really horrible I've seen I've seen things maybe you've experiences maybe you've experienced this yourself you come to a new environment and somebody explains something to you like this is how we do things around here right so if you want to make that kind of change this is how you do it and then you look at it closely and and or shake your head in disbelief because this can't possibly be true it can't possibly be true that people have accepted this and think this is kind of okay so you start arguing and you start hitting walls and you start discussing things with people and then you sort of grows that's one way to phrase it doesn't grow on you you sort of don't really care that much anymore and after a while that's just the way you do things and then this new person comes along and you explain to them that this is just the way things work and they look at you in disbelief so these things happen for four years you can see people who lift with my favourite example a a build where the build of the system took 26 hours and that's kind of a normal thing that people accept those kinds of things unless somebody shakes them so maybe you should be the one doing the shaking occasionally and this is related to one of my favorite favorite talks I'm gonna mention pretty soon this this confuses confusion or confusing of easy with simple right sometimes sometimes what's easy to do right now is what's actually the hard thing what's actually riddled with complexity that the hard thing is often to do the simple thing so again an example from this Web Services world maybe some of you experienced that is when you're in a in your IDE and you have a class and you hit the right mouse button and say generate and deploy web service and then something happens and lots of code is generated and some runtime environment gets fired up and something gets deployed there in some message you have no idea what you're doing but it was very easy to create that in that setup to create that system so simple and easy complex and heart are really things that you need to contrast and talk about for a while too where you want to spend your energy and there's a fantastic talk by rich Hickey the inventor of culture about this whole thing it's related to language design of course but that's not really the essential point here although closure is a fantastic language but the talk is worth watching because he addresses this particular topic very very nicely and talks a lot about how simplicity should be something to strive for and how that might mean that you have to do something that is hard right now little plug for my second talk I have a talkie immediately after this one which is what I'm gonna run it run away once I once we're done with this to another place it's a blue tent or something and then I'm gonna talk about even more human things and one of the one of the things here is that this simple and easy complex and hard thing is also something that's very human in general right Isis relate it's related to our feelings and our to our self-esteem and self-worth that sometimes playing with this complex stuff gives us satisfaction that is a good reason and it's really hard to convince people that something else is better and this might turn into something that you will find hard with your colleagues we all view our managers as the bad people right it's always our managers who keep us from doing reasonable things it's never appears it's never ourselves but sometimes it's our selves and our peers who create complexity and who make things unnecessarily hard and they if you if you want if you wonder your peers your colleagues to accept that you have a harder work that you need to work more because the end result is going to be simpler that might be a tough sell you might have to need some better arguments for that this is another one and the last one in my list actually an article impact dissonance this is really something related to the architect's role is particularly prevalent in people who actually are architects as a role and have that on their business card somewhere it's related to being too detached from the actual system and so it's related to this megalomania because sometimes you think that you're so important that everybody absolutely every has to consult with you first before you do anything reasonable and meaningful and that is I think related to the role of the architect in general so I'm not a big fan of having architects as or having an architect as an explicit role I think it's we have architectural work very often but I admit that sometimes in bigger projects and bigger organizations you end up with people who only fulfill things in that role so they might end up being actual architects so what architects want to do is similar to I think everybody they want to do good things so this is maybe the view an architect has have the view architects have of themselves right you want to you want to be involved with the important things I think if you if you adopt this architect role then you care about stuff you want to want to be influential you want to do if you want to be impactful right so you want to shape strategy of your organization or if the company or of the system you're you're playing with you want to make important decisions about those things you don't want to make every decision but you want to make them or be involved with the important ones you want to explore new stuff that's what drew you into this place Architects typically are people who like to play around they used to be the the fancy developers who always knew something new when they've always fought to be able to go to conferences right that's that's what gave their motivation and they also want to mentor developers they they want to develop themselves occasionally at least but they also want to be the partner of the developer in helping them fulfill their role now the problem is that these views are not necessarily shared by other people around those architects right so people think architects slow down development they're an impediment the architects are impediments so actually somebody should remove them they slow down development they continuously pick the wrong tools I mean they always make the wrong choice like in every single occasion and they define those annoying rules that you have to adhere to even though you know that if you didn't adhere to them you'd be much more productive right you could do something that would be way more in line with the actual requirements of this particular situation you're in most annoyingly architects never listen to developers right they think there is something better so developers tell them your rule doesn't work and they say well you don't apply it correctly you just have to follow it correctly and then everything will be good now this is just a different way to phrase this wonderful saying from from Ted Newark which I like a lot architect is Latin for can't code anymore I don't necessarily agree with that right I think architects very often are no longer on a critical path and no longer actively developed important parts of the system anymore because they're busy with other stuff at least that's what they like to think but there's a certain truth that after a while if it's been an architect for like a decade and the last time you wrote actual production code is like a decade in the past and maybe you should reconsider whether that's an actually very good idea you can become a conference speaker that's fine as well so what architect actually do I think is a little different I could have titled this slide what architect actually should do so I think the most important thing for architects is to be sales people and that seems a little crazy right why would I mean didn't you go into this IT developer technical thing because you wanted to avoid marketing and sales because that's not for real people not for smart people right that's what you're what you're failing classmate took as their major no you were supposed to be the smart well no that's wrong actually I'm starting to appreciate this more and more the roller I get or if you want to the less the less I know about actually technology but the I think that actually being able to convince people that your ideas are good ideas is an absolutely essential skill that begins with it being able to to communicate them correctly to write about them to present them to draw diagrams that people can understand to maybe explain things in a different way people don't get it the first time that is something that you have to do communicate and you have to defend your architecture against well-meant criticism because people are going to tell you well that's not the we should we could do it this way because then it would be better and the interesting thing is it they might be right but you may be wrong maybe you picked the room you picked the wrong choice and it would be a very good thing to listen to this particular developer on how to do things better and it might improve things so having that discussion and defending things in a positive way not you know defending it against any criticism that's not what I mean is an important thing you also will continuously have to fight to remain involved because from you know this perspective the one I had before this year I think every everybody would agree that the best thing that can happen is to let the architect sit in their room somewhere and draw diagrams and put them on the wall and nobody ever looks at them except for a laugh right that's if you are this kind of architect and that's rightfully what people want to do with you so if you if you're in this if you if you follow this advice then you will actively try to be involved with actual meaningful decisions in real life you will try to be part of actual projects that deliver value you will look how well your architectural decisions work in a smaller in the large depending on what kind of architect role it is that you have here and you will do some technical stuff because that's important maybe it's a little more than five percent but if you if you want to become an architect in a larger organization at least it's really really hard to to go to a 95 percent I code all day role so the politics come into play way more than many of us like to believe so I'm done through my 10 diseases and I promised that I would take that would say something about what to do about them right so this is sort of the miracle cure to all of those things that I mentioned before in typical consultant manner I don't have an answer so here's one anyway right so the the answer to me is a mixture of a lot of things so this is my success formula my attempt at a success formula for for architects I think a certain amount of actual rules and even dogma can be a good thing particularly if you're an organization with are very inexperienced people and I like the approach where you have a very very limited set of rules as few of them as you can but you stick to them and you defend them and you make sure that people understand why they're important and you actually enforce them somehow hopefully by convincing people that they're a good idea not by threatening that they'll be fired if they don't follow them but still a little bit of that is fine and you can you should stick to your own rules unless you change them because you've learned something you experience you need to you need to actually have some experience I think it's pretty hard to you know from University become an architect by maybe going to a training course or something like that so you actually have to have made a lot of mistakes which is also one of the reasons I like to talk about mistakes doing every mistake and every failure actually makes us a little bit better for the next for the next project that we're doing you have to be pragmatic sort of a no-brainer but I think it's it's really really important related to all of the other things that I'm talking about be making pragmatic decisions and say well this is this may not be perfect but it's what what delivers value now what makes us makes us more likely to succeed right now is a very good idea you have to be flexible and your systems have to be flexible and a certain amount of that is okay despite you know we have this pendulum that always goes to one or the other other direction or other extreme sometimes I've seen agile projects that decided that architecture in general is a bad thing which is a stupid thing to say because you can't avoid having an architecture you could use you just end up with one that you didn't want if you don't care about it so you know being on an agile project does not mean you're you're no longer allowed to think right so you you can think a little bit into the future just not too much and be pragmatic and think about the right amount of flexibility to build your systems and be flexible in your decisions minimalism probably I should raise this a bit I think this is a very important important thing because all of the moving parts adds to the complexity that you add to your system and if you can get away with a minimal solution that's often a good a good chance or increases the chances of your system being a success transit future needs again look at what others do but don't exaggerate that try to find out new things go to conferences because conferences are great and you can learn from other people and you can ask them whether this really actually work and you can maybe try it out so experiments and proof of concepts are a very useful tool to actually get some get some real-world experience early on with things things were no other no one else has had the chance yet to build up a decade of experience I've seen I've been in actual organizations where people made a critical important choice of a vendor or a product or a tool and never installed it they never even tried it once they made the decision purely based on the marketing material provided to them and that's not a not a recipe for success hands-on participation I think is a very important part to the degree that you can manage right so depending on the size of your organization you may not be in that role you may not have a chance or it may actually end up being a bad idea every architect I know wants to know okay let me rephrase that every good architect I know wants to code they all like coding they would love to do that but every smart architect I know has stopped doing that on the critical path right because you end up being too focused on that particular thing to care about the important stuff around right so you have to maybe pair with people or find a good way to remain involved and also have this last ingredient or rather I don't right so stay clear from the vendors because they're clearly not in your best interest I hope that was useful and that's all I have for now thank you very much oh that was really exciting now let's have some questions do you have a couple of moments before you have to run yes three questions let's do it what direction do you think architects should take to avoid getting extinct well to me if it's the name that is becoming extinct I'm fine with that I mean it's just a name it's just a role right if if we decide that architect is now a bad word like SOA or so--that's or maybe micro-services five years from now who knows you know if words if words become negative or have a negative connotation then we should stop using them so that's fine with me I don't think architecture will disappear because that's just the some of the important decisions about our systems and somebody has to make that decision ideally I'd love to be in a in a team where architectural decisions are made by the team as a whole that's perfect if the team can do that then by all means go for it very often you have a team where people have different levels of experience and that's really two or three of them will make more decisions than the others those might often end up those with the most experience those who communicate best those who sell their ideas best to defend their ideas best who know how to focus on the important stuff you know if those are just personality traits that in some then make those people architects without them calling themselves that that's fine with me all right thank you what direction nope in which of these diseases do you find yourself in all of them 100% of them just these I've had them in the past I think I've got them in a control and sort of on good medication right now but yes these are all these are all things particularly the first one maybe you notice the addition that the you know the enthusiastic developer can't that's my personal very personal story I did that was so long I'm feel so sorry for my first employers now that I put this burden on them but I learned from you at least learning your mistakes huh how do you get rid of tunnel vision when assigned to a new project or in a new company or environment old habits die hard yes that's very true um I think you have to make a choice I mean it's a valid choice to say you just stick with one thing and you become an absolute expert one thing you just run into a risk of this one thing becoming obsolete at one point in time so maybe it's not a good idea I prefer the approach where you occasionally really try to start again from scratch with something but not from scratch because you're still in the same industry and you can you can still rely on our experience but I like challenging myself and trying something completely different and I think that's the best way to stay relevant in this industry thank you so much thank you [Applause]

Channel: CraftHub Events

Views: 23,718

Rating: 4.920661 out of 5

Keywords:

Id: AkYDsiRVqno

Length: 48min 35sec (2915 seconds)

Published: Tue May 14 2019