Software Architects: Should They Be The Ones Prototyping?

Transcript is auto-generated and may contain errors.

all right it is Monday morning get the the beeping going here um I'm going to Reddit for a topic uh it's about prototyping so this is something I have experience with um prior to Microsoft I worked at a digital forensics company called magnet forensics and I spent a lot of my career prior to Microsoft prototyping things um so I wanted to talk through this the um the question itself is about like structuring structuring like a team and uh and how you kind of allocate resources for prototyping so I figured I can speak to that uh at least from my own experience so uh if you're new here I try to share experiences I don't try to tell you exactly like you know I don't I don't say like this is the way to do it because there's always many ways um but at least if

I share my experiences and insights then you can kind of draw your conclusions from that so if you have questions that you want answer leave them in the comments below or look for Dev leader on social media that's my main YouTube channel and also my personal brand that I go by so if you want to reach out on LinkedIn it's just Nick centino my profile should be open um okay so to start things off this person is saying and by the way I'm sorry my car is probably going to keep beeping until we have warm weather um I don't know I think because there's a wrap on the car and as soon as it's cold maybe the little bit of layer of frost on on the front on top of the wrap is just enough to make the sensors complain um anyway this person was

saying that they have an architect that is essentially doing the the proof of concepts for uh the company and the way that they defined it in terms of like how the proof of Concepts work it might work on them for a few weeks and then often the proof of Concepts aren't things that actually ever um and then you know so it ends up being what looks like throwaway work and I mean this is pretty typical for prototypes that's the the goal of the Prototype is to answer questions so when I was reading that I'm like okay that seems normal that's fine um but their main curiosity was around like you know is that how we should be using our architect I can't believe this stupid beeping um every time I stop it's going to do this and I think this is where the question gets

interesting because obviously if we don't have a lot of information about the resources at the company how they want to be structured and stuff uh to give an opinion on this is kind of just like I mean just that it's just an opinion and it's really hard to do a good analysis now what I've seen happen because I've had situations where we have Architects that basically work on Islands I think in general this is a really bad way to have Architects operate right I have someone tailgating me right now doesn't really make a lot of sense why you'd be doing that um having Architects operating on an island is not great almost never uh I've I've never had an experience where that worked really well um creates a lot of uh sort of disjoint Vision between the Architects and the developers that end up having

to carry out the work um kind of just yeah overall not a great not a great vibe however um prototyping is a little bit unique in that it's and I'm not saying it's reserved only for Architects but the the interesting thing about prototyping is that you have to think about developing code in a different way because the goal of the Prototype is to answer a question not to ship uh production ready software and one of the things that people struggle with I found historically is that getting into that mindset is very difficult people like the idea of oh I get to work on new shiny things and that seems exciting and that's cool but the problem is that they're not ready to throw away their code and then they get attached to it they want it to keep going and then you know if they

like things then basically they want to push out timelines and it's like hard to blame them because they like working on it and it is interesting but the reality is they you need to do the minimum amount of work to get a question answered and then that code is either going to get thrown away because it did its job or depending on what it looks like that might be a like a something like an integration point that another team takes on or depending on how you're structured it could go a bunch of different ways but the point is that you have to be ready to toss away code and I don't think that many people are in that mindset where they're comfortable with that again just speaking from my experience maybe that's not the same everywhere so the the fact that they have a single

person kind of or and even if it wasn't a single person small team even if that was the role of the Architects um I don't think that that's necessarily a terrible idea um it's just that if they needed their Architects for other things sorry I just switch lanes um they need their Architects for other things then they might not be leveraging their Architects for those other things right architecture is not about uh I mean architecture and prototyping is not the same thing so if they need Architects to be able to help structure the long-term vision of code bases and things like that um or to help take on initiatives of uh we call it like a a North Star right when you you're trying to work towards something in your product or Suite of product services and you have this vision of where you want

it to be and how the systems can integrate uh together that's generally oh I mean you have other terms for it but we call it a North star and Architects are there to help uh facilitate what that looks like shape that and then also help people navigate towards getting there so a lot of the time they're they're in a position where they're they're trying to help get you know large areas of a code base or product or service or Services uh moving in a Direction uh and so they have to coordinate between different teams get everyone on the same page bought into what that Vision looks like so if you need that at a company and that's what you want architects to do but then you're having them prototype I think that's where you start to have the challenge so what I'm trying to say

here is I'm not so bothered by the fact that you have like a dedicated person or a small team for prototyping I think that's totally fine and in fact I think that can work well before I left magnet this is essentially what uh I was going to be leading and uh I guess I can I call him my my predecessor um awesome awesome engineer and uh now a director there I think he's he's running that team so I I assume it's still working very well for them to have uh prototypes done that way so the point is I think that that can work well on small teams but uh the thing that I'm not super jazzed about here is that if you have an architect role are they no longer facilitating what I would call the true role of the architect the other thing to

say and we don't have the details here maybe that person has enough time where they're able to set like I don't know they can work with the teams get like a North star Vision set up they're Consulting uh with the other teams to help that happen and they can still prototype like cool that's great it's really hard to know without knowing like the scale of the company the workload and all this if it's like a smaller startup company then yeah I mean we didn't have we didn't have Architects for a while and then when we brought on Architects what happened was that it backfired not because the Architects themselves because they were brought on this is at Magnet um they were brought on in a way that basically like allowed them to operate in Islands so it it basically just made more friction than it

did offer value so we went I would say we went years before we had an architect role that actually seemed like it was offering value again not the fault of the individuals I think just the fault of like um how they were set up and if they would have been within teams like we didn't could we have benefited from it like sure but I also think that like it wasn't a requirement at the time either so I think we would have benefited just from having developers wri in code so then the question that we want to try and answer here is number one is there anything more optimal we can do with structuring a prototyping team around how it's organized uh or like do you distribute prototypes within teams and then the second part is like is that the goal of the architect and I

want to start with the second part um I would say honestly if you don't have the need for your architect to be doing the other architect kind of things right now I don't see any problem with this um as you're this is the thing I would want you to pay attention to though as the team is growing and scaling or the team Z plural are growing and scaling does the need for the like an architect role really start to show itself again and if it does what's going to happen are you are you basic and this I'm not saying it's wrong cuz uh I literally was in a position before where we were building prototypes and we said hey you got through the prototyping backlog no more work to do go bu go back to building products and we did that um but maybe in

this case a similar type of thing will happen which is hey we need an architect to actually be helping with architecture things and that means we can't be doing prototypes that might be a totally okay thing for the business but I think my point is that you want to have awareness of it because if you need an architect and you have them busy doing prototypes I'm not so sure that uh they're going to be able to take on both as that's as the requirements scale so at that point I would say if you've been finding it works really well to have the architecture sorry to have the prototyping work done on like a little Island then I would say like keep that part going if that's working well and um and then you might have to like find that you have to go hire people

specifically for that role which again could be tricky because of what I said earlier a lot of developers are not ready to operate in that way um so yeah I think like I don't think that's the role of an architect but if you're at a smaller company and you need people to wear different hats so to speak then by all means I don't I don't see an issue with it um now on structuring teams uh like this versus spreading that workout for prototyping I think there's something else that was mentioned too in in the either in the first comment or in the in the Reddit thread like the question itself but someone said like something about rotating people and I wanted to mention this is like a hybrid approach so if you have a prototyping team um I was kind of saying like not a

lot of developers are set up to like work effectively in a prototyping team but you can make the argument the other way too and that's if people are used to building prototypes and that's all they're doing um sometimes I can put them in a situation where they're not like they haven't been writing production ready code for a while and it's very different right because you want to think about I mean even when I was prototyping I would try to think about how can I write testable code not because I was going out and writing tons and tons of unit tests for it but because if I can write testable code in the first place and it's not taking me extra time to do it if I need to hand something over cuz we're not scrapping it then you don't have to like say oh it

was just prototyped and rushed and written really poorly instead you could just take it and in fact I did get to have some success with this one of the last things that I wrote that was integrated uh by another team they they said in fact they didn't even need me to help be with them to integrate because they said it was straightforward enough which is a huge win but I think if in terms of balancing out a team there is a huge opportunity here where I talked about this on another video recently where you could basically if you had a prototyping team have people that are situated on this team again depends how many people you have on the team the size of the company uh but they could be building prototypes and then what you could be doing is finding uh integration points so

say you do a prototype and it's not something that you that the question was answered and it's hey we want to go forward and find a way to productize this you could take one of the engineers that was working on that have them have them go work with the integration team to go build it whether that's a whole new product whether that's a new feature set or area of features in a product or service um have them go work with the team to go build that now when that happens your prototyping team temporarily shrinks right you're kind of dedicating one resource to go help with that there's nothing wrong with it but that might be an opportunity where you can actually bring in uh someone else so depending on how much uh flexibility and stuff uh movement you have within your teams could be a

really cool opportunity to bring someone else in um to try learning about prototyping so they could be um not to assign like a like a level but like they could be more Junior when it comes to prototyping so you teach them about how to prototype get them ramped up get them to understand it um and that could just be a temporary rotation thing that could be something where again depending on the size of your company and your teams where you're like hey you're you are the next it's not really temporary it's like you're you're a permanent member of the team until you have your own integration or we swap for some other reasons but uh this could be a really interesting way to breathe more life into the team give other people opportunities not only to prototype but the Prototype people to go back to

building production ready software so um I like I said I left magnet before um we got this team to this point but I think that would have been my I don't want to say long-term Vision it would have been the thing that I wanted to work towards trying so I need to be very transparent I never got to the point where we were doing that but that's what I was aiming for was to be able to have uh you know prototyping team members go to to integrate um and it's because at least the scale we were at there was always interest in prototyping um and I think a lot of uh interest in like hey I don't want to I don't I've been working on one team and I've been doing more maintenance and I really want to try something else like I think giving

those types of people an opportunity is uh is great so um overall I would say yeah not the role of the architect but like any like small company it's not it's not wrong to have people doing this kind of stuff it just might not be um the most effective and that's okay uh because right now it might be the most effective you have someone that's able to do it and they're doing a great job awesome uh just have awareness I would say that's probably the the best word make it a conscious decision have awareness and uh that way as your architecture needs change versus your prototype needs um you're not pulling this person in two different directions um prototypes done on teams I think uh sorry on like a dedicated team I think does work well because of the mindset you need for prototyping um

I I'm not a huge fan of scattering all of your prototypes across all of the teams and it's not because I don't want to share that opportunity with people it's literally because of the mindset requirement that I was mentioning um it's not to say that no teams are allowed to experiment with things like that's totally fine uh but if you if you need if you have the the need to basically have a pipeline of ideas getting answered and then you inject that into all of the other teams sort of uh uniformly or sporadically I think it can actually be distracting it might very well depend on the type of work but like I said how you approach prototyping which is really just how do we get a business question answered um I think that can be super distracting for some individuals so that's the only

reason I kind of caution against like um getting everyone to do it but I hope that helps that's my experience and my opinion on this kind of stuff um yeah hope that hope that Insight helps if you have questions you want to answered leave them in the comments or look for Dev leader on social media and I will see you next next time take care