Objection

Architects in scrum are like mayonaise in cake

After my talk about cake mixes and how they should be avoided, several people have come to me and said that cake mixes actually turn out better cakes than the ones they make themselves, so why bother making cakes from scratch. Aiaiaiaiai, what is the world coming to? You clearly need some education, people.  Luckily for you I’m here to help.  Here is a wonderfully easy recipe from my mom’s good old “Joy of Cooking” classic. It’s called “Quick or Lightening cake” or something like that. Really really easy to make.  I usually add a teaspoon or so of cinnamon and lots of apple slices to make it more interesting, but you don’t have to. Here are the ingredients:

1/2 cup of butter (add a pinch of salt (if the butter isn’t salted)

1 cup of sugar

2 eggs

1/2 cup (+ few teaspoons) of milk

1  1/2 teaspoons baking powder

1  3/4 cup of flour

Oh, right… butter…  I live in Norway - country of butter shortages - so I have gotten out of the habit of  keeping butter in the fridge.  But it’s ok. I’m pragmatic. I’m agile. (Who isn’t now-a-days?) I’ve got other stuff in the fridge. I can just use them.  Mayonaise for example.  Norwegians have a clever trick that ensures that their mayonaise will never run out.  We hide it from all foreigners and make sure only REAL norwegians can find it.  How? We make it look like tooth paste!  Tubes FTW! Who is going to think to look for mayo in a tube? 

But I digress. 

Some people say mayonaise doesn’t work in cake.  It HAS TO BE butter or maybe margarine.  Come on people, there is no need to be that anal about it.  I’m just one of these people who don’t use butter or margarine, I don’t have any, OK?  And there is nothing wrong with my mayo. It’s very tasty. I made excellent potato salad with it just the other day.  And anyway, what do you suggest I do with my mayo? I can’t just throw it away now can I? It’ll be ok,  I’ll just put a new label on it. A butter-label.  You won’t see that it’s mayonaise at all, I promise. 

I’m kidding of course.  Using mayonaise in cake is not being pragmatic. It is being disgusting.  You can’t just pick a recipe and then make it with whatever you have lying about in the fridge.  Apple pie requires apples, Banana split does not work with cucumbers; and scrum teams, do not work with managers or architects.  

In scrum training people quickly catch on to the fact that the project manager role does not feature in scrum. The cry goes out: “But - but - but - what do we do with the project managers then???” Oh shit; I have mayonaise in the fridge, but my cake recipe does not call for mayo!  What to do?!?  Well, who cares what you do with it?  Use it in sandwiches; make egg salad, rub it on your back. Whatever. Just don’t put it in the cake.  It may be unfair to compare managers to mayonaise, after all it is easy to think of uses for mayo.  But even if you can’t think of anything useful for managers to do, you can at least keep them out of the way.  Let them have meetings with each other. Let them hold power point presentations at each-other.  They’ll be fine. 

Every scrum training session I’ve been part of, the role (or lack of one) of the manager has been raised as a topic for debate. So even though everyone still uses project managers, they at least know they aren’t meant to.  But I haven’t heard anywhere near as much talk about the architect.  Either the architects don’t realize that they aren’t wanted in scrum - or they just keep quiet and hope no one else realizes.  Either way - most “scrum” teams I know, have an architect.  People don’t seem to find this controversial at all.  I admire their capacity for doublethink.  

What is a software architect after all? It’s a guy who’s responsible for the design and architecture of the software being built.  He’s the one who makes decisions about how things should be done.  Now, what is a self-organizing team? It’s a team who figure out how things should be done BETWEEN THEMSELVES.  It means that every team mate feels empowered, capable and responsible for providing solutions and driving the project forwards.  If there is an architect on the team, the team members are no longer responsible for the design decisions.  If there is an architect on the team, the team members are less likely to raise objections to designs proposed by him. If there is an architect on the team, talented team members feel frustrated since it is harder for them to get their ideas across.  

By now you’re thinking “Oh she’s just one of these stubborn anarchists who can’t take criticism or direction” Well, you might not be totally wrong ;-) But my main problem with architects is not that I find them to be authoritarian fascists.  It’s that I actually listen to them and take their advice more readily than I should.  If the architect comes over and says “Here is how we’re going to solve this problem”, I’ll say “OK”.  Well no, to be fair, I probably would still start an argument. But I would let the architect win. Now if a random team member came up and said “Here’s how we’ll be doing this”, I wouldn’t start the argument knowing that I was going to lose. I would feel that both our points of view deserved to be heard and that we probably should ask the rest of the team what they thought.  

Not having the authority to dictate procedure, you have to get the buy in from your team before proceeding with any big ideas.  Annoying as this is, I think it is essential for the health of both the team and the product.  So often architects make decisions that their teams either disagree with, or fail to understand properly.  In both cases, poor software is the result. 

Further more, if you have a good team, it is unlikely that any one architect is going to be the best in every aspect of the software.  If there is no formal architect, you are more likely to listen to different people at different times.  If you’re discussing front-end issues, you’ll take the advice of your best UI guy. If you’re discussing database design, you’ll talk to your best database person.  If you have a formal architect - he’s the one who’ll be asked for answers in all cases.  And he’s not going to decline or delegate is he.  All good architects say that they will, but of course they don’t. As the saying goes:

“But architecture is important!”  You might say.  I’m glad you think so.  I couldn’t agree more! That is one of the reasons it is so vital to involve more people in it.  Of course we have to think about software architecture.  The more everyone thinks about architecture the better. If every team member feels responsible for the design decisions and feels part of the decision making process, they will also take more care to follow the decisions made. If they understand why the design is the way it is, they will be able to recognize when the design makes sense and when it doesn’t.  When I say we should remove the architect role - I don’t mean we kick out the architect. When scrum advocates say one should avoid specialists, they don’t mean we should kick out all people with specialized knowledge.  That would be so stupid, it should be unnecessary to point out that that is not what we mean.  The more competent the team members, the more successful the team will be.  Obviously we want to keep the best and brightest. 

“But the team isn’t capable of taking good decisions” Well then you’re screwed, aren’t you. Regardless of whether you have an architect or not.  If the team sucks, so will what they produce.  You have 2 options: fire the incompetent ones, or help them get better.  There is an immense skill gap between the best and the worst software developers.  Many programmers are stumped by the simplest of problems - even after years of experience. It’s fascinating to witness.  Their experience seemingly consists of getting others to come up with solutions and then just typing those solutions out. This is not a particularly useful skill.  I think we should teach them how to think on their own.  You don’t learn thinking for yourself by following orders.  Obviously.  Like aid workers in developing countries have found out: just dumping food on the starving doesn’t help much in the long run.  We need to give people the opportunity to improve their skills.  Always handing them finished designs takes that opportunity away from them.  We need to let them code.  Maybe not the most crucial parts of the app, but enough for them to learn and to get better.  I know it hurts to look at solutions that don’t meet your standards, but If you really can’t handle seing code you wouldn’t have written yourself, what are you doing in a team? I say we grow our team members and let everyone use their brains for what they are worth. It’ll pay in the long run.

I first heard about scrum in 2006. I’ve been eating scrum cake with mayonaise, caviar and maple syrup ever since.  6 years later the recipe still looks very tempting.  I just hope I get to try it with the right ingredients some day.

—-

(PS,  if you DO want to bake that cake, you need to:

Beat the butter and sugar, add eggs and milk, blend well, then mix in flour and baking powder (and cinnamon) - gently, just until it’s all blended.  Pour it into a greased cake pan (add lots of peeled and sliced apples :-D ) and bake in preheated oven at 190 degrees (celsius) for around 20 minutes )

Fixed to the wall

How much will it cost? How long will it take? How much money will I make on this investment?  What will the weather be like on my holiday? How long is a piece of string?  I hear you.  I want answers too.

Do you seriously expect me to invest MY MONEY in the stock market without an agreement in black and white about exactly how much I’ll make from that investment? It’s my money, man! I can’t just throw it away like that.  Do you expect me to book a holiday without knowing what the weather will be like? Come on! Whenever I go on holiday I make sure I know what the weather will be like. How, you ask? Well, I get hold of a bunch of travel agents, and I ask them to give me estimates of what the weather will be like on the holidays they provide.  I then book the holiday from the travel agent who promises the best- or most realistic weather.  It sure is worth the extra cost.  Firstly, it feels good to know for sure what the weather will be like. Secondly, if the weather doesn’t follow the plan, I get to argue and fight with the travel agent afterwards.  I blame them.  They say it’s not their fault, I say “it IS TOO!”, they say “but, be reasonable…”. It’s great fun. I can’t think of anything else I’d rather do with my time. 

I have of course never heard of travel agents who give guarantees about weather conditions, but there are people who “guarantee” returns on investments.  Con-men, they are called.  Their victims are called suckers.  

Some things are inherently risky. If you want to get involved with them, you have to accept a certain level of risk. The outcomes CAN NOT be accurately predicted.  The weather, the stock market, war and software development are just a few examples.  Sure we try our best at predicting the outcomes of all four, but only in software development do people - well, management anyway - delude themselves into thinking that the predictions can be relied upon.  Fixed price software-development contracts with consultancies are all the rage. 

Under these kinds of contracts the customer and their chosen software supplier now have one aim. And it’s not making the best product possible. Whenever an unforeseen problem arrives, they go straight to business. No, not the business of finding a solution; figuring out who’s going to pay for finding a solution.  

Customer: “This is a bug. The software should do X, not Y. You have to pay”

Supplier: “No it isn’t a bug. You never specified that it should behave that way. If you want it, we’ll need more money”

And so it goes. Instead of spending energy on figuring out how best to solve the problem, tons of time is spent figuring out who is to blame.  The relationship suffers.  Money goes down the drain.  It’s a competition where everyone ends up a loser.  For the project to be a success, both parties have to stop thinking of- and talking about changes or improvements or anything that’s not part of the contract. They must never reconsider anything, never be creative, never think forwards for the best possible solution, but to think ALWAYS backwards to the contract.

Fixed price software contracts give security and predictability the way politicians make the world a better place.  Politicians want to keep their promises just as badly as software developers would like to deliver software exactly as estimated up front.  But it hardly ever happens. The most common response to this seems to be “You just need to get better estimates, more requirements analysis etc”.  The good old “if something isn’t working - do MORE of it”-approach. I’m not convinced.  I’m more a follower of the radical “if something isn’t working, do SOMETHING ELSE” school thinking.  

As a pacifist, I hate to bring the military in as a positive example for anything. But people at least seem to have a more sensible perception of risk in military operations.  I don’t think anyone would commission a “fixed price war” from a team of Accenture mercenaries.  Everyone knows that wars are uncertain. “Planning is essential, but plans are useless” as the saying goes.  We can commit a certain amount of our budget, and a certain amount of time, but we can’t commit ourselves to an outcome. We can AIM for a certain outcome, but we should stay flexible.  When something unforeseen happens, we want to be able to act in the best possible way for the exact situation we’re in.  If our soldiers are attacked unexpectedly, we don’t want them to argue about whether or not this attack was part of the contract, and then base their decisions on what might cause their employer to lose or earn extra money.  We want the decision to be based solely on how it affects the current military goal.  A fixed price war-contract would be disastrous.  All we can and should do is pay for the time and effort put in, and do our utmost to make sure that effort is as good as can be.  

“But you want fixed price contracts for your plumber/joiner/whatever don’t you?”.  Well actually no.  After having working on these kinds of contracts myself, I will never again even contemplate fixed price for any work done on my house.  But I get your point. People seem to have good experiences with fixed price contracts for manual labour.  But that’s not the type of work software developers do. Builders can’t copy-paste a wall from one house to another.  In our virtual world, we can.  And because we can, we don’t have to do all the repetitive tasks that make a house-building-process easy to estimate.  We spend all our time on things that have not been done before. It would be like building a completely custom house where every single room is unique.  Estimation in these circumstances might be a useful planning exercise, but the estimates should not be trusted, no matter how detailed they are.  As software developers we can promise that we will work hard. That we will do our best. We can show our past results and how long they took and what they cost.  But that’s all.  Beyond that you just have to trust us.

The worst thing fixed price contracts do, is allow work to start before there is trust between the 2 parties.  Fixed price contracts say “you don’t need trust when you’ve got one of us”.  They are wrong.  You do.  Rather it’s the other way around: If you have trust, you don’t need a fixed price contract.

The token female

I’m a girl. And a programmer. A reasonably experienced one even.  There aren’t many of us.  Of the few who study computing the majority goes on to do management, or anything other than programming.  I’ve always liked this of course. I’m a bit of a male chauvinist to be honest.  Even as a child I preferred playing with boys.  In many ways I wish fewer women would study computing.

“Don’t be a victim” was one of the most emphasized values I was taught as a child.  Complaining and whining never got me anywhere.  I suppose that’s why I’ve always found much of the feminist rhetoric annoying.  From the start I never complained about it being hard to be a female developer in a male dominated field.  Mostly because I didn’t think it was.  But in any case I didn’t want people to give me a break because they felt sorry for me.  I wanted to earn their respect fair and square. Have I succeeded? Well, sort of.  But while I still hate feminist whining, I must admit that I do understand where they are coming from.  

Women programmers get treated like foreigners writing in your language.  We aren’t expected to do as well as “the natives”.  Common errors everyone makes, are seen as proof that you are inherently incompetent. Playful formulations are seen as mistakes. Any deviation from the norm is interpreted as if you have failed to understand that norm.  When I suggested to hold a talk at JavaZone about how Hibernate should be avoided, I was met with concern: 

“But Hibernate saves you from writing SQL, you see. That’s why we use it.”

Oh REALLY? Is THAT what it does? I thought it made USER INTERFACES!  
For God’s sake, I’ve got more than a decade of programming experience behind me.  I know what Hibernate does.  This kind of thing happens all the time.  People generally don’t expect me to be any good or to know what I’m talking about up front. They find out soon enough, but their initial expectations are low.

The worst example to date was back in 2004 (when I was still young *sigh*). I felt we needed to reorganize our code and database a bit, so I went to my boss to ask for permission.  (Like the submissive female that I am.)  I explained the problems we were having and outlined my new proposed solution.  But despite my best efforts - and I really did try to be convincing - he didn’t agree with me.  I had to shelf my idea. Then a few months later, my boss called me in to a meeting with another programmer. A proper one with facial hair and everything.  This other programmer had had a great idea for improving our code base and my boss wanted me to hear it.  Yes, you guessed it.  It was the exact same idea I had.  In every detail.  As you can imagine, I was ever so slightly annoyed.  

My boss was no sexist old pig. He was a great guy my age. Intelligent and funny.  But he had no recollection of me bringing up this idea.  He hadn’t been listening.  He brushed off my idea without even letting it register.  Now it may be that I’m just terrible at presenting ideas.  But it is a fact that if people expect you to be crap, they look for - and find - errors in your performance.  If they expect you to be awsome, they look for greatness.  Experiments have shown that when reports by well known scientists are submitted under a false name, they don’t get published.  When crap is submitted under a well know name, it is.  Even worse, experiments show that if people think they are disadvantaged in anyway, they perform worse than if they think they have an advantage. 

I hate to admit this, but I rarely look at somebody else’s code without thinking “Why, (dear God WHYYY!!!) have they done it THIS way, when it would be SOOO much better to do it THAT way?” If I think the guy who wrote it knows what he is doing, I’ll assume he must have had some good reason for writing it that way, and I’ll ask him about it. But if I don’t think he knows what he’s doing, I - hate to admit it - but I get kind of annoyed. And I’ll probably trust that person less in future.  Having low expectations of someone makes it THAT much harder for them to gain the respect of their peers.  Just like the foreigner trying to learn a new language - their grammar has to be PERFECT before anyone trusts them to write anything for them. 

I have of course always felt welcome as a female programmer. In my experience people really do want more women in computing.  In every hiring situation I have felt that being a woman has been an advantage.  Few programmers are consciously sexist.  But if they see a woman arriving in the team, they don’t expect her to be particularly good.  Would you?  I know I wouldn’t.  

The problem of course is that so many boys have programming as a hobby while still in school.  By the time they start studying computing they already have years of experience behind them.  Extremely few girls do this.  I didn’t.  I never did any programming until I started university.  The skill-gap between first year students in computing is immense.  And while there are also boys with no experience, they are less conspicuous. The girls have BEGINNER stamped on their foreheads in bright pink.  And it’s an accurate stamp too.  We are clueless.  From the very start therefore every computing student knows not to ask a girl for advice.  Everyone knows that the boys are better.  Not every boy is a good programmer, but all the good programmers are boys.  By the time the girls catch up, the damage is done. No one notices.  We’ve already been branded.

Would you send your daughter off to study music if she had never touched a musical instrument?  Of course not.  Even if you would, she wouldn’t be let in.  There are entrance exams to pass.  Juilliard school of music doesn’t mix beginners with experienced students.  The reasons are obvious.  They should be equally obvious for us.  Like music and sports, programming is a specific skill a significant amount of people learn and have as a hobby.  In geology, medicine or anthropology the initial skill-gap among students is negligible compared to computing.  I think it would help immensely if students were placed in classes with people at roughly the same level.  There are plenty of guys who start studying computing with just as little experience as the girls.  In this kind of setting, it would be easier to discover that women’s’ coding abilities are in no way inherently inferior.

Most importantly though we need to get girls into computing WAY BEFORE university.  Why not teach programming in school?  I think kids would enjoy it. Girls as well as boys. Maybe even more so! Who knows? 

In the meantime, I encourage all female programmers who really enjoy coding to keep being awesome! Don’t give up! Take part in as many projects, conferences and other gatherings of programmers as you can. Let more people experience that boobs and coding ability are not mutually exclusive.  And guys, take a moment to think about it: A women arrives in your team, what would you expect of her? Your expectation matters.

Size Matters

How big should a method be? How many lines should there be per class? Everyone has an opinion on this.  But how about project size? What is the maximum amount of KLOCs or classes a project should contain?  Why haven’t I heard anyone talk about this? Everyone knows that large projects are harder to work on than smaller ones.  And I’m not just talking about spaghetti-code.  Even well designed projects are hell once they reach a certain size.  

Anthropologist Robin Dunbar found that people can only maintain stable social relationships with 150 people.  If your organization contains less, you’re able to keep track of who is who, what they do and how they might help you out. Under 150 you walk down the hall to ask Tim a question.  More than 150 and you email support@mycompany.com and hope for an answer by the end of the day.  You start relying on abstractions. Abstractions slow you down.  Abstractions keep you from solving problems in the most appropriate way.

It’s the same with software projects. The larger the project, the more abstractions. The more interfaces, the more layers, the longer the distance between the problem and its solution. The harder it is to just solve your problem in the most efficient way possible. 

Does anyone out there have an opinion on how large projects should grow? When should we start splitting them up? I don’t think there is a one size fits all answer here. But I think we should have as clear an idea of our preferences about this as about how large our classes, and methods are.  

What do you think?