The Architect's Feelings

One of the more interesting transitions a programmer undergoes is when she becomes a manager of other programmers. It might happen in different ways. Sometimes as a process with a healthy pace. Or overnight because the company needs a manager and you just happened to be there. But wherever observed, it is a fascinating path that involves strong, sometimes turbulent feelings.

Many aspects of this process have been explored in management books. How to build a team, how to cultivate the team spirit, how to create a community,respect your programmers, avoid micro-managing, be courageous, recognize without soapiness - all true and extremely important aspects, but all could pertain to any project management role in any industry. There is one dilemma, however, that is very unique to software architects. That is, how to translate your feelings into architectural explanations.

What do I mean translate feelings to architecture? We architects don't deal with feelings. Haven't we came to this field - or brought to it - because we stayed away from all those elusive concepts, multi-faceted, never well-defined, called feelings? Haven't we always tried to ignore, if not mocked all that nonsense that belongs more in the Faculty for Scandinavian Literature than here in CS, the Computer Science department?

Well, when I say 'feelings', I have to explain that this word means to me two things, somewhat related but still different. First, when used by psychologists, a 'feeling' would mean 'emotion'. It could be anger, happiness, enthusiasm, or any of those amorphous states of the mind, which a person posses, exists inside of, and which would usually paint the way he or she experiences events at that moment. Probably such feelings would be categorized as either being good or bad. Some religions, especially South-East-Asian kind of religions, try to teach their followers how to reach a state of no feelings at all - surprisingly a hard thing to do. Funny enough, this lack of feelings is always an experience that makes many people very, very - hmm, well, very happy.

But when I say 'feelings' I don't mean all that. I just mean, those things that you don't know how to explain in words. The elusiveness is still there, but its certainly not about emotions - its that accumulation of past experiences that paves the way you design your code and your system. It is the inexplicable driving force that dictates the way a programmer codes. And for the architect, it is a set of many reasons and rules, amalgamated in a strongly felt opinion.

For this architect, this poses a difficult dilemma. How to explain your opinion that a certain thing needs to be done in a certain way rather than the other?

There are several types of architects, and not every one of them would face this dilemma. To start with, there is the architect who does not posses any deep feelings about the code at all. He got to be an 'architect' because he wanted to manage, and the company needed managers. He doesn't care because he never cared - he really focused his career on becoming a manager, not a programmer. In fact, he might have been a programmer for a really, really short period of time. Since he manages a team of programmers, and he has a programmer's background, he is the architect too.
For him, what's important is that the code would work. He does not need to think about explanations. This module doesn't work, need to be fixed, please fix your bugs, and if you have some time left, could you perhaps take a look on the bug list and pick some of Michael's bugs, too? pretty simple.

Then there is the architect who is still a programmer. He cares, oh he really does. He might even care too much, and that is sometimes the problem. He cares so much, and enjoys coding so much, that he took on himself to code some of the modules himself. He might have just became an architect, still programmer at heart, and he does his game well, taking great pride of it. So when the project gets into a thunderstorm of bug attacks and delays he jumps in to save the day, solving these bugs himself. So he doesn't need to do any explanations either. He just codes.

But then there is the third kind of architect. This is the architect who is still a programmer at heart, but has no programming studio is at his fingertips. He might be an architect whose project got so big, that he needs to manage and couldn't afford to program any more. Or the architect at the start-up company, whose project is still small, but the resources are low, and he has to make up for the understaffing. He has to be the business analyst, the tasks distributor, the project plan owner, the tester and sometimes even the company technological evangelist -- so his time of programming is very limited at best.

For this kind of architect, a battle awaits. He has enough experience to know that a system needs to be built in a modular, loosely decoupled fashion, with just the right amount of componentization and a framework that would support - and promote - code re-use. His programmers know design patterns inside out; they were tested on it in the initial interviews. What they don't know, and he does, is that the system can't be just programmed. It has to be based on all of the above foundations, or else it will collapse under its own weight on doomsday.

But these foundations are pretty elusive too. They are not soup ingredients that we just add to the mix and lunch comes out great. Certain data structures and certain algorithms needs to be built, that would serve the needs of that very specific project. Usually, this architect would have used the old Nike methodology of project management: Just Do It. He would have coded the framework himself, and explain later. The code lines would break the language barrier, explaining themselves to the programmers. But this time he can't.

This time he has to explain.

And this is one of the most difficult challenges to many architects. Whether not coding at all, or whether coding a little and managing a lot, they have to find a way of explaining what they feel on how the code should be written.

Many beasts need to be subdued. First, there is the ego. Your ego and your programmer's ego. You know how much you hated when managers - usually of the first or second above types - tried to tell you what to do and how to write your code. So you don't want to create the same resentment here. Sadly is that sometimes you just avoid talking to some of the developers which you sense have the biggest ego, or the more fragile ones. Actually the latter guys might be your best programmers.

Second, there is the time problem. As an architect with not too much time to program, how could you have time to explain? Probably you too are running after the bug fixes, the clients new request, the deadlines - or maybe they run after you? In any event, it's really not easy to find the tranquility, the isolation, the quiet hours to sit with your programmer and to explain.

And third, not always you know what to explain. With the Just Do It methodology, you have programmed many modules by just doing them, starting with a concept and improving it over time. How could you do it with your programmers when you don't even code in this project? To make matters worse, because you don't code, you don't know enough about the real problems of the particular system and might offer ideas that are not realistic. If you recognize it, it might instill fear whether you could really affect the architecture. If you don't, your programmers will listen to you, say yes, boss, and do whatever the hell they want to do.

But in all cases, the problem is the explanation. How could you find the right words that would describe the right solution, be listened to, and make an impact?

We could try to give some answers to that. We need to know that not necessarily they would be encouraging. In fact, they might not be important. What does it all mean?

The first answer is that it really can't be done well. A good project should have clear separation between managers and architects. Between hands-on'ers to paper pushers, we might be tempted to say - but not really. Good projects should simply give their architects enough room, enough meditative time to code the frameworks, the architectures that would support the system and self-explain themselves to programmers in modules to come.

Second answer is that if needs be, there is a way. I saw architects who didn't program a single line in a project but still could explain how the events flow and what each table field means. These are the ones that demonstrate that you don't have to code in order to understand, and that an architect role is sometimes to be a junction of knowledge first, and then a source of it.

What these architects do, is ask. Curious as a child, they move from programmer to programmer and look on his or her code, trying to understand each set of mind. Especially if they arrived late in the project, but also if they've been there from the beginning, not always an architect could grasp the whole system at first sight. This continuous learning refines their ideas, and establishes a dialog with the developers, slowly building a vocabulary of classes, tables, structures and ideas. Since they operate as junctions of knowledge, they see when a programmer is in need for a piece of code that could be reused from another's existing code base. They know when they need to put two programmers together. Slowly, they would establish enough common language with their programmers so they could inject their own ideas into the code, when the programmers agrees and understands.

Some may say that there is always some things that would never be achieved. That there are so many obstacles - ego, time, knowledge, so that all we do as architects is just trying to optimize. That perhaps we simply have to learn to live with the guilt that no one, no project, and no architect, is perfect.

But this will not lead us anywhere. Maybe the real answer is that we have to recognize that our main task as architects is explaining. Then, we would invest the time and thought to find the right approach to the sensitive programmer, the right time to experiment coding solutions, and the right words to explain it all.