 really suck at coming up with titles for talks but this was the only way I could do it so it's a kind of a mixture that we have of of the manager that nags developers it says are we done yet where are we are we there did we get there it's kind of like my kids in the backseat of a long journey right you five minutes out of home and so how much longer do we have you know that's the first thing that came along and at another level it was also a case of me just reflecting upon many years of working with teams my own teams and with other companies teams and being involved in this agile community for for quite a while and we come through these conferences over and over and there's a lot of repetition and I think the repetition is valuable it's a necessary repetition to start off with because there's always new people walking through the building so we need to hear that and maybe sometimes we need to repeat it so that we can actually start believing it as well but in all this time did we achieve this magical nirvana of software development that we seem to be aiming for okay so there's this mixture of something that's quite literal and something that's quite philosophical it's a kind of topic that I could actually do zero preparation for and ask all of you together at these round tables and I'll say here's a topic please discuss it in your groups and then report back and then we'll pick one or two things and say okay how about discussing that a little bit more detail and you know and then I do nothing you know I'll just facilitate it and you'd do everything so it's not that I have some evangelism and gospel to reveal onto you today okay I'm going to put down some ideas and things that I've tried in practice that seem to have worked for me your mileage may vary you might walk out of here thinking well that's an absolute load of or bucket off whatever or you might pick up something and try it so I'm gonna try to speak for less than an hour I want to have a kind of a discussion from you okay so before I go on just a show of hands whoops I still got my pencil in my ear show of hands who's who's on the manager side of the world and who's managers first people who manage teams regardless okay I know it's a management track but I need anyone here who has that like an architecture or lead developer role or basically got hands on keyboard writing code lying to managers about how we're far we are anyone with the dual role okay okay you really conflicted right just like me okay so before we go further oh one more thing I'm gonna do an experiment with you I'm gonna do a very non-linear presentation right I don't have slides that go one after the other okay it'll be dancing around and it's an absolute experiment so even if you catch me outside tell me whether it worked or not because it's a kind of topic where I couldn't actually create one linear sequence of things there's so many tangents so I've chosen another tool to actually do the presentation so things will move around on the screen ignore the motion focus on the content so let's just focus on this guy here which is myself so who am I aslam Khan that's my blog free your mind f3 your mind free your mind net if you have trouble sleeping you can read that blog it's fantastic for insomnia I'm a software developer the reason why I call myself a software developer is because my mom who's 82 years old has a reasonable understanding to explain to all the family what I do okay if I say architect it gets confusing if I say coach it gets even more confusing so it's just software developer mom you can tell them that it's something to do with that sometimes she says I fix the internet but that's another story so I'm from Cape Town in South Africa this is my second trip to India was born in South Africa so two data points here for the conference last year for the first time second time it's now a pilgrimage for me and absolutely love being in India I don't know why it took so long I have spent more than half my life writing software and getting paid to write software so that's a professional capacity right in all of that it's only in the last year so I've realized that my whole life I've been just trying to balance everything there's conflicts that pick that pop up all the time and often I always try to make one side win and it's only now right that I realize that okay that's such a futile effort to get one side to win there must be a nice sweet spot somewhere in between so this is what I'm doing and this thing that we'll talk about today is about that sweet spot perhaps that we're trying to find between managers of teams and the teams himself okay and what is the thread that actually works through that so it's based on observation I'm gonna present a few case studies real-world examples things are blurred out you don't need to see the text it's there to save confidentiality very mildly I could get sued I guess but we'll work through some of those things and if any of you are going to come to the technical track the case studies I'm going to repeat but in the technical track I'm going to talk about at an engineering level what led to this and some things we can try to correct that at a technical level right so this is more to human level so the first case study is actually a software product right it's in the supply chain industry I've worked with this company for about six years right no yeah now six years and very early on I asked them someone on the technical side please show me your architecture give me a picture you know so I can see what's going on and they gave this to me okay and I couldn't make it a tale of it right it looked really nice and compartmentalized and I thought it was all one product until they said that that's actually version one and they the color scheme is very appropriate here because the internal code name for version was was black box so you know what version two was called right red box and version three was called blue box and the other one it was in version four okay so here's the thing right they actually over a period of time went through several iterations came up with new versions the problem was that every version was in production right every single version was in production the green stuff at the bottom where I also was about to say green box there's actually some magical thing that they've concocted to just start integrating data between these things right so I know even put a question mark that this is not really integration it's just some weird thing that they've put together but that's not the interesting thing about this problem right so here's a look at that the writing might be a bit small but I read it out to you so when I started looking at the lines of code version one was about 800,000 lines of code version two the red box was what 650,000 lines of code and version three was about 700,000 lines of code okay the number of developers on version one was eight the one on version two where six people in the team version three was 20 people on the team and here's the killer version one was about 65% complete before they decided to do a rewrite to version two a rewrite okay version two they managed to get up to about 80% and version three is sitting at about was sitting at about 50% you've got 20 developers you've got 700,000 lines of code for 50% completion when version two was 80% complete with six people right and 600,000 lines of code and you can just look at the picture at how much version three is but it doesn't even touch the functionality of version two there's something horribly wrong here okay so that's let's leave them for a while there's another case study this is an enterprise software in the insurance industry okay now you don't even have to read the pictures read the boxes and what they mean they're completely meaningless right but this was at a namespace level this is at a fairly high level static analysis of the code that I did and so at a particular level elevated high view down this is what it looks like so ignoring the boxes and their labels you can see the cyclic dependencies right how things are interrelated okay and from engineering point of view we kind of know that when we have those kinds of loops it creates a disaster right so it's not so much the loops but the quantity of those that's attached that the number of dependencies that this is absolutely real right some of those dependencies I 95,000 dependencies between two modules 95,000 times something is referencing this other thing 95,000 unique distinct references between this and that 95,000 okay 10,000 43,000 okay so this has got to be the most insane code base I've ever seen right I was involved I was asked to help them with one central component that central component had 90 dependencies on its own 90 at the first level so I put this down I need 90 things in order to work with this thing 90 right the main piece of logic was 4,500 lines long yeah how many screen fools you know how many page downs that is to get to around to this I typically shrink code to reduce the font size if I reduced it down to point font I still couldn't fit it onto a screen for okay this was the most important piece of code here so they've been using you know scrum for two years there were waterfall before that this is an inherited code base right there's nothing about the process that can fix this nothing about the process they follow there are actually a very good scrum team very very good scrum team okay but the problem is that this is still under active development and the manager is always nagging the development team about why is this featured not ready yet etc okay there's a demand from business this thing is responsible for calculating insurance premiums across portfolios etc so it's critical part of their business right but it's a legacy problem that they've inherited by the way I forgot to mention to you that the previous case study was seven years of development using extreme programming okay then the last one is actually for a company they were actually doing it was tools it was just very bespoke tools within the company and it was just integration again you don't have to look at the numbers but if you can see the railroad network between things but if you squint and look at it with blurred eyes you'll notice that there's about three things on one side and three things on the other side right so what this thing's responsibility was was actually to bridge three disparate web services it looks like this on this side and it looks like that on that side take this from here transform it make it work like that on the other side okay problem here it was a very simple requirement with a highly complicated solution the consequence simple trivial changes results in a long defect list because you don't know which rail road you have to follow to see what the dependencies are etc okay this is two years of development with one year with scrum okay and again the adoption has been extremely good right so there's a problem here okay there's three quite different cases right product company enterprise software tools all have been through various levels of maturity for agile adoption no one actually sat down in those teams and said let's create the worst designed software ever right no one did that no one said let's see if we can make this the worst software right I don't think anybody sits down and does that but this is what happens to software over time and over time what happens is that when you start asking as a manager are we there yet the answer is not yet and you will get that answer more often because this is degradation of the design over time and it's not deliberate no one is actually sitting down and saying well hey let's just go and create another 2,000 dependencies here just for the heck of it let's see what the next team does you know no one does that you know you don't put down on your resume I've created so many dependencies you know it's not a stripe your way so this there's something here so who's at fault the team engineering team the architect that main guy up there where the buck stops at who's it you you're saying you on both sides the manager so it's easy you're at fault completely right so that's an easy one we can just blame you it's fine you the manager you the architect you the team it's fine but there must be something that's that's not working here right so let's get try to get to the essence of that so this reminded me of something I read many years ago by Fred Brooks and this is the third or fourth time at this conference that Fred Brooks has come up okay he wrote a famous set of essays firstly in about 1975 I think it was yeah he published it and the second edition he published in 1995 it's called the mythical man month right and it's essays and software engineering the famous one is no silver bullets but there's another paper essay in there which deals with this thing called conceptual integrity right and this is what he says he says I will contend right so he's willing to debate this I will contend that conceptual integrity is the most important consideration in system design it is the most important thing in system design it is better to have a system omit certain features than to have one that contains independent and uncoordinated ideas so don't just throw every idea in that's basically what he's saying that there's a certain integrity of the entire system that determines the success of that system how we work with it this would be saying all right so when I reflected upon this and this is something that I've now this idea of conceptual integrity is something I've been trying to apply over the years several years now and in each case conceptual integrity of these cases I put forward was destroyed it was gone right and the conceptual integrity is the responsibility of the architect and the manager okay I'm going to use those two terms very loosely manager to mean anything that's not engineering right whether it's a development manager a divisional manager it's a product owner it's a product manager it doesn't matter you can create your own impression but someone who's not directly hands-on engineering and architect is someone who's not the manager who is doing hands-on engineering right whether it's one person or a group of people it doesn't matter so I'll speak about them in the singular so let's think about this thing called conceptual integrity for a while okay what is this mythical beast and how is conceptual integrity the interplay between the architect and the manager so in the world of movies right if you had to try to create roles through a metaphor here the architect is the director and the manager is the producer manager is managing the constraints and they are and the architect is the one who's making things happen so that's the roles that we're looking at here so there's two halves okay the one half is on the architecture side it's fine okay and the architecture side has a responsibility without reservation to fulfill the requirements of the user of the customer unreservedly they have no other higher purpose than to fulfill the needs of the customer it doesn't matter what the design is and the architecture is and what technology they're using first and foremost this is what I'm putting on to the table you need to decide you need to give the customer the highest priority right firstly on the other side on the producer side this side is responsible for managing the constraints of the project okay the constraints of the project are typical it's old-fashioned project management it's people capacity budgets all of those things those are constraints that's what producers do they look after the those things okay so let's focus on this part there's this weird term that we have in agile circles called value I'm not even going to try to define that Jeff Patton gave a definition yesterday about outcomes versus output right you measure the outcome you can't predict value up front which is a nice definition but I'm going to say this right to create value in order to create value the architecture side needs to maintain this mythical thing called conceptual integrity right so what is this thing called conceptual integrity it's embodied in something called ease of use and ease of use is basically something that has to be managed and I'm going to say this quite controversially autocratically by the architect not democratically this ease of use this this unreserved focus on the customer comes from an autocratic hand not from a democratic hand somewhere someone has to make a decision to stand up and wave the flag for that customer okay there's two things that affect ease of use right in any system one is functionality and the other one is simplicity you could replace simplicity with with the negative connotation negative word of that which is complexity so any system an architect is going to sit in the middle and is torn between these two forces that pull this person apart right one is functionality as functionality increases complexity has a tendency to increase or simplicity decrease it has that if I increase if I want to aim for simplicity and reduce that complexity then I'm trying to simplify what we actually give the customer right so architect that engineering person is the agent of the user that is sitting there imagining what is going to be like for this user trying to balance these two highly oppressive forces creating this really taught tension between these two things and that's what architect is about right so how do you do this what skills do you need to be able to resolve this type of tension okay and I came across this a few years back which is known as the drafus model of skills acquisition drafus and his brother had exist had been around I think pre-70s the state of nursing in the US was really poor the skills levels of nurses was poor and then he came up with the model of how you acquire skills so it's very context-based but this is what he puts down there's a novice level right five levels novice from his engineering point of view they code with recipes you tell him this is you follow the script and the code will come out and that's fine you code with recipes you follow it by example you code by example the advanced beginner the distinct characteristic is that they work in the small not in the large if you give an advanced beginner the big picture it frightens them off they can't deal with that they can only work in localized space right local max the competent is someone who's moved on from from advanced beginner you can see it starts seeing the bigger picture and being able to see the bigger picture helps them to be able to troubleshoot successfully the proficient can actually do self-correction that is they can correct their own behavior say that okay wow I shouldn't have done that wow I should do this that's self-correction and the expert works from intuition right so it's something in them that they can draw upon experiences from the past and it helps them guide them and it's this case of we've all have that sometime in our life of you just have a gut feeling it should be this way and you go and you act on that gut feeling and it just works out right so that's not the most interesting thing about it so the novice has no discretionary judgment they cannot apply any kind of discretionary judgment on anything right the advanced beginner treats everything is of equal importance they cannot discern they cannot prioritize the competent is able to do deliberate planning the proficient can prioritize the importance of aspects and the expert can envision what is possible they can see forward and imagine and articulate what is possible drawing from that at novice and advanced beginners can't estimate very well so if you're sitting in a scrum team and you're doing those poker games and doing those points estimations and this is a mixture of people that estimation is seriously skewed because you have if you have novices and advanced beginners they are unable they not yet have they do not yet have the requisite skills we able to create any meaningful estimation so their estimation is skewed okay the the competent and proficient they can organize and estimate pretty well okay much better but it means that they're in a position to be able to do self-organization so if you're asking advanced advanced beginners and novices to self-organize you've got a really really hard work ahead of you okay and the expert is able to understand choices and consequences that means that they're able to sit down and say okay given this situation these are my alternatives and if I choose this particular path I know the consequence would be that okay that's a big difference right so given that when I look at those case studies right the software product company it was the team was mostly advanced beginners few competent designers version 2 which in my opinion is their most successful rewrite had one expert who then left the company in the enterprise software it was roughly an even split between novices and advanced beginners I don't know what it's like in India but in enterprise software development in South Africa there's a steady flow of people that are grad levels coming into a company getting a job writing some code leaving next round comes in because the expert those who are seeking that perhaps the organization doesn't afford them the experience that they actually want so they move on okay and in the tooling company it was mostly advanced beginners and one or two competent people right so if we look at that again right and just apply that so the novice the advanced beginner and competent when it comes to software development the business that we're in there's three parts to engineering to software development one is this theory which is computer science then there's application of the theory which is engineering and then this constrainment of that of that engineering which is the domain in which you are working it is the context in which you work so engineering practices applied within this business of insurance is constrained by that domain okay but those three levels the novice the advanced beginner they have a reliance on tools as opposed to computer science they have a reliance they actually end up doing do it yourself amateur hobby building as opposed to deliberate engineering and they're unaware of the domain but they rely upon specifications so it's just give it to me I'll do it like that you told me to do it like that I'll do it like that okay the result of this is a code basis actually sprawls out of control like what we've seen right and it happens to be that just those sprawling code bases are much harder to work with and they cost a lot more on the other hand those two the competent and and the expert they look to computer science to solve problems they apply engineering practices they really get to understand that domain and rely less on specification if they understand the domain they can be a true agent to the user that's what it comes down to as opposed to someone who has a literal very superficial understanding of what the customer really is all about the result of that is actually a much smaller code base that's easier to manage right not through some engineering marvel but through a combination of these things it also happens to be quite small and it happens to be a lot cheaper to manage and maintain so there's two two things that come out of that one is that that caught my eye was this thing of velocity or predictability it becomes really good for for planning right but there's another concept which I called maneuverability how can I navigate my way through and that's useful for maintaining this thing called conceptual integrity because along the way we discover something new about this domain which you didn't understand so now it causes me to do a u-turn and move around so I'm not so interested in velocity I'm interested in how can I move it's exactly like traffic here in India right it's slow moving but you can move around quite freely almost well most of the time or sometimes scarily but it's true and it is the same thing with software development that maneuverability comes with fear because you don't know whether that's a gap you can take but you can do that right I start value I've started valuing maneuverability much higher than velocity or predictability and then this is other thing right so it doesn't mean that we don't have room for novices and advanced beginners we need to have them but it's a learning process right novices do a lot of need to do a lot of self-learning those in between this training this coaching and then it goes full circle when you're an expert you go back to self-learning and then your context changes and then you become a novice again for the new area okay so when I look at all of that those are aspects about how do we maintain conceptual integrity which is being the agent to the user establishing an agency with the user and and just enforcing that all our judgments our decision-making is based on ease of use which is this balance between simplicity and functionality okay and there's a requisite skill levels that come with that that allows us to do that it is not something that anybody can do okay balancing the tension is quite complicated on this side here we were managing the constraints you know constraints are actually pretty simple right it's those things but from an engineering perspective you have to take those things into consideration right and I find many teams where they actually are aware of the budget they're aware of the deadline they're aware of the capacity that's available but for some reason you completely ignore it those things influence your decisions given this constraint this is what I am able to do okay and there's nothing wrong with declaring that with the person that you're working with you know we have this amount of time this is what we can achieve so you have a reasonable polite discussion it's not about you know it's people do two things yeah yeah definitely I'll finish it and you burn the midnight oil and you know you get burnt out or you just say no it's impossible but you can't say why all right so you get both but here's something that I've observed unconstrained teams and in agile software development you swinging from highly constrained to a certain amount of freedom that comes with self-organization etc and this whole thing of cross-functional teams and democracy within teams when teams work unconstrained this is my observation they tend to spend a lot of time debating architectural decisions design decisions an extraordinary amount of time you think about just reflect upon your backlog grooming sessions your sprint planning sessions those types of things they say okay do it in two hours and it'll take the whole day you know and it's not even finished because next morning they'll still start talking about it over tea and things like it just carries on and on it's unconstrained and the consequence of that is that the implementation gets shortchanged right that's the first consequence the implementation is shortchanged you're so stuck in this thing of talking about it that you're actually not doing it and because you're not doing it you've actually delayed your feedback loop to such an extent the consequence of that feedback loop disappearing or being retarded or lagging is that your domain knowledge is unconfirmed you don't know whether you really understand this domain okay so the sooner you move to trying an option that's on the table the sooner you move towards trying an option on the table that's been debated the sooner you can confirm your understanding the longer you delay it you're losing that last responsible moment now the last the way I understand last responsible moment is the last responsible moment for making a committed decision I have these options available at the last moment on a commit to this one that's what it comes down to and there's lots more which we'll talk about so that's about the constraints right and that's pretty straightforward so there's these extremes you can leave a team unconstrained and this is what happens even though you're working in this agile process it's unconstrained you start having a highly retarded or delayed feedback loop and things start moving out longer than you expect okay now to create value from the management side you have to respect conceptual integrity if as a manager you understand that the person on the other side of the table on the engineering side is standing there to protect conceptual integrity then you have to respect that position because that is in the position that is taking the interest of you all our customers it's a common customer okay so conceptual integrity from this side of the table is actually a single philosophy it's one philosophy about the system and that single philosophy can flow from a very small number of minds maybe two or three but often one person will reflect the single philosophy right and the single philosophy is manifest in that ease of use right it's actually creating a mental model that that says this is how the user will perceive the system this is how they will work so if you think back to the early days of something like something like let's say excel right it's a simple thing there's rows and columns and cells you can put in values and you can put in formulae okay then you have weird things like pivots and all sorts of stuff happening okay when those things get thrown in you're actually altering the mental model of the user okay now as long as those features satisfy the conceptual integrity that this is how we can work with data it's one more thing we can use to work with data then it's absolutely fine but if it breaks that conceptual integrity right it's just a nice to have that breaks the mental model of how we work with the system as a user then we're in trouble okay so this poor manager is stuck in the same position as the architect but with different forces mostly he's trying to balance this thing of democracy and autocracy okay so with democracy we want to encourage democracy and we should have democracy and what we mean by democracy is that we actually are willing to receive the ideas of everyone okay that's what it comes down to but not all ideas will make it in if the idea is to the detriment of the conceptual integrity of the system you cannot include it so what happens if you have a flood of ideas that threaten the conceptual integrity of the system it means our original mental model of the system is is warped it's wrong in that case is absolutely cheaper I have no reservation saying it is cheaper than to abort create a new conceptual model and start and start incorporating those ideas in the lean world they call that a pivot okay let's switch oops wrong idea completely let's switch to here right but there's also an amount of autocracy associated with this that is when it is a beneficial it's very benevolent autocracy that says that this person here will sit here and will make a judgment call based on ease of use that mental model that will be retained and honored for this particular idea okay there's also this notion of aristocracy that exists in teams this elitism of architects and the rest and developers and testers and all sorts of different things you know lead developer and junior developer it's this aristocracy that exists amongst that and there is no reason for that okay and all of it comes down to one simple human thing is that we all have entered this industry because it's a creative industry and we want to exercise our creativity but there's opportunity to exercise creativity in multitude of ways at all aspects of software development right so there's no reason for it not there's no reason for it to exist but autocracy and democracy there will be that interplay at the end of the day it's the buck must stop somewhere someone has to be a good decision so if i think of it in a political context at let's say a national level if you have to have a referendum on a contentious issue right now right and it's basically a referendum is going to be an opinion it's an opinion poll and if you had to pass a law based on the opinion poll is that law in the interest of the people is the interest of opinions it's not necessarily that is an interest and well-being of the country okay so it is there as a way of establishing what is actually going on so there's two other things that threat conceptual integrity the first one is called featureitis now in medicine terms anything with the word itis means inflammation of right so if i say i have appendicitis inflammation of appendix tonsillitis append inflammation of tonsils featureitis is inflammation of features right so here's the thing there's some great ideas out there and when you look at it and you think wow that's fantastic right and it's so appealing on onset that you actually rush out and say let's just do it okay and you could do your estimations right you'll do your whole planning poker and all sorts of things and you look at the city say yeah yeah yeah we can do it and we'll finish it in this sprint or two sprints time whatever it is and you go for it right so you put your head down and you run into it and you try to do it but the real cost comes up during implementation that is undeniable you will hit some stone walls and you say oh my goodness what about this whoops didn't think of that one let me change that and all the time what you're doing is that you're actually destroying conceptual integrity to accommodate this really cool thing which seems so great an onset over time it's this thing that is destroying ease of use it's corrupting the mental model of the for the user of what the system in the way it behaves in the way it works completely destroying it okay after feature it sneaks up upon you right so this thing of incremental development right it's like me snacking every night you know on a biscuit and a cup of coffee and after a while you end up like this right it bloat okay it's incremental it didn't happen overnight come on it didn't happen overnight I didn't even see it coming it's this insidious thing it's not my fault I my mental model of myself is not this I can tell you that now right but it creeps up on you you know wow that's a great thing let's have that but that nice as well you know so and that's the real cost of implementation and I imagine the effort to get me back down to trim weight okay that's the effort that has to go in each of those case studies right it's serious you're gonna burn more this is other concept right of amorphous users now remember we're talking about that we're agents to the user now how can we be an agent to a user if we have an amorphous user we have no idea of what the user is so if you speak to people in the design world and user experience world they'll talk about creating personas and things like that then there's a reason for that is to give you something concrete to attach to so you have some idea of what the person or that user represents and for a single system you have sets of users there's category that works the system like this there's a category that works like that there's a category that works like that okay and if you have large groups of amorphous users then every single person in that team working on that system has a different idea of what the user is about so how can you ensure conceptual integrity if you don't know what who's at whose interests you're representing and what are their own interests right so this is what I try to do I ask four questions ask who who are they right so just talk about who are they who are these who's this group of users the next one is what do they need just just talk about that and then what do they think they need what do those users think they need right and the last question which is really the one that kicks you in the gut is what do they really want you know it's that whole Ford story that you've most probably heard and quoted many times over about you know they wanted a faster horse but we gave them a car so that they actually want a car you know and it'll definitely be black so it's that old story so you have to go through this process of asking those questions and you get to the last one says what do they really need which is why the iPhone came about and it's been quoted so many times here today this this week you know the iPhone the iPod all of those things what do they really need it didn't happen from a set of requirements and specifications so that comes down that's that's these two worlds right and I'm saying to you that when I try to balance those two parts of the world the single thread that I find most useful is this thing called conceptual integrity okay which is the binding thread for a manager and an architectural engineering team the engineering team will carry and wave that flag in the interest of the user and the manager is going to impose constraints but respect that this person on the other side is actually working for the integrity of the system and in the interests of the customer so one is maintaining and treasuring that and the other one has to respect the decisions that come out of that and if you can justify your engineering decisions based in the interest of the user without destroying that conceptual integrity it's easier to argue with something around that that's very concrete than it is to say well I don't think you can do that no no no it's impossible you know what it means from a database migration to be able to do that no no we're not going to do that forget it you know those kinds of discussions are actually worthless so what is this thing called concept what form does it take this conceptual integrity in many forms you could you know Jeff Patton talks about a story map that's a way of describing the conceptual integrity of the system that's what it is you could have a system metaphor right and that system metaphor describes a conceptual integrity you break the metaphor you break the integrity you you're lost you've gone off on a tangent right it could be sketches that you put down it could be in a financial services industry we were doing forex trades the conceptual integrity was embodied in one single spreadsheet and we could use the spreadsheet to to show the different trades that exist different ways in which it happens now it's not that we spent months devigning designing the spreadsheet but it was there to say that this is dependent on that and even if the calculations were not embodied in there it was a way of doing that find something that is concrete that is of relevance to the domain in which you're working but please don't do this right don't wave in the air around what the system is going to be like there's no conceptual integrity that comes from hand waving okay there's a way that there's this thing of powerpoint architects which is you can use something like powerpoint to illustrate the conceptual integrity of the system you can do that you could have slides as a transition that just show a particular scenario unfolding but that is far different from a powerpoint architect waving the hand in the air and saying okay this database we've chosen and that framework etc that's got nothing to do with conceptual integrity maybe technical integrity yes but not conceptual integrity so that leaves us here right that conceptual integrity of the system is something that we should treasure and I find that it actually bridges the two it pulls them closer not necessarily you know hands around shoulders but it definitely brings them closer and there's a few landmarks that we visited here first one is incremental development which you had a giggle at me about right this insidious gradual increase in bloat feedback okay so here's the way I approach feedback I want to receive it as soon as possible but I want to react to it as late as possible I rather gather it but I want to have a deliberate plan of action of when I want to react to it and often the mistake that's made is that receive and react immediately that's one choice react immediately is one choice you can delay your reaction to an appropriate time you may wait for more to create a dataset to say okay it's definitely something that we should act upon you might put a bug fixed on and work around before you actually fix it in production at a latest sprint I talked about velocity and the fact that I value with maneuverability a lot more this interplay of democracy and autocracy deliver value so again I'm going to reiterate this we can deliver value when we give when the software itself presents an elegant elegant coherent mental model for the user it's this thing of given the software I don't have to think about it I'll just use it it makes sense because I know my business and I'll just use it right that's what we're after but why do we bother with that is because the software you write is not about the machines it's all about us helping one user at a time and the more we corrupt the mental model we corrupt users the more disservice we are making to humanity so warnings this there's quite a few confusion points here first one is that this conceptual integrity is not big design upfront if you think about the maneuverability and last responsible moment you're exploring a domain you're looking at options you're building it up in a very evolutionary way as long as you're actually still retaining it so that so it can increase right but if you think of it as a nice whole you don't want to suddenly just have a little bulge on the side little things sticking out here that's when you're violating that the fragility of the conceptual integrity is unknown you don't know this is the reality of software development no matter what you design no matter what you build you're only one requirement away from collapse extinction level event of your entire design you can't predict that it just takes one requirement and three-quarter of your ideas maybe may just collapse under that and it's a valuable necessary requirement okay can't predict that the idea is to try to find those early right so feasibility is different from value feasibility is driven by project constraints people budgets all of those things that's independent of the value value is what you give to the user in terms of ease of use and also it's not about elitism right it's not about aristocracy and creating those hierarchies in the team okay there are proficiency and experts those five levels may seem like elitism right proficiency and experts in my opinion are generational in it is generational so are we there yet my answer is no it's plain and simple I think we've just begun we're just starting to understand the essence of software development and we're just starting to understand the impact of software development on the rest of the world okay the reality is that we're not trying to change the world we are changing the world the moment you release a piece of software you've affected another person we might as well try to do it in a nice way and be nice about it okay so avoid this conceptual corruption that happens between each of us okay so I don't have anything further to say this entire presentation in that style is available online it's at I don't think you can can you read that to the bottom bit.ly wqe5mp I mean that sounds like a coupon code but bit.ly gives out coupon codes and so anyway so this entire presentation in its entire form like that where you can click through find the parts that you want sure right so it's bit.ly slash uppercase w qe lowercase 5mp I'll most probably embed this on my soporific blog as well so you could get it from there as well I'll do that later in the week so thank you for your time thank you for enduring and not walking out and I hope there's something here that you could take away or there's something here you can challenge me on I'll be willing to hear that so open for questions discussions thank you yes so the question is that I've spoken about the balance between architect and managers and where does the notion of product owner comes from okay so one of the first notions of ideas around agility came from extreme programming and in extreme programming they said bring the customer on site work with the customer okay and then Scrum came along and said here's you know we can't always have the customer on site let's get a product owner okay so the product owner became a proxy for the customer in that sense right in product development companies we've had traditionally product managers which were responsible for either a portfolio of products or single product okay so in in extreme programming situation those that team those maybe the one person that main architect was actually the product owner engaging with the customer okay and here we've moved it over to someone else who has this responsibility of being the center point with the customer I find that very difficult to work with and last year when I gave a talk around product ownership I proposed that the product owner in the traditional sense in Scrum and the architect or the person who holds a conceptual integrity in the team actually one one body they should be working really really tightly together to be able to do this so in this sense here the product owner could be the architect in that sense who was establishing this mental model this coherent mental model and then you have other people who are just doers who are designers and and you know at software design level implementing it so that is why when I started I said this notion of manager and architect is very loosely defined here so manager could be anyone who's responsible for the constraints of the project and the architect is anyone who's responsible for the conceptual integrity does that answer your question okay so it's changed over time I think it'll come back to yes sorry I can't hear you okay all right thank you very much maneuverability it's hard word to say though yes yes yes either measuring or discerning this maneuverability I think yes at various levels actually what makes you maneuverable is eliciting feedback pretty quickly so whether you're doing a paper prototype that gives an option to maneuver if you're actually going into development itself with code you'd want to put in instrumentation very early on on that piece of code so that you can maybe track click-throughs or something like that okay pretty early on so you can get that feedback which says that okay I have something here right but it's not good enough to just say I'm now measuring that because you need to know where the gap is next so you can only be you can only you can only maneuver if you know what your options are okay which comes down to something that we tend not to do we tend to debate options choose one and discard the others right we say this is the better design let's go for that right so those ones are poor I keep all options on the table until there's feedback to say that this is moving the right direction so to build in at a technical level to build in instrumentation just to determine whether the idea is moving forward is moving us forward but also that given this information already you must know how to analyze that information so you can actually choose an alternative part that you already know exists okay you do get cases where people will try both options they play it off okay sometimes it works sometimes it doesn't but you could you just think about creating what is the feedback loop I want what in the feedback loop do I want to gather right and if I gather this information what would I do with it so whether it's a paper prototype whether it's a thought experiment that you create whether it's a conversation and a walkthrough of a story map with the customer whether it's a piece of code on a web page that is that you've changed you got to find something that to create the feedback loop okay yes so how do you how do you deal with that technical debt that's accumulating so absolutely that's that's an honest open declaration absolutely honest open declaration right so how do we how do we how do we firstly become make everyone aware of that that's the first thing that look if we're going to do this it doesn't break the conceptual integrity but our design choice will incur something that makes this thing less it makes this more rigid it reduces our maneuverability down the line that's the thing that we have to talk about okay and that comes from those people at the right skill levels that can see the big picture can envision can predict what's going to happen it might not come from one person but it has to be an open declaration you know it's like you know if you have a plumber coming to your house and there's a leaky tap and he says well you know I can just put some epoxy on it it'll stop for three days but in order to fix it for real I have to break the wall and I've got to do that it's the same thing you'd rather hear that and deal with that and take that into consideration the accumulation of that is is a different problem in the brownfields environment where you have legacy code base how you turn that around is different those strategies are different because in in brownfields environment you're trying to trying to claw back conceptual integrity whereas in greenfields you are establishing conceptual integrity from the outset okay so in brownfields you can establish you you claw back your conceptual integrity and then there must be some parts of your code base that you're going to say this doesn't fit into this model anymore we're actually going to deprecate these things there's different techniques around that are you going to come to the technical track no no okay so if if you bear with me I can tell you one technique that I've done successfully and that is that I actually claw back technical or conceptual integrity by analyzing the data so all scenarios all use cases are recorded in your database it's there okay so typically what I would do is find a way of articulating in in data what a particular use case is right so for example if we know that it's a workflow thing and you go from this step to that step to that step I would concatenate all the steps and say here's a very unique scenario here's another one here's another one here's another one and I'll do a frequency count of that so I create a histogram okay and what that does is that you actually find the long tail very quickly okay so we haven't yet touched code we're analyzing existing data that is myth busting that's all it is okay and based on that you can draw a line and say ignore that okay so thank you