...

Qualities of a Highly Effective Architect

Originally aired:

About the Session

Many developers aspire to become architects. Some of us serve currently as architects while the rest of us may hope to become one some day. We all have worked with architects, some good, and some that could be better. What are the traits of a good architect? What are the skills and qualities we should pick to become a very good one? Come to this presentation to learn about things that can make that journey to be a successful architect a pleasant one.

Transcript

Hey folks, it's a pleasure to be here, to talk about qualities of highly effective architect. I want to talk about: What does it take to be a really good architect in organizations? I'm going to switch over here to just using the slides over here because I'm having trouble projecting it with my monitor. Actually, let me try something really quickly here. How about switching over?

What I want to do here is talk a little bit about: What does it take to be a good architect? When it comes to the term “architect”, what comes to mind when I say the word “architect”? Well, oftentimes when we talk about architects, architects want to be important people in organizations and when it comes to architects as a result, we often think of the architect from The Matrix movie.

Well, unfortunately, that's not the kind of architect we really want to be. We want to be architects who actually serve the business, serve the purpose and actually help the people as well. I want to start by referring to a wonderful article by Martin Fowler. And if you Google for it, you will find it, it's called “Who Needs an Architect?”

I won't deny the pleasure of reading it for you. It's a very short article, wonderful article. I would encourage you to Google for it and read it. But one of the things I want to mention in that article really is, he talks about the role of an architect and that's kind of what I want to emphasize, is a good architect is somebody that mentors the team and he goes on to say that a good architect tries to remove themselves and then promote the rest of the organization to improve and do the work.

I want to talk about 12 qualities of being a highly effective architect. The very first thing I want to start with is “Be a mentor, not a tormentor.” This reminds me of so many different instances as I worked through organizations, but in particular, I remember about one particular instance. I was consulting for a company, and as a consultant, I come in and go over time, and one of the times I went back to the client side, a developer came to me and said “Hey, I've written down a few questions along the way, and I have been waiting for you to come by to ask you those questions”, so I went and sat down with the developer, answered the questions. And when we finished, I said “You know, you said you had written down these questions and we were waiting for me to come back, but your architect is much more knowledgeable about this.”

Let me move the crosstalk over there. One of the things that the developer said was “You mean I should go ask the architect?” And I said “Yeah, you know, the architect knows more than I do”, and the developer said “Maybe you don't know this, but any question to the architect is received with the response: ‘Are you stupid?’” And that's really sad because when you are an architect, when you have this team to really work with, it's a responsibility of an architect to mentor and work with the team and not to really go around insulting them. I'm going to say that nurturing is a professional responsibility that each one of us carries. It is our responsibility to really nurture the team.

You may ask the question, “Okay, that's great. If I nurture the team, they are going to be improving, but what's in it for me?” And I want to be honest about it. We’re not saints, we definitely want to do good things and nice things, but there's gotta be a return on the investment as well, but I'm going to emphasize that knowledge is the only wealth that grows when we share.

If I give you $10, I'm poorer by $10 tomorrow, but if I give you some knowledge, I am learning as I am helping you to learn as well. By working with the team members and nurturing them, we become more knowledgeable, and as a result, we've become more valuable over time as well. That's our professional responsibility, but we get something in return as well doing it.

I’ve talked about the emphasis of nurturing a team and being a mentor, but when it comes to interacting with the team members, it's important to criticize ideas and not people. Sometimes we get carried away and we don't realize along the way that we are trying to really attack people rather than focusing on the ideas and criticizing them.

It's extremely important to criticize ideas, but not so by really insulting people. That is something we gotta be very careful about. The question is: How could we possibly be able to do this? And the answer to that question is we want to really keep the focus on the technology, the concepts, the ideas, and be very mindful and empathetic about the people that we work with.

After all, one of the things we realized in development is that what we work in is full of tradeoffs. After all, architecting is really evaluating tradeoffs every single day. What I say today may make sense. It may not make sense tomorrow. It might be a great idea today, may not be the brightest idea tomorrow.

We all are going to have good ideas and bad ideas over time, but whether it's good or bad, depends on the context. Depends on various factors. So, rather than trying to criticize somebody or making fun of them for suggesting ideas, if we can instead ask for the pros and cons evaluate it, that is one of the things we need to do.

For example, suppose we’re trying to evaluate and pick what frontend framework we want to use, what library we want to use. Maybe the debate is whether we should use Angular or React when we should be using Vue, for example. Well, the point really is that, how do we decide this? Well, if you ask somebody for why they like something, if they say that’s the best thing ever, or if they say that's the worst thing ever, those are biases people carry with themselves. Instead, what we need to really do is to focus on the pros and cons. If somebody cannot explain to me a good reason to do something and also reasons why it may not be used, then they're not really taking the time to evaluate it.

There's an interesting technique called “Debating with Knives”. You are sitting around with a group of people. You ask people to put their dining knives, some facing away from them, others facing towards them. Now, after having set this up, you can talk.

For example, I’m going to talk about why Angular is really good to use, but the person next to me, whose knife is facing in the opposite direction than my knife is, speaks against it and says why Angular shouldn't be used.

We go on with this for a while, and at some point somebody rotates the knife, and everybody rotates their knives. Now I should speak against the idea, and the person next to me should speak in favor of it, so if somebody cannot speak on both sides, then it means that we are not taking the time to really evaluate it.

The main idea here is to really find the pros and cons of things, so we can actually select things based on the merits of it. That is something we should really strive for in our discussions.

The third thing I'm going to say is “Guide, don't dictate”. Once we grow up to become architects, somehow, sometimes we may feel like our job is to tell people what to do and how to do things.

That is really not a way to be leading as an architect. You don't want to be dictating to the developers and the team what to do, but instead step back and serve as a guide so they can mature. And it feels like you're working in a team, which is filled with adults, a mature team who can learn to make the right decisions along the way. That is something we need to build into it.

I'm going to say there are two kinds of people that scare me the most: those who cannot follow instructions and those who can only follow instructions. Both of these types are really dangerous people. You give somebody something and say “Do this”, and you come back after a few hours and they're sitting there saying “Gosh, I followed your instruction. It didn't work”, and you're like, “Gosh, you know, that's a guidance. Why can’t you improvise on it?” Or somebody says “I don't have a clue how to do it”, even though instructions were given to them. You want the team to mature and be able to take some risk, try out a few things, make mistakes, and that's how people learn. You want to really empower the team to be able to do that. The team may actually end up discovering things.

This reminds me of an experience I will never forget. I was working with a developer and the developer came to me and said “How do I do this?” And I said “I know exactly how to do this, but I'm not going to tell you that right now. Why don’t you go try in these directions and maybe spend an hour, and if you find something, that's great and we can look at it. If not, come back and I'll give you a solution to do this”, and only 30 minutes go by, I was walking down the corridor when the developer said “Oh, by the way, thanks for that advice. I found an answer and I was able to use it. I found a solution and was able to use it”, and I was curious. I said “What did you find out?” And I found out the developer had found a solution much better than what I had thought about. So in this process, I actually ended up learning and we may be able to discover something from this experience. Of course, if the developer is not able to find any good solution, you always have one that you can provide, but giving that opportunity is extremely important.

Well, the next thing to think about as an architect is to really practice collective ownership. I really don't like a work environment where there is this straight boundary. This is Sarah's code. This is Joe's code, and this is Roger's code. No, I don't want to have this territorial ownership of different areas of code. I really like collective ownership. Now, obviously you may say “If everybody's going to do everything, won’t we be really slow?” Yes, we may be slow in the beginning, but it reduces the risks and can make things faster over time as well.

There's a term called a “truck factor” in a lot of teams. The truck factor is the number of people on a team that should have to be run over by a truck and get killed for the project to fail. I know that sounds really sad, but unfortunately, in a lot of companies and teams, that truck factor is a value of one because one developer is the only one who knows how something works, and God forbid this particular person gets run over by a bus and dies. The project can collapse, so we want to really reduce that truck factor by having collective ownership of different people on the team.

From the point of maintainability of the code, I'm going to say, I know only one way to write readable code, and that is to ask a colleague to be able to read it. That's one of the ways to really reduce the errors in code, make the code readable, maintainable as well. With collective ownership that naturally begins to happen because multiple people work on the code base continuously, rather than a territorial ownership that somebody takes on the code.

Allow developers to figure it out. This is a little bit like the guide don't dictate, but this goes a little bit further as well. When developers are experiencing and working with the project, you really want to give them the opportunity for them to go out and explore and figure out solutions.

One of the reasons is, it really raises the bar. They become more competent. But also, it brings their loyalty because when they have done things on their own, they're more committed to, and more motivated to work on things. This reminds me of an experience. I was working on a project with Stuart Halloway, a good friend of mine who is a part of the closure community now, but this was years ago, and I joined this project, and this project has been going on for a few weeks to a few months at that point.

When I joined, this was like the first few days of the project, and I was looking through the code and I went to Stu, I remember, telling “Hey, there's a much better way to design this than the way it's been done”, Stu could have looked at me and said “Oh, Venkat, why don’t you shut up and go, just continue to code because we have already gone through it before”, instead, Stu looked at me and said “What is your idea?” And I said “Here's the reason why this should be designed this way and not like the way it is being done”, and then he looked at me and said “Would be nice to really be able to try this out. What do you think?” I said “Oh, I can just prototype this very quickly”, and he said “How much time you need?” I said “Oh, I think I'll need an hour”, he said “The time starts now”, so I went back to my desk. I was absolutely happy, and I started working on it.

Ten minutes later, I went back to him and said “Hey, I'm done with my analysis and prototyping effort”, he said “That was really quick. What did you find?” I said “I found that I'm stupid”, and he kind of looked at me and said “Well, that's not what I wanted to hear. Tell me what happened”, and I said “Well, here's the solution I had in mind, and here's what I tried, and when I tried, I can see these disadvantages that I did not see in the beginning, and now I can see why, even though that other solution did not look really optimal on the surface, it’s actually a better one.

He looked at me and said “I really wish that we could have gone with the idea you proposed, because I do think it's a better idea, but I really agree with all the cons you mentioned as well. What do you think we should do?” And I said “Well, we should just continue with what has been done already”, but now I was committed on one hand. Very motivated, but also had the deepest respect for him because he didn't reject the idea. Instead, he gave an opportunity for me to really try it out, and absolutely, I was on board and aligned with what's happening moving forward. That is something we should really encourage, for developers to figure things out, but it also requires one other thing, where it should be perfectly safe to be honest. This is one of the things I want to emphasize really in a team.

Suppose we are working in a team and I am by the water cooler, you come along and you say “How's it going?” And imagine I say “Oh, you know what? I was talking to Mani yesterday, and what a terrible developer he is. He was actually working on this code, and he did not even know this fundamentals and basics, I wonder how they hired him and where he went to school”, what are you going to do when I say this about Mani? You're going to be thinking about this and saying “Hmm. If this is what Venkat talks about somebody else to me, I wonder what he talks about me to somebody else”, well, I completely eroded your trust in this conversation. On the other hand, if I focus on the positives and help people on the team, I am going to gain your trust along the way. Everybody has great ideas and everybody goes through a learning curve.

There are a lot of things I know, and a lot more that I don't know. I don't want to pretend to you that somehow I know everything and to be humble and to be honest is extremely important. At the same time, to promote other developers on the team to be honest, and to really provide a safe environment for them to be honest is extremely important in this to build a better team, and as an architect and as a team leader, we can work towards developing that very nicely.

This came out of an experience I had last year and I tweeted that day saying “Funny how some ideas go from brilliant to stupid within minutes of prototyping.”

I remember this day, actually you can see the time over there. It was 5:30 in the morning. I had spent a couple of hours already, I usually wake up pretty early in the morning, and I was trying to solve a pretty difficult design problem. I was searching and working on solutions and I came across an article that explained how this can be done very effectively. I remember reading it and screaming saying “Oh, my gosh, that's brilliant! I never thought of this!” And I'm so committed to this great idea, but something, experience, tells you “Maybe I don't want to take that idea and just put it in the code”, so I went off and created a standalone prototype, and as I started working with that, soon enough I found out all the problems of using this idea. While it looked brilliant in the beginning, it ended up being a really stupid idea. I completed rejected this article, threw it away and went back to the design to discover a better solution that would actually work.

That's one of the things I want to emphasize here is, as an architect, you may come across a lot of different solutions, and you should, but when you look at a solution, don't read about it and take it at face value. Always create a prototype, because that experience really helps us to understand the ins and outs of things, rather than just looking at something at face and saying “Oh, this is great”, and then realize that, after all, it’s not.

That is something to do, is to really make sure that this is actually an idea that's worth its merit. And of course, in order to do this on a team like Stu did, you want to really time box your effort. Ask the question, “How much time you need?”, and give them time, whether it's a couple of hours, couple of days, depending on the complexity of the problem.

You could even pair up developers to work on this together during this time box opportunity, so we can actually come back with a good solution that can be evaluated and tested, timed and tested before we adopt it. Things that reduce the risk for us in our teams as well.

The next thing I want to talk about here is to focus on outcome and not process. How many times we do this, where we are told this is the process you have to follow in this company or in this team. Well, while processes are necessary, I'm not going to say that they’re not, we have to keep an eye out for making sure that we focus on the outcome and not just on the process.

Now, as an example, I remember being called by a particular company. This was in the Northern part of the U.S. They invited me to come and teach a course, a week-long course on a particular technology.

I show up over there, and as I walked in, the manager said “Thanks for coming.

You're going to spend the week with us here, but before I take you to the training room, maybe you want to know who really was the reason for you to come here?” I said “I'm sorry. I thought you found my availability and invited me. Now I'm curious. Why am I here?” And he takes me into a room. There are two developers in this room with the lights turned off, sitting in front of the keyboard and working away and he said “These two are the reason why you are here”, I said “Enlightened me, give me more details”, and he said, “Well, these two developers went to a conference, heard you speak, and they came back and they were like on fire because they had found out a solution they had not known after listening to it. They didn't tell us this is a better solution, but went off to prototype it. And after prototyping it, they came to us and gave us the pros and cons of it and showed how this newer technology would solve every single problem that we have. And then give an option for us either take it or leave it. We evaluated it because of the prototype they did. We didn't have a theory to talk about, but a real example to work with and we analyzed it. And we realized that this is a much better solution than what we have been using. So now you are here to train the entire team to move in this direction so we can get deeper and start using this and embracing this technology.”

One of the things to think about is prototyping beats any arguments you can have with your team, because you are able to convince your team that this is a better technology, or not, based on developing a prototype, and that leads towards a better outcome because the goal is not to follow a piece of process, but the goal is to produce a better outcome, a better software, for they value all those good things we talk about and we need to really keep our eyes on it.

The next thing of course, as an architect is we need to learn so many things every single day. We have to learn about technology. We have to learn about frontend, the backend, the cloud computing, the microservices. It seems overwhelming. And you may look at me and say “Come on, Venkat! Are you serious? In addition to all of that, you're telling me I have to learn about the domain as well?”

It is absolutely critical to learn about the domain as an architect and not only the technology that we work with. Part of the reason is we often talk about extensibility, but what in the world is extensibility? That seems like the Holy Grail in software development, isn't it? But when it comes to extensibility, it is something we have to strive, but what makes software extensible?

Well, unfortunately, we can think about theoretical extensibility, and what we end up doing is create complexity rather than extensibility of software. I'm going to say there are three kinds of people on every single software system that we develop. Now, what are these three kinds of people that are in development?

Well, the first kind of people are the people who know the software, but not the domain. These are generally the programmers. The second are the people who know the domain, but not the software. The third, small category of people are the ones who know both the software and the domain. Those are the three kinds of people.

Oh yeah, I get it. Let's politely ignore the fourth category. Now, among these three kinds of people, the third one is far and few. I remember by name these people that I worked with over the past few decades. Here's a very easy way to find them in your companies: when you're in a room meeting, quickly turn off the light. These are the people that will glow in the dark. You will know who they are.

These people are far and few, but they understand the domain and the software really well, but I'm going to say these are the people who can really think about extensibility.

You know, I remember working in engineering, chemical engineering. I would go to my domain experts, chemical engineers, and I would say something, these were the nicest of people. They won't laugh and they will look at me and say “Hey, Venkat, I'm really glad you thought about this, but if we ever do this, it'll be a violation of all physics.” “Oh my goodness. I'm so glad I didn't write that in the code.”

Or other times they may look at me and say “That's actually a brilliant idea. We should really think about it, but that does not apply to hydrocarbons”, I don't know what that means, but I'm so glad I asked them. On the same token though, they may have a hypothetical idea of what can be done, but as a software developer or an architect, you may have a better idea of whether that's possible or not.

The feasibility is extremely important too.

By having these two knowledges, we are better at designing software. Obviously, not all of us have as much equal domain experience and software experience, but this is one of the reasons why we have to collaborate together. But as an architect, it's important to continuously learn, not just the technology, but the domain as well.

That brings us to, not just learning, but another quality is to actively unlearn. This is something I've noticed a lot in my experience. When you’re working with developers often, and as architects themselves, we want to continue to ask the question, what should I learn? What should I pick up tomorrow? Well, it's not just the act of learning, but an act of unlearning is extremely important, and learning is relatively easy, but in comparison, unlearning is a lot more difficult.

Part of the reason for that is unlearning is a very deliberate activity, so we have to put a lot of effort to actually unlearn and change our habits and change our behavior and change our thinking as well. And that takes a lot of effort in general. In a sense, when it comes to getting better at what we do, it's not a question of learning, but also actively unlearning. So to deliberately ask the question, what are the practices I want to acquire? But also to ask the question, what are the current practices I want to replace and replace them with the new skills and knowledge and learnings that I want to bring in?

Unlearning is part of what we need to do as well. I work with some really smart developers and architects over time, and what I've noticed with them is they’re extremely good in learning, but have struggles and hard time adopting certain ideas, not because they couldn't learn. It's because they couldn't replace their habits and thinking with a different one. That active unlearning is extremely important.

Then, of course, diversify your knowledge portfolio. This is, in fact, I would say one of the things that I've learned personally, myself. In my early part of my career, as a very young developer, Green behind my ears, I was so proud and adamant as being a C++ programmer, and I’m like, “I don't need to do anything else. I know there's one thing I'm really good at it. I am doing database modeling and I'm the happiest guy in the world”, then I realized one day, how much I know in such a small area and how little I knew of so many things, I was absolutely scared, and I realized that I would never be able to become a better developer, leave alone, be a leader in the software area, if I had such a narrow understanding. So, diversification was a very important mission for me to go out and learn.

The pragmatic programmers tell us we should learn at least one new language each year. What they mean here is not that you know Java, and you're going to learn C#, that doesn't count. The language you want to learn should be very different from what you already know. In fact, I often say, you know that you're learning a language that is different and worthwhile if you kick and scream, and cry and it frustrates you. That is one of the key things, is to go out and learn something completely different. It should really take you out of the comfort zone.

So, if the language looks easy and comfortable and familiar, you are really learning the wrong thing. But why?

When you learn something completely different, it changes the way of thinking. It gives you a new set of tools that we otherwise don't even experience. Honestly, over the past few decades, this has been the most aha moment for me, used to go out and learn something completely different and sit there and say “Oh my gosh, I never thought about it this way”, and that changes the way I approach and solve problems moving forward.

I'm going to say the amount of time you need to learn something new is inversely proportional to the number of different things you've learned in the past few years. I mentioned this, so essentially, the amount of time you learn.

I get a message here from Phillip saying to put the presentation on presentation mode. I am not able to, but can you confirm that you are able to view the slides in the current mode? I can't put it in the presentation mode for reasons that are beyond my repair at this moment. Phillip, can you respond to me when you get a chance? Thank you. So, when it comes to this, I was working on a… Yeah, that's perfectly fine, as long as people are able to see the content, I want to focus on that. Thank you.

So, essentially in this case, I remember teaching a course in a company and I noticed that there were two developers. They were about the same age and they were a bit older than me at the time. I think they still are. These two developers, even though about the same number of years of experience, but I would present the concept. One of the developers would say “Oh, wait, can you go over that? How is this in comparison with…”, and ask me to compare with other things. The other developer, on the other hand, would say “Oh, come on! Why do you bother me with this? This is so different from what I know”, and that's when I realized the first developer was having such a great time understanding and adapting because the developer had diversified the knowledge portfolio. The other developer, on the other hand, was having such a hard time because he was much less familiar with a lot of different things, knew only a few things.

The more we diversify our knowledge portfolio, the better it is for us. One other thing to keep in mind is that learning happens in deltas, and that's what we do all the time, is that learning happens in deltas, and we don't really learn a whole lot of things in a short amount of time, but we keep learning in increments over and over and over. The more continuously we learn and the more different things we learn, we really get better at it over time and that is something we need to really do. Learning happens in deltas and we have to diversify that.

I'm going to emphasize that lead by example. This is something I want to emphasize. I remember being in a really large corporation and this architect would go around and tell developers what they should do. Then I realized this architect was not capable of doing any of those things and was just interested in telling the developers they should be doing it. Unfortunately, the developers did not know how to do it, and they didn't have the guidance to do it either.

This is when I realized that we should, as architects, always lead by example. That is something extremely important. So rather than telling people how to do things, if you can roll up your sleeves and pair with them and say “Let's do it together”, not with the intention of showing off to them, but with the intention of guiding them along.

You can say “Hey, we can do this. And if you get stuck with it, I'm going to work with you, and we can figure this out and how to do it”, and that is something really important, but unfortunately, in a lot of organizations, thank you.

Unfortunately, in a lot of organizations though, the architect sometimes is trying to create this boundary, and trying to set up a process and regulations. I remember one company where they had a team of architects who would evaluate technology and only when they approve somebody else can use it.

That's governance. There's nothing wrong with it. But the problem was they will take so long to approve that that technology would become irrelevant by the time they did. And I came to the realization that architectural committee is where good ideas and innovation go to die. That is not the type of organization you want to be building.

I want to emphasize this: you want an architectural committee to be there to provide standardization, but stop for a minute and ask the question: Does the architectural committee help to standardize, or have they helped really do stagnation? So, you don't want stagnation. You want standardization. And if the architectural committee is not swift enough and thorough enough at the same time, then they don't serve the organization.

They become a part of not providing innovation and they stifle the innovation in organizations. But one way we can actually foster good things in an organization is to lead by example. Now this reminds me of an experience. When my children were really young, I was telling them “Oh, you should brush your teeth every night before you go to bed, because that's hygienic. When you sleep, you don't want the bacteria to be growing. You want to brush your teeth every night when you go to bed. In the morning, you feel a lot more refreshed as well”, and so on. Well, the first night when I give the advice, the children are like, “Thank you, daddy. That's great. Let's do it”, well, the next day or a few days after, “Oh, I'm really tired. I don't want to brush my teeth today”, it’s like, “Okay, no problem, sweetie. You don't want to brush. That's fine.” “Okay. Can you read a book for me?” “Oh, of course. Go to the bed. I'll come and read the book for you, but you've got to wait for a few minutes. I'm going to go brush”, and then they're like, “Gosh, if you're going to go brush. I might as well come and brush with you”, I've noticed this on other occasions too. “I'm really tired. I don’t want to go for a walk”, you have a nice partner and the partner’s like, “Up! Come on, let's go for a walk,” we can motivate each other.

By leading by example, we can actually do better than just telling people “You should do this”, and that's one of the things I expect from a good architect, is to really lead by example. A good architect practices what they preach and not just to impel people, but are able to actually do it effectively as well.

I'm going to say for application architects, it's extremely important for them to be able to write code. I cannot tell you how many companies I've been to, where the architect will always say the phrase “When I used to code”, sorry, that's not good enough.

If an architect cannot code and if they are going off of their previous experience, they become rather ineffective. I'm going to say an architect who doesn't code anymore turns into what's called a PowerPoint architect. These are dangerous people and they can draw nice pictures, but before anything useful gets done, they leave.

It's really important for us to be able to drive this development by partaking in the coding as well. And also, you know, I was recently talking to an architect and the architect listened to my talk and said, “Venkat, really great idea, but in my job, I cannot do that”, and I said “No, sorry, you’re saying it wrongly. It's not like you cannot do it. The word is you don't want to do it”, and he looked at me and said “Well, no, no, no. I really want to do it, but I cannot because I don't have time. I have so many other things”, well, the point is if you really want to do it, you'll find a way to do it. You don't have to write code full time, but just do hours every single day. Go pair with somebody and write a piece of code with them.

The amount of stuff you can influence the team and learn at the same time, it’s phenomenal being able to do that. As a result, that is one of the reasons why we should continue to code along the way.

It looks like my video feed got dropped as of right now. I'm hoping that people are still able to hear me, and listen to me. this is kind of hard because of not having the feedback loop, but if you're able to hear me and listen to me, if, Dilip can take me back, that'd be great, because my video just kind of cut off the feed. I really apologize, but we are trying to do the best with the lack of visibility on my part. I cannot see anything from here. It's kind of like literally speaking to a dark screen here.

Anyway, basically at this point, by being able to really work with the developers, we are being able to stay relevant. We are able to help and motivate the team, but also at the same time, we are also able to help the team really give us an experience to learn about something relevant. One of the other things to really emphasize is every technical decision has an expiration label, so we cannot simply make a decision and walk away.

It's kind of like the milk in the fridge. You can leave it there. But two weeks later, or three weeks later, it's going to smell. Architectural decisions are like that. Technical decisions are like that. You want to put an expression label on it and come back and revisit and see if it is still valid or we should change something. That is something we need to do continuously.

The last thing I want to say here is evolve the architecture. Now, when you're hired as an architect, you have this immense pressure to really create an architecture, but a really mature architect needs to have the mindset to say “I want to eventually create an architecture, but not rush into it.”

In the beginning of a project, we actually know very little, and as a result, the effort to create an architecture at the beginning is a fool's errand, if you really think about it. Mention the amount of confidence you have in the architecture, the confidence in the architecture should increase with the knowledge of the application as we develop it.

I can start with a 10% confidence. A few weeks or few months into it, I could develop a much better confidence and put a lot more emphasis on the architecture so we can evolve the architecture rather than pretending it is all set in stone and we know what we're doing in the beginning. One of the ways we can help with this process is to use what's called the tracer bullet approach.

The tracer bullet approach is where you develop a prototype of things, but also various architectural parts you put in marks and placeholders, and you build on it. This gives a nice end-to-end feedback loop, and if something makes sense, you can turn that stub on a mark into a real object over time, but if you feel like that's not necessary, you can discard it. What a great saving of time and effort, if you didn't have to build the stuff that you don't actually need. Build the architecture vertically rather than into horizontal layers and use tracer bullet approach to build it.

We talked about a number of different things in here. I want to spend a few minutes on Q&A and listen to your questions or comments along the way, but quickly to summarize, here are the things we talked about, the 12 ways to be a better architect and how we can develop and build with the team. The first thing we talked about is to be a mentor, not a tormentor.

Then we talked about criticize ideas and not people. Then we talked about guide and don't dictate. Practice collective ownership with the team and emphasize the team practices collective ownership. Allow developers in your team to figure things out, but make sure to provide a very honest and safe environment for them to thrive in.

Focus on not the process, but the outcome. But as an architect, spend the time gaining domain expertise, but also take the time to unlearn as much as you learn as well and diversify your knowledge portfolio, don't focus on a narrow area, go learn something completely different, Something that's going to make you really angry and frustrated, but that changes the line of thinking that you have, and lead by example. And then of course, be part of the team and write code with the team. Spend a few hours at least, every day, planning with the developer and write code with them and see how remarkable this actually becomes over time and that can be extremely beneficial. So, I hope that was useful. I want to yield and answer some questions.

See Highlights of
Wurreka

Hear What Attendees Say

“Once again Wurreka has knocked it out of the park with interesting speakers, engaging content and challenging ideas. No jetlag fog at all, which counts for how interesting the whole thing was."

Cybersecurity Lead, PwC

“Very much looking forward to next year. I will be keeping my eye out for the date so I can make sure I lock it in my calendar"

Software Engineering Specialist, Intuit

“Best conference I have ever been to with lots of insights and information on next generation technologies and those that are the need of the hour."

Software Architect, GroupOn

Hear What Speakers & Sponsors Say

“Happy to meet everyone who came from near and far. Glad to know you've discovered some great lessons here, and glad you joined us for all the discoveries great and small."

Scott Davis, Web Architect & Principal Engineer, ThoughtWorks

“What a buzz! The events have been instrumental in bringing the whole software community together. There has been something for everyone from developers to architects to business to vendors. Thanks everyone!"

Voltaire Yap, Global Events Manager, Oracle Corp.

“Wonderful set of conferences, well organized, fantastic speakers, and an amazingly interactive set of audience. Thanks for having me at the events!"

Dr. Venkat Subramaniam, Founder - Agile Developer Inc.