jamesladdcode.com

At a recent user group meeting an attendee Chris discussed a problem he was having with the current project he was on, essentially he was being asked to fit 500 days of work into 300 days, a tough but common situation indeed. Chris had suggested all the usual things like cutting scope, extending the deadline, getting more resources, buying a competitors product and a few other creative suggestions, all of which were met with a “No, we wont do that.”. A few of us laughed and said welcome to the ‘Bring me a rock‘ game. Of course we had a lot of empathy for Chris since this situation is one most of us have been in at one time or another. We discussed his options, but could only see one - to diplomatically say “Here’s what we can achieve in the time” while looking for another job.

The software industry is still very young when compared to other industries and in general there are many facts about our industry that are not known or glossed over because at times some people don’t want to acknowledge the cold hard facts. Knowing these facts can help you in the “Bring me a rock’ situation and other situations by providing some independent backing for your position. So what are these facts?

Robert L. Glass has distilled 55 facts and some fallacies of software engineering into his book “Facts and Fallacies of Software Engineering” which is an interesting and easy read, with a lot of “Oh My God” moments. Knowing these facts and fallacies could help you avoid some of the perils of software development, like that experienced by Chris. Here are a random 10 facts from the book:

The most important factor in software work is not the tools and techniques used by programmers, but rather the quality of the programmers themselves.

Most software estimates are made either by upper management or by marketing, not by the people who will build the software or their managers. Estimation is, therefore, done by the wrong people.

Since estimates are so faulty, there is little reason to be concerned when software projects do not meet estimated targets. But everyone is concerned anyway.

Modification of reused code is particularly error-prone. If more than 20 to 25 percent of a component is to be revised, it is more efficient and effective to write it from scratch.

For every 25 percent increase in problem complexity, there is a 100 percent increase in complexity of the software solution. That’s not a condition to try to change (even though reducing complexity is always a desirable thing to do); that’s just the way it is.

Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical.

Requirements errors are the most expensive to fix when found during production but the cheapest to fix early in development.

Missing requirements are the hardest requirements errors to correct.

Peer reviews are both technical and sociological. Paying attention to one without the other is a recipe for disaster.

Quality is not user satisfaction, meeting requirements, meeting cost and schedule targets, or reliability.

In case you are wondering how it turned out for Chris, well he stuck to his guns and said he could not make 500 days of work happen in 300 and was sacked. My guess is he ran out of rocks. I admire Chris for telling it how it is and sticking by it, but I wonder if next time he will stretch the truth because that keeps him in a job.

We coders are probably all familiar with code smells that possibly indicate deeper problems in our code, and the need to refactor when they are found, but do you see interpersonal smells and the need to refactor yourself?

I often reflect on the interactions I have with team members and think about how those interactions went, mostly when I feel the outcome is negative or not what I expected. To me, these situations are interpersonal smells that possibly indicate a deeper problem in my interactions. Some interpersonal smells may be serious and some not, but I analyse each just like code to determine what if anything should be refactored in myself.

Just like code smells there is often a subjective judgement as to whether an interpersonal smell is really a smell or not and sometimes you need to call on others to help hold a mirror to your behaviour so you can make an informed decision. This is hard for a number of reasons, not least of which is having some good colleagues you can call on that will be honest and frank, as well as having the courage to carry out this reflection. Having others help you reflect is very important since a real interpersonal smell is like body odour, something that offends but the offended have a really hard time telling you that you have it. So how can you find out what you don’t know about yourself?

Depending on your circumstances you can just ask people you trust or you can use a more formal approach like that described in the Johari Window. The Johari Window is also referred to as a ‘disclosure/feedback model of self awareness’, and by some people an ‘information processing tool’. The Johari Window actually represents information - feelings, experience, views, attitudes, skills, intentions, motivation, etc - within or about a person - in relation to their group, from four perspectives. I have not used this model myself, but I know from research that it is apparently the thing to use. It can be used with groups as well. In my case I didn’t want to get that formal.

I asked some people I have worked with over the last five (5) years to give me a list of strengths and weaknesses so I can reflect on them and refactor my interpersonal smells. This is a hard and daunting task and one helper said “it really is ridiculously brave.” I suggest you also ask for strengths since you can read a weakness then a strength and use this to keep things positive and in perspective.

Here is a list of some of my strengths, as viewed by those helping me:

• Innovative and creative –> “an ideas man”
• Highly focused and results driven
• Always striving for a better outcome
• Technologically ‘hip’
• Protective of his team
• Values and encourages team input
• Highly congruent behaviour - Acts consistently with stated values
• Constantly learning and encourages team learning
• Customer and User focused
• Constantly identifying new ideas/opportunities that can exploit your technical skills/knowledge.

I’m not going to give the list of weaknesses as they are smells I am working on and hopefully going away by the time you read this. I am really glad to say that there were no surprises which means my process of reflection is working! Reflection on myself to identify interpersonal smells is important to me and my career. I encourage you to do it as well, and although it can be confronting the results are worth it. Let the refactoring begin.