Objection

The real reason we need more women in software

I just thought of something, very profound as usual.  Women are more complicated than men, right? We say yes, when we mean no and vice versa. We expect people to read our minds, instead of just telling them what we mean.  We’re better at multitasking, we’re more flexible, but also a bit more fragile. Am I right guys? Still, for whatever reason, you seem to be attracted to women.  This complexity must draw you in and fascinate you somehow.   

Women on the other hand tend to prefer men.  Screw the soft and the flexible, we prefer straight forward, stable and strong.  So here’s my thought: Does this apply to code as well?  Do guys prefer complexity in code to a larger extent than women?  Think about it, if a guy sees a hard coded value he shudders and instantly hides the value under at least 5 layers of abstraction.  When a woman sees one, she’s like: “Oh, great I can see what’s going on here” I was tempted to make a joke about how I like my code like I like my men… but somebody might get fired.  

I have absolutely no data to back up this theory, but I think there is something to it.  In my experience, women are more interested in the end product than their male counterparts.  As soon as men start coding, they often seem to forget that they are actually meant to make a product.  They get totally distracted by the code itself.  Instead of writing a solution for the problem at hand, they try to solve the problem of how to solve any problem. This is far more complex.  When women fail to see the beauty of this complexity we’re made to feel stupid.  We aren’t.  We just like it simple, reliable and to the point.  

People are always telling me that I exaggerate and generalize.  As if I don’t know this.  Of course I’m generalizing and exaggerating.  I used to be American for crying out loud!  So just for the record, I don’t hard code every value, quite few in fact.  And I know plenty of guys with a great ability to think practically about the problem at hand.  But I still think we could use an increase in software developers who care about the products we’re creating over the code itself.  I think women, on average, can deliver that.  

Dangerous jokes

At my first full time job I was asked to come along to meet a customer. He wanted us to spend a week developing a prototype, then if he liked it, he would possibly pay to have us develop a proper application.  I did my best and after the week was up he apparently told my boss that he was giving us the contract on condition that I would be the one working on it.  

I remember my boss and the sales manager coming in to tell me the good news: “Well done Christin! We won’t ask what you did, but well done!” *nudge, nudge, wink, wink*  ”Hahahahahaaa!”  We all laughed and went out and had a nice lunch together.  They were such great guys to work with. Always joking about everything. Nothing was sacred.  The office was always filled with laughter.  I loved it.  Why wouldn’t I?  Should I have been offended by their insinuations?  Why? They knew I was good at my job, they didn’t actually think I had slept with the guy to get the contract. THEY WERE JOKING.  And shocking as it may seem, females can actually enjoy jokes too. I’m one, and I know of several others.  

Later I got a job doing R&D for a large international oil company.  As you all know women are few and far between in the IT-industry, the more technical it is, the fewer women there are. There were very few women doing anything technical at the office. And which project do you think they put me on? Programming the central control system for land based seismic source VIBRATORS.  I thought that was hilarious! I was just dying to make jokes: “Well I hope you approve of test driven development! :-D”  But NOBODY joked about it.  Not a single word.  Now THAT made ME really uncomfortable.  I was confused - “Are they joking behind my back?” “Don’t they have any sense of humour at all?” “Can I joke about anything at all in this place?” I just can’t work in a place like that.  Where I can’t be myself.  Where people are afraid of making jokes.  I mean that quite seriously. If somebody had joked about the vibrators, if the culture allowed that kind of banter, I might not have resigned.  (The lack of jokes was of course not my main reason for resigning, but more fun  around the office might have made those reasons seem less pressing)

The worst part is, I don’t even get it - why on earth should women take offense at sexual jokes? Women like sex too (If you don’t, you’re doing it wrong) Romance novels sell like hotcakes.  I often wonder what would happen if guys at a Rihanna concert started behaving like girls do at Justin Bieber-concerts.  Women go completely nuts about good looking guys.  Why on EARTH should we be so up tight about men even mentioning anything sexual? Jokes about women being stupid - now there offense makes sense.  Sexual harassement, guys actually expecting sexual favors, there complete outrage makes sense.  But that’s not the issue here.  Let’s not confuse sex (and jokes about sex) with sexism.  I know they sound the same, but there is a big difference.  

It makes me so sad and angry to see that some women are trying to turn the whole IT industry into the kind of work place that I felt I had to get away from.  Well you don’t represent me, girls.  So there.  Maybe mine is a minority opinion, as usual. But there it is. For what it’s worth.  

The truck factor

I like writing. It helps me think, helps clarify my thoughts. I even think writing about coding has made me a better programmer. It has certainly made me think in a more structured way about my coding style.  I just wish I took the time to write more often. I think you should too.  And when you do, make sure not to do so alone.  You should never write anything all by yourself. You’re not good enough. No one is.  A team of about 7 people simultaneously co-writing should be about right.  Give or take a few.  ”7 people? That many?” I hear you ask. Don’t worry, it’s the only responsible way to write and it’s totally worth it.  You’ll see.  First you divide your main idea into a few main topics you want to cover. You then split up in pairs and start writing, making sure to switch partner and topic at regular intervals. That way everyone gets familiar with the entire document, and everyone gets to put their own little personal touches on the final text. The results are very charming. Another benefit is that if you get hit by a truck, nobody gives a shit, because you are totally replaceable. Yay! Everyone in the team also gets the opportunity to voice their opinions and have meetings upon meetings to discuss all the possible ways the document could be structured. The more meetings that are held, the better the document becomes. Obviously. Some people get motivated by  progress, and the feeling of getting things done. Not me. I mean how can you enjoy completing something without having discussed and documented it’s every single aspect and every possible way it could have been different, but isn’t and why those differences matter or don’t matter to whom and when they matter more and less etc. I get goose bumps just thinking about those meetings. So thrilling.  And even if you don’t like to spend all your day in meetings, you shouldn’t just think of yourself. You have to think about those who might have to maintain your solution in future. I mean imagine the disappointment of a newcomer to the writing-team on learning he would NOT get access to a wiki describing in detail how the document isn’t written and why it’s not written that way. He’d be devastated. We must think of him.

Now I know that not many authors work like this, but I can’t figure out why.   

After years of nothing but team work (that I’ve enjoyed by the way, and learned a lot from, despite my sarcasm above) I’ve just had the opportunity to work pretty much by myself on a new project and it was so much fun! I could just do stuff! I could make decisions and get things done.  At work!  It was amazing!  I had forgotten just how much faster I can do stuff when I’m alone compared to in a team setting.  

“But faster isn’t better”, you might say. Nonsense. Of course faster is better.  Either, you finish early, it all works and everyone is happy. Otherwise you realize it doesn’t work, but you still have time to fix it.  Your next solution will then be based on real experience of the problem, rather than the plans made before you had even started working on the issue.  I swear I could implement stuff at least 3 times over in the time it would take a team (with me in it) to do the same. I don’t mean to say that “I’m awesome”, but teamwork takes so long! You can’t just go ahead and do stuff, you need to agree about what to do first.  If you don’t, everyone will implement things differently and the code turns into a mess.

Some say all this planning and discussion leads to better decisions being made. I’m sure it does.  Maybe the chances of getting it right increase by 10% or so.  But with all the extra time it takes, you had better get it right, because there won’t be any time to do it differently should the chosen solution not work.  By cutting out the team bureaucracy you’re indeed exposing yourself to a bigger risk of failure, but you’re also decreasing the impact of it.  With all the time saved, you’re able to learn from your mistakes and actually have time to redo stuff.  Having 200% more fun all the while.

I’m not saying we should all sit in our corners and avoid each other all day. The best part of my recent experience was that I was still sitting with my colleagues, able to discuss issues, show them what I was working on, etc.  I would never argue that we should stop collaborating. I’m a big fan of pair programming even. But not everywhere and all the time. Is it so wrong to enjoy a bit of autonomy and private focus? Am I a bad person for wanting to work more like authors do -  with personal ownership of my work, but lots of peer reviews to ensure quality and knowledge transfer? Agile theory suggests I am. I suppose I’ll end in agile hell. Will you join me there?

What women want

So much effort is spent on getting more women into computing. It’s touching.  I thought I’d join the effort. So here goes:

“Our conferences are full of MEN! Yuck! They even dare to like pretty women! It’s disgusting, they are all pigs. Women are only seen as sexual objects.  Let’s boycott all those nasty men.  No wonder so few women join the industry.  It’s terrible! We’re not respected at ALL. The whole industry needs to change. NOW”

There, that should attract a whole bunch of new female programmers, don’t you think?

Ok, ok, I’m guilty of complaining too of course. Here is something I have already written about problems I’ve faced as a female programmer.  Sure, being a female programmer sucks some times.  Just like everything else sucks some times.  Who on earth doesn’t have some personal quirk that sucks some times? 

Personally, I’m not too concerned about attracting more females to the industry. I’m happy with how things are.  And ironically, I think that attitude might just attract more women into the industry than all the talk of how we need to change in order to be more attractive to women.

I’m not saying we should stop trying to improve things. I’m just saying that complaining about the status quo is not likely to attract more women to the IT sector. It’s by focusing on the obstacles that you hit them. 

What do women want after all? They want an interesting, fun and rewarding job.  So, let’s show them how much fun we have. Let’s show them how interesting it is.  Make fun of the occasional (mostly unintended) male chauvinism.  Every job sector has its’ share of assholes, and there is no need to go ballistic over people occasionally putting their foot in their mouths.

So for what it’s worth; I love my job! And I love my colleagues, I love the community and I love the conferences.  Don’t listen to all the negativity guys.  Men in IT are the most wonderful people on the planet.  Don’t let anyone tell you otherwise. 

Reuse? Refuse!

Hi guys, I have an amazing idea!  In software we’re always talking about reuse.  Why spend time and money making loads of new stuff, if we can reuse what we already have?  And then it struck me, why don’t we start applying this at home?  Looking around me here in the living room, it is frightfully cluttered.  There are chairs and sofas and tables all over.  Same situation in the kitchen. Lots of chairs and a table there too.  The house is full of chairs, although any one person is only able to sit on one chair at a time.  What if we reused our chairs.  Strictly speaking we only need one chair per person.  Think of all the space we’d save! Think of all the cost saved if people only needed one chair per person.  We’d have to move it around alot, but that’s ok, we could just put wheels on it and an engine and drive it around the house with a joy stick! It would be fun!  But why stop there, look at beds.  By lifting the head-end, and lowering the foot-end of a bed, voilà it can turn into a comfy chair.  Add the wheels and engine, and you could have a bed and universal chair all in one!  But wait, there is more!  With some clever plumbing underneath, a secret hole in the mattress, we could even turn it into your own personal toilet! No more pausing the film to go to the bathroom! Your toilet would always be with you.  How awesome would that be!  Patent office here I come!

I could go on, but hopefully you get the point.  The chair you eat your food in, the chair you watch TV in, and the chair you take a dump in SHOULD BE SEPARATE AND DIFFERENT.  Yes, they are all chair-like. Yes you sit in them all, but they serve different functions.

This is so obvious when it comes to physical items. Anyone can see that the bed-chair-toilet will actually be far more complex and therefore less reliable, and harder to maintain than a simple bed, a simple chair and a simple toilet.  Not to mention the fact that you really don’t want to be lugging your toilet with you everywhere you go.  It’s disgusting.  And whenever it breaks down, you’ve lost both your toilet, your chair and your bed!  Bad idea. But as soon as we’re talking software, people firmly believe that reuse leads to less maintenance.  We HAVE to reuse the same domain model.  No we don’t.  We HAVE to have the same UI-components. No we don’t.  

It’s so easy to get started down this road.  At first the common domain model/custom UI-framework/whatever is used in its entirety by every part of the system.  Then as time goes by and the product develops, the various parts need their own little extensions.  An extra property here, a new method there, interfaces and complex class hiearchies form as each part of the program needs things to work in a slightly different way, but at the same time has to make sure the change doesn’t affect anyone else.  As the “reusable common project” grows and grows, the proportion of it used by any sub-system diminishes.  Only a small fraction of the classes are of any use to any one sub-system, and in those that are used, more than half the properties are never touched.  At the end of the day, very little is actually reused. Just like the bed-chair-toilet.  When you’re eating dinner, you won’t be needing the toilet-plumbing underneath (hopefully).  

Are you dreaming of building a system with loads of reuseable parts? Snap out of it! Have you got one of these systems? I suggest you start dismantling it.  No need to go at it with a chain saw, just little bits at a time.  But be sure that next time someone asks you to adapt it some way - “I need a bidet embedded in it as well”. Take that as an opportunity to take the damn plumbing out and put it in the bathroom where it belongs.

Losing loose coupling

When I’ve been asked to sit in on job interviews, I generally ask one question of the candidate: What is good code?  Worryingly, a very common answer from people fresh out of university is “Plenty of good comments”.  Now that’s the wrong answer guys.  Who teaches them this stuff?  Scary.  But I digress… I don’t believe there is a correct answer to my question, however I would accept something along the lines of “high cohesion and loose coupling”.  At least that says something about the code.  But if it were a java developer I were interviewing, I would definitely not let the poor soul get away without a few follow up questions.  Because java developers have gone completely nuts.  We are obsessed with meticulously chopping code into tinsy winsy little pieces.  We chop and chop until there is hardly anything left.  Once the little darlings are separated we start worrying about them touching each other.  Oh the germs!  We need to protect them from each-other at all cost.  Every little spec of code gets its own interface so it doesn’t have to get its hands dirty by touching the other pieces directly.   Then we connect them all up via magical frameworks that use convenient abstract singleton proxy creating factories and the like.  

Imagine a bicycle made by the same principles.  The frame chopped up into 1 centimeter long pieces and connected vertebrae style.  Would it be more flexible? Absolutely. Would it be practical? Absolutely not. It would cost more to manufacture, by a factor of hundreds.  It would be more likely to break, also by a factor of hundreds.  It would cause more accidents, and last but not least, it would look ridiculous and be difficult to ride.  Our back is meant to flex, therefore vertebrae make sense. Bikes are not.  

We don’t make the bike out of one piece of metal or carbon fibre.  We can swap out the wheels, we can change the handlebars, but we don’t go nuts about it.  Some pieces are small, some ar large. It’s all good.

Another thing we do when designing bikes, is design bikes.  Not generic “transportation devices”.  We don’t give a shit if our customers might some day want to cross the Atlantic.  If they do, they won’t be doing so on our bicycle.  If our customers want to fly up to the top of a sky-scraper, they won’t get much help from us.  We’re fine with that.  We want to make the most awesome BICYCLE ever. A bicycle that can be reconfigured to suit any possible transportation need, and still work well, might be an option for Bruce Wayne, but unfortunately most of us don’t have those kinds of budgets.  If we want our systems to truly rock, and be fit for purpose, we need to know what we’re building.  Flexibility and configurability are for people who don’t know what they want, or when you need 3rd parties to contribute certain parts of the system.  Bike frame manufacturers will make sure they don’t limit their bikes to only one type of seat, one type of handlebar or one type of wheel.  In computing terms they connect to a HandleBar interface that can be implemented by any number of actual suppliers’ handlebar models.  But the frame itself - their own product isn’t chopped up into tiny interchangeable fragments. If they need different types of frames, guess what, they have separate models.  Models that share many of the same traits, but are completely separate all the same.

In software we obsess about being able to interchange any part of our system with any other implementation.  If we change one thing and it stops something else from working, we see that as bad design.  Now what would happen if we put monster truck wheels on our bike? The bike wouldn’t work very well, would it? But does that mean the bike is badly designed? In the physical world we’re fine with things being connected. Hard coded if you will.  We prefer it even.  It makes it easy for us to see when things fit and when they don’t.  Bicycles need wheels that fit the frame.  We can’t just use a Wheel interface, we have to be pretty specific.  A bike structure that could handle any type of wheel would be pretty complex.  Not worth it.

If we want a bike that can use monster truck wheels, we’ll have to change our design, and make something that will fit.  And you know what - we can do the same thing in software.  I’ve come across this amazing technique, I don’t know if it works in IntelliJ, I’m an Eclipse user myself, but in Eclipse at least you can go to the section of code that needs changing. Hold down the SHIFT key, click the arrow buttons until you’ve highlighted the part of code that needs changing, and then you let go of SHIFT and press DELETE.  And it disappears! And then you can write something else. It really works! I’ve tried it.  In java code too, not just xml or properties files!  It’s amazing. 

Ever notice how large enterprise software projects tend to cost fortunes and take forever to develop and then fail spectacularly at delivering any value?  There are many reasons for this.  But I’m convinced one of them is this insistance on flexibility.  Flexibility by meat cleaver and vacuum bags. Individually packaged mini morsels of generic code. Instead of just making (possibly several) systems that work really well for specific known cases, we insist on making THE ONE (super configurable) SYSTEM TO RULE THEM ALL. A program that should work for everybody everywhere no matter what their needs may be.  

So what if we need to change the database one day? So what if we need to get this data from somewhere else at some point? So what if the format of this message changes?  We can change it.  Isn’t that why we release our systems frequently in the first place?  So that we can change them? If our systems are well tested and well designed, change isn’t a problem.

I’m all for loose coupling, but do yourself a favor and make sure your solution is coupled with your problem.

Impolite? Me? :-D

I feel honored that Uncle Bob has responded to my JavaZone presentation where I critisized his “extract ‘til you drop” way of coding. Here is his response:

https://gist.github.com/3753571

My first reaction is this: Don’t people read entire newspaper articles anymore?  That explains a few things.  I think the world would be a better place if people did.  I sure do myself. The historical reason newspaper articles are ordered the way they are, with the most important things in the first paragraph, is so the editor - having limited space available - can chop bits off the end of the article without it ruining it.  Besides, newspaper articles are not structured like 5-line-method code.  Sure it has the most important stuff at the top, but you read it from top to bottom. Every sentence does not send you off somewhere else down the page, forcing you to jump from paragraph to paragraph.  

I agree that you should not have to dig down into the details of a 3rd party library. But your own code, code that you are responsible for maintaining, SHOULD be read thoroughly and understood.  If my colleagues are incapable of reading more than 5 lines of code at a time without clicking a “test” button or getting themselves a cup of coffee, then I think we have a problem.  Maybe some Ritalin would help?

I have been writing code à la uncle Bob for years.  I did so because I was fully convinced by him that it was the most proffessional way of coding.  But I now realize that I went too far.  Max 5 lines causes far too much fragmentation. The big picture is lost.  Others coming in to edit “your code” don’t see the full picture and therefore mess it up very easily.  You do the same to “their code”.  And I find that coming into an unknown code base where no method exceeds 5 lines is REALLY FRUSTRATING.

Sure some methods can be 5 lines long.  But some are better left at 100.  Bottom line is you need to use your head about these things.  It depends on the type of project you’re on and the types of problems you’re solving.  

The best programmers don’t just follow guidelines (à la “extract til you drop”) blindly. The best programmers THINK for themselves.