Geir Hedemarks blog

The past couple of days, people have talked to me about architects. There are a couple of statements I have heard:

- agilists don’t do design

- we (my architect team) are supposed to work as a team with the developers as a self-organizing team. How can we do that, and still tell the teams that they need to do something differently?

This is all based on a couple of misunderstandings, I think. I will try to straighten them out here.

“Self-organizing teams can decide everything by themselves”. This is obviously wrong. If this is the case, then what is the product owner for? The team decides how to make something, but not what to make.

Mike Cohn wrote someting about this yesterday on his blog. There is obviously at least one proponent of agile – with a proven track record – who also thinks about up-front design, which means the teams around him are not all reactive. YAGNI, but you just might want to think about things for a bit anyway.

The product owner is one thing. Something similar applies to the scrummaster or the agile coach. People seem to think these characters don’t wield any power. This is also bunk. The scrummaster controls the direction of the team, almost in a tayloresque. The major difference is that the team is allowed to set their own pace. The same thing applies to the scrum coach – whoever thinks coaches have no influence is obviously not one.

I have to admit I am not a purist. I think there is a need to have a technical function – something like a product owner – to handle technical alignment and nonfunctional stuff at the system level in large projects. I don’t really care what this character is called as long as both the development teams and whoever is exercising the function are in agreement on what this function can and cannot do. I will continue to call the function “architect”, even if this will lose me some hardcore agilists.

Whoever is in a function like this should take care not to become just another developer. This is the first mistake any developer who is tasked with a different job makes. Once the problems start cropping up, it is very easy to fall back into the job you know how to do. I have seen this happen many times – and I did it myself, back when I started out as an architect/techie. The primary task of an architect is to ensure the teams are aligned. Life will become hard if this task is left unfulfilled.

This is where life gets hard. I don’t believe it is possible to get this technical alignment to happen without being a hardcore techie. I absolutely abhor non-developer architects. Still, I am saying techies who get this kind of mandate need to keep at least partly away from being a developer. Feel conflicted yet? You should. This is a very hard balancing act, which is compounded when teams do not agree and there is a need to be a part of all teams and none to be able to get things moving forward.

A coach achieves this by actively not delivering opinions. There are several ways of trying to handle this conflict, ranging from becoming “an opinionated asshole” who never delivers anything of value, going for the more military imperative style, through a coach-like style. Not everyone can adopt all of these styles, and I am not sure any of these styles are right in all situations either. Most architects lack psychology knowledge, and are ill-equipped to do their task.

I am reading “the greatest show on earth” by Richard Dawkins. On page 217, he muses on the building of cathedrals in the context of evolution:

An architect designs a great cathedral. Then, through a hierarchical chain of command, the building operation is broken down into separate departments, which break it down further into sub-departments, and so on until instructions are finally handed out to individual masons, carpenters and glaziers, who go to work until the cathedral is built, looking pretty much like the architect’s original drawing. That’s top-down design.

Bottom-up design works completely differently. I never believed this, but there used to be a myth that some of the finest medieval cathedrals in Europe had no architect. Nobody designed the cathedral. Each mason and carpenter would busy himself, in his own skilled way, with his own little corner of the building, paying scant attention to what the others were doing and no attention to any overall plan. Somehow, out of such anarchy, a cathedral would emerge. If that really happened, it would be bottom-up architecture. Notwithstanding the myth, it surely didn’t happen like that for cathedrals. (Footnote: My medieval historian colleague Dr. Christopher Tyerman confirms that this was indeed a myth that was invented in victorian times for idealistic reasons, but that there was never a scintilla of truth in it.)

This is a wonderful book – go read it.

So, it seems that our profession is now creating the same myth that was created a long time ago by (parts of?) the building industry. I am guessing whoever built cathedrals in victorian times did not perpetuate this myth, but builders of smaller things – things requiring architecture that could easily be handled by a small handful of people – could have used this myth to cut the architects out of the loop. You can still buy a small house without getting help from an architect. I wonder if there are any failed cathedral projects out there where a bunch of masons went wild?

Our problem is that the development business is very new. We don’t know how to define an architect role in a way that works yet, and we don’t know when we need to have this role around. I have a hunch that most who get this right are doing what they are doing by the seat of their pants.

I would also guess the definition of what a software architect should do is situation-dependent. Some teams produce useful installation instructions without being prompted. Others are completely at a loss and need a bit of guidance. Some teams are whipped into stopping their QA processes in favour of producing more functionality, and are never allowed the time to correct the shortcoming.

My own shortlist of candidate areas for guidance is:
- System-level QA
- Performance
- Versioning
- Deployment
- Technology platform (as in “all subsystems should use the same OS and middleware to reduce operating costs”, not “use junit 4.3.1″)
- Arbitration of interfacing conflicts
- Tracking of delivery by external parties, if applicable
- Moderation of time-to-market demands by showing the cost of skimping on structural quality
- Establishing an expectation of the lifespan of the software

I am writing an architecture mandate right now, where I am trying to find the balance between owning nonfunctional requirements, letting the teams be agile (or not, if that takes their fancy), and still opening the door for support if they need and/or want it. If I go too far in one direction, the mandate turns into a big ball of mud which won’t help anyone. If I go too far in the other direction, there won’t be room for change if there turns out to be a need for it. I am going to try to get reviews of the mandate every three months to try to get the whole thing right.

If you have any thoughts on this, please feel free to leave a comment.

I found a weekly in my mother-in-law’s flat today, with a relatively long article on intelligence (good), and why having an IQ of 180 didn’t necessarily mean you were able to get a good job (presumably bad, depending on your definition of “good”).

I started interviewing potential developers for positions around six years ago. Since then, I have seen a lot of resumes, and I have talked with a lot of people. The reason why I am writing this is that a friend of mine, who is a top-notch developer without any managerial experience told me he envied me because I have an insight into how an interview works from the employer side. Most people tend to get this wrong, so I will try to explain how my head is bolted together when interviewing. Hopefully, other people will think the same way.

Norwegian schools and intelligence

The backbone of the article I referred to seemed to be an assumption that very smart people get bored in the norwegian school system, and that Mensa is a kind of support group for the poor people who are cursed with an above average intelligence. There were quotes along these lines, at least, but I will try not to tar all members of Mensa with the same brush. The idea was that school work was so ridiculously easy that being interested in it was a bit beneath these people.

When I was at university, we had to jump through a number of hoops in order to graduate. Some of these hoops were knowledge-based (I remember a course called MA-105 with fondness). These courses were designed to be harder than adequate, prompting most students to have some thoughts about whether they wanted to go through with their studies, or to find something else to spend their time on.

The other kind of test put into the coursework was a test of willpower. Many students spent a lot of time finishing their M.Sc. thesis. Part of the reason was that the earlier grade of Cand. Real. was twice as long, and faculty had not completely caught up with this fact. Another reason was that students were mostly left to their own devices. Finishing the thesis was a different kind of filter. If you hired one of these people, you knew that you were getting a reasonably smart person with a will towards doing something.

Keeping students around indefinitely is a costly proposition, so these studies have now been restructured to provide much more guidance, forcing the students through the system faster. The downside is that candidates have not been sieved the same way as they were before. Employers have had to compensate for this.

This is why I think there is a broken premise in the article I read. The article is based on the premise that extremely intelligent people can do whatever they want. This is garbage. Intelligence is only one part of the equation. There are persons out there who are both highly intelligent and simultaneously too lazy to work at something for a significant amount of time. I don’t believe there is any connection between these two personality traits.

What does this mean for my interview?

There are literally thousands of pages out there explaining how to put a sensible CV together. The goal of these pages is to get you to an interview. From there on out, you are on your own. What happens in the interview is mostly a private affair.

Putting a good CV together is a very, very important task. It is not common for senior developers to read through 250 CVs. The contents of the CV is the first toll gate that gets you closer to an interview. If an employer gets 250 CVs, only three or four people get an interview. The other 245 people are – hopefully – not right for the job.

Sometimes, the sieving process means your CV will not get read. A local employer is known to have divided a bunch of CVs in two, binning one half while saying that he didn’t need unlucky employees. In other words, not getting an interview does not mean you are unsuitable. You may just be unlucky.

There are ways to grab attention. A girl who was applying for a position five years back tried to bribe her way into an interview by offering a hot balloon ride. It was all done with humour, and I still remember the CV to this day since she managed to tickle my interest. This is a bit dangerous since it depends on the interviewer sharing the same kind of humour as the candidate. Oh, and by the way, she didn’t get an interview, and I didn’t get a balloon ride, but it was a very close call.

Another guy in the same bunch of CVs was not that lucky. I was given a 5 cm wad of CVs. About 25% of that thickness turned out to be one CV. This bloke had added copies of everything – even a copy of his boy scout knots award. I also remember this CV for much the same reason – it gave me a laugh, even if it was more of an exasperated one.

The final CV I want to mention is the electrician with a six week course in building PCs who applied for a senior developer position. Take care to understand what the position is, and don’t apply if you are clearly not eligible. You will be seen as a time waster.

I will look at your positions, I will look at the technologies you claim to know. I will have a look at your cover letter – if you say you are interested in switching pastures, I may still have room for you. The ones I think best match the skill set I need, who will be willing to work for the money I have, and who seems to fit socially with the team I want to build will get the interview. It is that simple, and that hard. Prospective employees usually have no idea how I want my team to be built.

There are other ways to get my attention. If you know someone I trust, you should get them to give you an introduction. If the introduction is good and I have good experiences with referrals from this person, you will almost certainly get an interview.

So, let us say you have been able to get an interview. Now what?

Time for the interview

Norwegians are usually an informal lot. I usually wear a sweater, t-shirt and jeans to work. I may wear a suit if I feel like it, but I usually don’t. It would not be playing the part of techie hereabouts. I want you as a candidate to dress much the same as I do, but a little neater. Business casual is good. A three-piece suit will earn you a couple of questions to try to figure out what is happening. Turning up smelling of sweat, and possibly stale beer, is a surefire way of losing the interview on the spot. Talks with employees about the need for personal hygiene are not experiences I cherish.

When the time comes to meet, we will probably meet on neutral ground, which means the reception or somewhere like it. I will offer you coffee, water or something else, and try to put you at your ease. If you are very nervous, skip the coffee and take water instead. When you are in the meeting, try not to use your mug or glass of water as a lifeline. Many people – myself included – grab onto something for comfort when they are under pressure. That is all fine, but you may be holding onto the cup when you should have been pulling out some paper to draw something for me.

Most people are very, very nervous. There is no need to be. My job is not to kill or maim. My job is to find out if we should work together. I really won’t bite. So try to relax, yeah?

There are two ways we might start. If nobody has done it before, I will present the company and what it does. If someone else has already done that, I will pare it down, and just describe myself and what I do.

I think there are two ways the remainder of the interview can work out. If you are talking to a senior techie who has lost his touch, and is willing to do full-time administration, you will probably breeze through the interview. I would ask myself if I really wanted to work for an architect like that.

The why…

Now, here is a dirty little secret: I don’t care if you know the contract of the equals method in the java Object class. I may ask, but the contract is not the endgame. You can look the contract up if you need it. My goal is to get you talking about contracts, equality, possibly cross-references to Haskell, ruminations on how hard it is to implement equals, why you are fed up with ORM, have I tried the new eclipse plugin that does this, that or the other, …

The details are not interesting. When I ask someone why they prefer to develop on Ubuntu, I don’t care about their reasons. I care about the reasoning that lead them to the decision. A developer who says he prefers jetty over tomcat probably has some reason for it – even if the reason only is that he has never seen a reason to fix something that works, and haven’t been able to prioritize toying with other containers. I want you to show me that you are not just parroting what other people are doing, but that you understand the reasons behind what you do.

The how…

I will probably also ask quite intricate questions about stuff you say you are proficient with. Sadly, the term “expert” is very variable. “Expert” from one CV means beginner-level, while another CV might hide world-class knowledge. I have had people claiming to know unix well not be able to tell me what services were running on one of my boxes. I need to know this stuff in order to map your skill set against my expectations, but it doesn’t mean much either way. Competent people are able to pick up technology fast. I will need to know if you need teaching.

I will also try to figure out how you learn. Do you read books? Blogs? Go to conferences? Do you participate in something that gives you knowledge? What do you do on your time off? For norwegians – are you comfortable reading english books? Speaking english? How about italian?

… and how it all works together

There is still a relatively large amount of developers out there who do code-and-fix. I need to know how structured and disciplined you are. I will try to draw you out on this, and you should let me. Most of the people I interview have absolutely no idea how their code production process works. How do you handle bugs? Have you got any personal little quality improvement procedurettes you use? How many years were your projects meant to live?

All of this goes towards giving me an idea of how structured you are. I think this is much more important than knowing technologies. I can teach technologies, but how do you teach being structured? How do you make a kid tidy his room? And do I want to teach a 30 year old developer how to write tidy code? Probably not.

After a slightly extended hour or so, I will probably start winding down. I will progressively give you a looser and looser rein in case there is something you want to tell me – stuff you know, and which I haven’t been able to drag out of you.

Don’t lie by omission

A while ago, I was in an interview with a bloke that waited until this last moment to tell me he had already signed a contract with a different company. He couldn’t get out of this contract. I cannot for the life of me understand why he didn’t call me before the interview to tell me this. His CV was good, and he would probably have gotten an interview when his contract ran out after a couple of months. He left me doubting whether I can trust him. Don’t do that. It can’t help your chances. Be honest.

– oh, and if you are looking for a job in the Oslo area as a senior java developer, my company is hiring right now.