Here are excerpts of a document entitled “A little guide to a little etiquette” that provides guidelines on what to avoid doing in a work environment designed to be collaborative.

“Walk, don’t yell”, “Use your inside voice”. Basically the designers understood that open floors have no barriers against sound. They also recognise that the natural behaviour when you see someone that you need help from is to ask them directly from the distance, shouting to get their attention. And they found a solution: change your natural behaviour (and do some exercise at the same time !).

Regarding personal items, “One rule of thumb is that if you can see it from a public space or across the room (…) it needs to go”. Interesting as from my perspective anything that is on a desk can be seen from a public space on an open floor. Note that there is nothing here to suggest that this treatment is reserved to offensive material. Well, okay Dilbert may be offensive to some. Also there is a ban on plants and tape to make sure that in reality you cannot display anything personal in this neatly designed, beautiful place.

Other gems include:
“A reminder that all holiday lights should be viewed at (edited name of a city spot), not your desk. Also please remove any holiday items by January 2.”
“Walk Around. Please use the main walkways and go around the perimeter of workstations instead of cutting through work areas.”
“Please avoid ground-hogging - peeking over the workstations walls in order to talk to co-workers.”

Aside from the fact that it is the first time I get to read a written form of the furniture police manual what strikes me, and I guess it is good news for us software professionals, is that even for interior designs we have decided to replace hardware (walls and doors) by software (behaviour). It is really unfortunate that the designer failed to understand that one of the prime examples for open floors, trading floors, are places made specifically to enable people to yell and sign at each other from across the floor.

Let me re-read Peopleware.

César touched on hiring and promoting a while back. This came in conjunction with a number of other things that I have heard or lived in the recent past. It is all about the “right” person.

What is the “right” person ? Is she the person that satisfies all your criteria ? Will your criteria become obsolete as the environment evolves ? Or even worse you will discover that you had the wrong criteria ? What if the job you envisioned for the person has changed before they could actually start ? And if the “right” person does not want to work with you, will you settle for a “wrong” one ?

Hiring is all about compromise. The firm needs to make a compromise between diversity of opinions and common values. It needs both to be innovative. Compromise because a job always needs a mix of qualities a fine balance between expertise, character and ethics. There is also an important compromise between immediate results and long term contributions by the new hire. For instance, do you prefer to hire a cheap graduate that you will have to train but you will also get to grow or a seasoned veteran that has done the same thing ten times and will do it again for you ?

Earlier in my career I tended to interview people as a reflection of myself rather than as separate contributors. It turns out no one like me wanted to work with me. As I have aged I now realise that a job definition will always be stereotypical. The person hired to fill it will largely influence its actual shape. And the social group (team, department, company) is the result of the co-evolution of all the persons that compose it. Therefore the “right” person would be right in the situation as it was before you hired her. There is no telling what the situation will be after.

So as a conclusion, if you are deterministic, the person you hire is necessary the right person. For the rest of us there is no such thing as the “right: person. In other words nobody is perfect and right implies a contextual perfection that does not exist. More importantly, looking for the “right” person clouds your judgement as a recruiter. You have to be agile as a recruiter as well.

I recently got to feel the weight of social conditioning in the enterprise. I was asked to temporary (three weeks to be precise) fill in in a somewhat managerial position. I started with the idea that I have great confidence in my team mates and that therefore I would not need to do much in this interim period aside from fielding a few e-mails and showing up in a few meetings (I was even spared the administrative burden !).

I soon discovered however that I was trapped in the conventional thinking that is continuously hammered into us that people will not do what they should and that, as a result, if you are delegating the work, you should also verify it very thoroughly. Even knowing it is not good (see Peopleware for convincing arguments) I still felt compelled to do it. Worse, I had to refrain myself from over doing it and try to be more supportive than prescriptive !

The awful thing is that it is an attitude I don’t like as a subordinate, it is something that does not happen when the relationship is truly a peer to peer one. I came to realise the reason I was trapped in this attitude is that I felt singled out as the individual responsible for the outcome. It did not feel like a team responsibility but my responsibility.

That is what I would call the management trap. The illusion that things are at stake for you personally rather than the group. It is the social trap that we use everyday to ensure a control structure rather than a collaborative one.

Let me put first questions that aim at determining that you have a Computer Science background. It may also be that in some environments they are formally use and also test required skills. I am referring to questions about algorithm complexity and cost or about describing some specific algorithm (well known to new graduates) such as sort or data structure exploration. I like them because it is something I don’t get to reflect upon frequently. In practice, in the jobs I worked on they are seldom used formally.

Then there are the problem solving questions. Some of them are extracted from the vaunted google and microsoft interviews. You can find a few tihomir’s blog. From the ones listed only a handful are actually useful. Many are simply trick questions (like the angle between your watch’s hands at 3:15). Some have this particular quality that they test the creativity and the reasoning of the interviewee. This kind of question is all about the path your reason takes to solve the riddle.

I found two main categories. One is composed of the questions for which it is clear that the interviewer does not expect a precise answer. My personal favourite (which I was asked by Amazon) is “How many piano tuners are there in Seattle ?”. The other is composed of questions for which a definite answer exists but requires a creative jump to find. I found a few interesting ones in books (including the The Olduvai Imperative, a book I highly recommend even if it dates back to 1993). The main difference between the two is that the first one is resistant to publication. Whereas once the answer is published for the second category it becomes useless.

Their strong point is that they enable to evaluate a candidate’s problem solving abilities and the capacity to articulate the solution (as the authors of the Olduvai Imperative point out this is one of the primary activities of software developers). Specifically they require you to use creativity to solve the problem and they require you to organise the result as an articulated solution.

These are the questions we need more of in order to do a serious evaluation of software development candidates. Candidates who give appropriate answers to this kind of questions will be able to adapt to changes in technology and they will foster creativity and innovation in the software you are developing. Well I guess that some recruiters are not looking for that but that certainly is the part that I prefer in my job.

I have interviewed a number of candidates in the past, mostly on their technical skills. I also have been interviewed a few times over the years. There is one thing that I really dislike about technical interviews, it is the technical questions.

Now not so much the technical questions but the ones that ask about things like the “final” or “synchronized” keywords in java or the types of joins in SQL. I could concede that a few are fair game. They are sometimes used by managers to filter candidates. However in that case I would suggest something shallow and short that enables you to terminate the interview quickly and save time. Otherwise you risk two things. One the candidate may have a deeper understanding of the problem than the interviewer (and possibly than the person who wrote the question, especially for standardised questionnaires in large organisations) and therefore give an answer the interviewer misjudges as wrong. The other is that people who have no practical experience in the matter but only read a few books (say to get a Java certification) can answer these flawlessly.

So aside from my personal preference when I am interviewed, it seems to me these questions are typically of little value to evaluate the candidate’s possible contribution to a team or company. My personal approach is on the completely opposite side. I try to have the candidate talk about his experiences in some technical details. This provides more details about the actual work than what typically appears on the resume (and discovered in many cases that it was a lot less interesting than presented). It also gives me an idea on what the person actually did in the project described in the resume. I was never disappointed with this approach. And I don’t think it takes significantly more time to filter out bad candidates.

Now there is a third, rather interesting approach. I had the privilege to be interviewed for a job opening a few weeks ago. I was actually interviewed three times by three different persons. Two of them were asking questions in the bookish style (by the way there is always the pitfall in that type of questioning that you actually have the wrong answers). The third one (well actually the second one in order of appearance) started with the bookish questions but used them to trigger deeper conversations on the subject. I found this way of driving the interview extremely interesting. First from a candidate’s point of view you suddenly feel as if you were comparing notes with a peer rather than being formally interviewed. Which means that both the interviewer and the candidate quickly get a feel of how things would go if they were team-mates. It goes beyond the mere questioning to establish a rapport which in turn gives more useful information for both sides.

Unfortunately, my other interviewers at that company must have felt differently because I got asked twice the same questions plus a few that were inspired (or directly lifted ?) from logical quizzes and internet riddles (like the three blue hat). Also, by contrast, at no point during these other interviews did I feel like I truly wanted to work at that company…

I recently was given the following problem during an interview.

3 persons are in a dark room along with three blue hats and two red hats. Each person picks a hat randomly without knowing its colour. When the light comes, the first person expresses she cannot tell what colour her hat is. Same for the second one. The third one is blind and exclaims she knows which colour her hat is.

Let’s call the characters A, B and C in order of appearance and let’s express the solution space as binary numbers where 0 is blue, 1 is red. Solutions are expressed in terms of binary numbers representing CBA sates.

space = {000,001,010,011,100,101,110}

111 is not possible as there are only two red hats.

The uncertainty of A translates in {x,y in space such that x xor y = 001}
The uncertainty of B translates in {x,y in space such that x xor y = 010}

The solution is therefore the intersection of {x,y in space such that x xor y = 001} and {x,y such that x xor y = 010} which is {x,y such that x xor y = 011} or {001,010}

Therefore the third character wears a blue hat. The same result can be achieved using if then and else. However this way of expressing the solution shows more. For one it shows that the solution is symmetric around the third person as the narration indicated. It also makes it clear that what makes the solution possible is the di-symmetry in the number of hats. Which means that, it is as logical to solve the problem from the narrative as to go through the resolution steps. A quick text analysis shows the characters symmetry and the hats di-symmetry and leads to the conclusion.

You can also memorise the solution, or the steps, but it is not as fun.

It is really unfortunate I did not have the wit to come up with all that until I reflected a bit on the story. I am sure I would have made a better impression otherwise. Oh well…

The financial world is abuzz with what happened at Société Générale. Many among the professionals are surprised by the size of the loss but not at all by its possibility. Why ?

In the past 10 years the systems security has greatly improved: requirements on password composition, frequent renewal of passwords have done a great deal for that. A bit deeper a lot of things are logged, traced, recorded: phone conversations, e-mails, application use. Even deeper, applications support things like two person checks, roles, permissions to ensure that users are allowed to do only what they are supposed to and get appropriate approvals for this. I would not dare to contend that these protections and safeguards are completely foolproof but for most of the applications I know, hacking them is beyond the reach of a master in finance.

So what gives ? I will give a few examples.

If in a back-office the official procedure is to use cross checks to avoid errors (pairing in agile terms), what really happens most of the time is that operators will exchange their passwords to enable them to do the cross check alone. Why would someone do that ? Because otherwise everybody would have to be here all the time, for very long days, taking no vacations, not being sick.

In a front-office, as noted by some commenters, passwords are on yellow sticky notes inside drawers or underneath keyboards. Why would someone do that when they signed a paper saying they should not ? Because in many applications, other traders cannot act on each other’s trades. Or the procedure to be able to do so is too complex. Or one of them started a trade and it finalizes while he is out getting a cup of coffee. His colleagues naturally cover for him and breach those security checks to accommodate team work.

I will not pile on with users that have permissions they should not, permissions that are not timely maintained when a user changes role, the heavy use of excel for critical things, failures in systems and missing checks.

To simplify, back-offices are the production line and front-offices the sales/engineering force. I have not yet spoken of the risk control part because I have little experience in this area. Believe it or not, risk control has considerably matured and is now very important in many firms. It always hold veto power over the front-office. Unfortunately, without the back-office risk control is half blind (as the SocGen example shows). The sub prime crisis on the other shows that risk models have a hard time keeping-up with financial innovation.

So what is the point in this ?

A lot of ink was devoted to the idea that information systems were tricked to produce unreasonable exposure. The reality is that it is the actual (as opposed to written) processes of the bank that were taken advantage of. The point is that when people cannot work under the rules and procedures they bend them or they give up. Either way problems of this nature will happen. Empowering workers to make appropriate changes to the way they work increases productivity and quality (such as better operations reports in this case). This is the realization at the core of Kaisen in the Toyota production system, this is also the core of Agile methodologies.

After Cesar’s comments on You shall not compromise quality! and the obvious confusion between quality and qualities, I created the following simple analogy. I believe it conveys the point efficiently.

If your house is flooded, two plastic bags and some tape will be enough to keep your feet dry. The quality requirement (qualities) is that they do not have holes. The quality of the bag is measured by the number and position of the holes. If you are lucky they are all high on the bag and your feet may stay dry.

If you go fishing in a swamp, you should use specially designed boots. The quality requirements (qualities) are that they have no holes, are able to resist various environmental aggressions and that they are comfortable. The quality of the boots will be a combination of the comfort, sturdiness and water tightness.

Compromising quality is that you don’t apply the best practices, use the wrong tools (ever tried to knit boots or plastic bags ?), promising more than can be achieved (like trying to make a plastic bag with half the necessary plastic or making boots when the soles are above budget).

Final point, good boots are not cheap. Plastic bags are relatively cheap and can be used for lots of things but they easily break and end up polluting the landscape (who just thought Excel out loud ?!?).

Last week-end Agile in Action asked whether we (as professionals) should you always do what customer wants (and don’t skip the comments at least one of those is great, will give you pre canned arguments in such a discussion and its not mine) ? It concluded that if a customer wants to compromise quality the author would walk away. I would agree with him, when it is possible because it is very much the sign of a barbarian culture on the clients part.

The way I understand it,  quality is a measure of how well the software product finally delivered implements the desired properties (or qualities) and in particular the desired functionalities. In that context, compromising quality means that you are prepared to deliver a product that may not be fit for its intended purpose. Which generally really means they you want to go to the market as fast as possible, let the customer test (discovering in the process what they really use and how) and then fix the problems as fast as possible. In short a barbarian approach. I believe that stating it this way is actually acceptable because it means the client understands the implications of the choice to be as fast as possible (and it may even be ok to execute on this in very specific circumstances).

Obviously, this is exactly the kind of situations that Agile methodologies address best. They enable to discover the functionalities the client really cares about as well as how they should work. They enable to make the other -ilities emerge though refactoring when they become desirable attributes of the product. They enable to bring features to market as soon as they work (as opposed to before they are tested). They are more satisfying for both the client and the implementor.

In conclusion, rather than compromising quality for the things you need, drop the things you don’t. Unless your client wants to consciously sabotage the product and specify the bugs, truly making them features.

I referred some time ago to an article by Robert L Glass published in IEEE’s Software magazine entitled "Greece vs. Rome Two Very Different Software Cultures". You can purchase this article but I find it a bit expensive for a two pages column. It is based on The Olduvai Imperative by Peter DeGrace and Leslie Hulet Stahl. Unfortunately this book seems out of print (although it can be found from specialty book shops online).

The author of the article describes three work cultures. The greek one where workers are "(…) individuals or self motivated members of teams" that were behaving like contractors and the roman one where the worker is "(…) sacrificing himself for the good of the organization, giving up his individuality, and closely identifying with his group." are taken from the book. He adds a third one, the barbarian.

He goes on to describe the compared values of each culture (I would have to reprint the whole article to give them here and I don’t want to infringe on the IEEE and Robert L Glass copyrights). Let me go straight to the conclusion as it applies to Agility: "Greeks would fit pretty well in the Agile Camp, Romans would be working mightily to improve their CMM level, and barbarians would say "huh?" if you mentioned either one.".

The article finishes with an excellent tale (taken from the book) telling what many of us have witnessed for a long time. The roman produces a great deal of external activity and produces a lot of artifacts showing more productivity. He beats the greek who took time to think of a simple solution that did not display enough effort. But Robert L Glass adds that in reality the barbarian wins by coding like crazy, introducing tons of bugs and then saving the day by fixing them. The barbarian, in our current software culture will be celebrated as a hero.

I know it is a very sad story. I blame Microsoft Windows a lot for that, having ingrained in the popular culture that bugs and crashes happen and are a normal part of software. But that is only my personal nag.