Overtime is killing your productivity

Overtime is something of a given in today’s software development world. The question is if that is a good or a bad thing. I have discovered that it is an extremely bad thing!

After reading some books about project and team management I have discovered that most project are managed using the “Spanish theory”.  This is mentioned in the popular book Peopleware and in a compressed sense states the following:

Spanish Theory Management – Historians abstracted the Spanish Theory of Value that only a fixed amount of value existed on earth, while the English Theory held that value could be created through ingenuity and technology. While the English had an Industrial Revolution, Spain exploited the lands and Indians in the New World to move tons of gold across the ocean and achieved hyper-inflation as there was too much gold chasing too few usable goods. Spanish Theory managers dream of attaining new productivity levels through the simple mechanism of unpaid overtime by playing mind games (guilt trips, job security) with their employees.

According to this and my personal experience overtime has more negative side-effects than good ones. For a short amount of time overtime is the productivity boost that some projects need to get that corner. But today I see that overtime has become a way of work. It is not the last the resort that it should be but is the norm.NOS car performance system

In my minds eye I like to imagine that the project is a tricked out race car and the project manager is the driver. The project manager has his finger on the NOS trigger. Every one who had played a need 4 speed game or and other race game knows that the usage of NOS will give you a boost in performance that can mean the difference of winning or loosing the race. When to use the NOS is a highly strategical question. In reality it seems that most project managers start the race with the NOS button pressed and then they act surprised that their team members burn out half way through the project.

Being an overtime addict myself I tried to not do overtime on the last project I was in (and still am at this time). To be honest I could not believe the difference that made. Just to point out some:

  • The code quality went through the roof
  • The bug count was close to zero
  • There was actually some documentation done
  • Getting into the flow was extremely easy
  • My private life got better
  • I was a happier person all around
  • I actually produced code that I was proud to show

This got me thinking. How can I do more with higher quality in less time? Did I somehow find the holly grail of software development? The sad answer is NO, but what I have discovered was that project development can be done without sacrifising your own personal life.

I guess that the main reason why the whole project was successful is the simple fact that I enjoyed working on it! There were times where I would rather be someplace else, but those moments were few and far between. I started work at 9 am and went home at 5 pm. I fell into a daily routine that was not bad but actually benefited my work. I would get enough sleep and because I had enough time to spend with my family my personal problems diminished. Because of that I could focus my whole attention on doing something productive and not worrying about other things. There were still the usual “flow killers” around like booking hours and filling out reports but they somehow did not bother my flow. Much more than that they became a part of it.

Do not get me wrong that there was no pressure on the project. There was immense pressure, but somehow it did not result in general panic mode in the development team. Every day I was there on top of my mental faculties and the code just flowed out! Regardless of the pressure the code was delivered on time on a little before time. That gave me many little opportunities to do refactoring on the code, which made my work only easier and more productive in the long run. I do not get why many project managers fail to notice this fact?

Regardless of all the positive benefits of not doing overtime as a way of live there is the pure economical reason why not to do it. Most developers today have contracts in which overtime is not payed or is somehow compensated. For most people that means that the extra time spend at work has absolutely no economical benefit for them, but all for the company. You spend your precious time at work for virtually free while the employer reaps all the benefits. There is no cheaper labor than free labor!

While you are loosing money the company is making money. This is only fear for one party! In the time you “waste” at work you could be with your kids or working on that personal pet project or earning some extra money by doing something else.  And as soon as people notice that they are clearly at an economic disadvantage the productivity breaks in drastically. Which ultimately results in a failed project or worse.

What I keep reminding myself about is that I have signed an agreement with my employer that I will sell 40 hours of my live per week for a specific amount of money (or other goods). So if I do more than 40 hours a week I expect that the employer will compensate me accordingly! And by accordingly I do not mean that the extra hours will go into my vacation time. Because if you are already doing overtime you will not be able to use that extra vacation time anyway.

The bottom line is that overtime is something that should be used only as a last resort and when that time comes and people stay in the office and play with their keyboards instead of their children then the compensation has to know in advance. If you are a good employer then the developers will all willingly help you if you are in a tight spot. If you treat your employers like cattle then do not be surprised when get limited or no support for your “business goals”.

The bus factor

After being gone for some time I will start with a light management post 🙂

So let’s get going.

First we have to find out what the bus factor is. According to Wikipedia the bus factor is:

In software development, a software project's bus factor is an
irreverent measurement of concentration of information in
a single  person, or very few people.
The bus factor is the total number of key developers who
would need to be incapacitated, as by getting hit by a bus,
to send  the project into such disarray that it would not
be able to proceed.

So basically the higher the bus factor of your project the better.

Regarding this little project metric there are two question that arise:

  1. How to determine the bus factor
  2. How to raise the bus factor

How to determine the bus factor

First we have to clarify that the bus factor is a subjective measurement and therefore does not lend itself to monitoring. But regardless of that the measurement is quite useful to point out problems in your team.

So if you want to know the bus factor you just have to ask yourself the following simple question for every team member:

Could the project continue if he got hit by a bus?

The more yes-es you have the better 🙂

It is quite impossible to put a general rule of how high the bus factor should be because it depends on to many factors. Personally think that 50% of your project team but not less than 2 is a good number. But that is just my personal impression.

But regardless of my opinion if your bus factor is 1 (one) then you are clearly doing something wrong!

How to raise the bus factor

If you have come to be in the situation that your bus factor is a little to low for comfort then your goal should be to get the factor up.

Basically it all comes down to increasing communication in the team. In a software project communication is everything! If your team members are not communicating you as a manager have weary few options left in your repertoire of management tricks.

To get this clearly out of the room. My personal opinion is that if a team does not harmonize then the irritating factor should be removed from the team. It makes no sense to let four people suffer because one can not drop his ego.

All that you as a manager can do is to provide a platform for the individual team members to communicate. These include:

  • Organize daily standup meeting where the whole team can get together and discuss what has been done since the last meeting
  • Organize extra budget to do pair programming
  • Organize code review session with all team members (this will do wanders for your project in more than just one way)
  • Identify the person which has the highest knowledge accumulation and persuade him to share that knowledge

The last point is the hardest to do. Depending on the organizational atmosphere this is almost impossible to do. In some firm a developers salary is dependent on their inexpendability. In such an environment the developer will actively refuse to share his “knowledge” and to be honest I can understand him. Why should I endanger my position in the company and risk a lover pay or ever being fired later on? It is the job of the manager to answer this question and give reassurance (real reassurance and not just the moral one).

The biggest bus factor is you

If you manage a project you are the biggest bus factor! You are the manager! You keep the company from the development team to give them time to actually do their job. If you become “unavailable” then the project team has to do all of your tasks plus their own.

Do not underestimate what you do for the team. I am a developer but I know what a project manager does. All the little tasks that the development team does not like to do:

  • Managing timeliness
  • Communication with other development team
  • Reporting to upper management
  • Getting the developers what they need to do their jobs (from paper clips to that component from the other team)

So you have to find a way to take yourself out of the equation. There are a few ways that you can do that:

  • Have a deputy at hand
  • Tell the team what you are doing
  • Keep a public list of all your communication contacts (who from the aurora project time have you been communication with)
  • Make all documentation that you have created accessible to the team

Conclusion

I hope that you have gotten a sense of the importance of the bus factor. It is something that you will not be able to include in your annual project progress report but is something that is worth keeping an eye on.

You newer know when a bus driver will fall asleep.

Pessimistic vs Optimistic

Locking that is.

I had a funny situation recently. The funny situation being: moving document from the document management system to the source control system. Nothing special and I understand the reasons. But it got me thinking… Some time ago I would have opted to keep everything in source control. And getting a little maturer I changed this opinion.

Today my opinion is that document should be kept in a document management system and source code in a source control system. Sounds logical. But did you ever ask yourself why this is so? I have today and after thinking about it for some time came to the conclusion that the main difference is the concurrency control.

If you want to read more about concurrency control you can find better sources on the internet. What I would like to stress here is:

  • Source control system use optimistic locking
  • Document management systems use pessimistic locking

Working with source code you do not want to acquire exclusive edit tokens for every file you touch. This would basically make normal work impossible.  You want to do your work and after you are done you take care of all the conflicts.
On the other hand if you are working on a document (word, writer, …), the last thing you want is to find out that someone beat  you to the punch and checked in a newer version of the same document. Resolving the merge conflicts is quite a challenge. In this situation you want to acquire a exclusive edit token for your document.

So why is resolving merge conflicts in document hard and the same thing with source code easy? Thinking about it I come to a weary simple conclusion: Source code is nothing more than text file; documents are big binary files that need special applications to make sense of the zeros and ones.

Taking this into account we have to change our initial categorization of source code and documents to text files and binary files. Going along this line of thought we can put up the following finding:

  • Optimistic locking with text files
  • Pessimistic locking with binary files

This way you can edit all your images, documents and presentations without fear, and the developers can do their stuff efficiently.

SCRUM, Kanaban and co.

We have come a long way since the early days of software development, or have we? I honestly am not too sure about that anymore. As we “advance” in some aspects I can’t help myself as to feeling a funny feeling of deja vu. So it comes to no surprise that the same is true with management. Although many managers are beginning to grasp the concept that managing a software projects in not the same as managing a manufacturing plants the majority are still stuck on the other site of 1890.

In the beginning our managers tortured us with the waterfall methodology. And we all hated it!! Then in the year 1995 a new star was born. SCRUM made its first baby steps and all was good. It was a quantum leap into the right direction and it looked extremely nice on paper. Developers could do more work and managers had less to do because the almighty scrum board would do most of their work. The methodology has gathered a cult following which is only matched by apple fan-boys in number and ferocity. And still the projects went overboard. To the ScrumBoys this was of course not the fault of SCRUM but the team that used it wrong. In hindsight I wish the bloody thing would have come with a users manual. With waterfall you had the almighty Gantt chart that clearly showed the way the project will fail. But with SCRUM that was not so easy anymore.

SCRUM has many problems when faced with the day-to-day reality of making unique stuff. So as it looks now we are getting a new contender that has proven itself in the auto industry. SCRUM is dead long live Kanban I hear the people crying while I still pickup the broken shards of my last project. And after my personal experience with SCRUM I am willing to give it a try.

So what is kanban? According to Wikipedia it is the following:

Kanban (or kamban in Hepburn romanizationkanji 看板, katakana カンバン, meaning “signboard” or “billboard“) is a concept related to lean and just-in-time (JIT) production. According to Taiichi Ohno, the man credited with developing JIT, kanban is a means through which JIT is achieved.[1]

Kanban is a signaling system to trigger action. As its name suggests, kanban historically uses cards to signal the need for an item. However, other devices such as plastic markers (kanban squares), balls (often golf balls), an empty part transport trolley, or simply a floor location can also be used to trigger the movement, production, or supply of a unit in a factory.

The need to maintain a high rate of improvements led Toyota to devise the kanban system. Kanban became an effective tool to support the running of the production system as a whole. In addition, it proved to be an excellent way for promoting improvements because reducing the number of kanban in circulation highlighted problem areas

Nice little description and I must admit that my hopes are high again. But (there is always a but). After reading some articles of what Toyota is doing and what Kanban is doing I fail to see the direct correlation. In my world there is a big difference between creating a Toyota Prius door for the millionth time or creating moduleA for application Z for the first and only time. At Toyota there are dedicated workers that create doors when they are needed, I doubt that you company has a developer there that only does moduleA. So there goes reality! Well I still think that it will fair better than SCRUM. If for nothing else then because it gives the gun back to the development team. This gives the developers the power to shoot themselves at their own leisure.

But back to the world of normal. Kanban makes a major overhaul on the SCRUM Kanban board. The notion of a sprint is drooped in favor of the release cycle. All in all some cleaver “innovations” that could actually make sense.  Before I run out of stuff to write about I would like to go through the 6 points that Toyota set up for Kanban:

  • Do not send defective products to the subsequent process
    I guess this is the zero defects myth again. Even Toyota failed at that. So this is a valiant point that every sensible developer wants to reach. So nothing new here.
  • The subsequent process comes to withdraw only what is needed
    In software we only code once and then reproduce until doomsday. So the subsequent process will take everything from the previous process. So not much sense there eighter.
  • Produce only the exact quantity withdrawn by the subsequent process
    We need only one and we produce only one. So make a big fat green tick on our TODO list.
  • Equalize production
    Create 1 consume 1.
  • Kanban is a means to fine tuning
    This makes sense. Nothing to say here.
  • Stabilize and rationalize the process
    Interesting point. But again the process does not repeat itself so there is no rationalization in something that only happens once.

I know that this is only true for one-off software. But then again most of software is.

In the end Kanban will bear the same risks as SCRUM and a few addition for free. It is up to the development team to make software effective. If you still think that Kanban will save you company or make your developers into super efficient coders that spit out code faster than the speed of light then you are beyond help. The only think that could help you is the Poepleware book, go and buy it.

All in all I hope that the history will not repeat itself.

Building a .net solution using RAKE [part 2]

As begone in the previous post lets look at the RAKE script.

Preparing the build

The first thing the script has to do is to initialize the file structure it is going to work with later on in the script and there are some global variables to set. And before you look at the code this is the biggest task in the build script.

task :prepare do |taks, args|
 require 'fileutils'
 require 'ftools'
 FileUtils.rm_rf Variables::OUTPUT_PATH if File.exist? Variables::OUTPUT_PATH
 Dir.mkdir(Variables::OUTPUT_PATH)
 Dir.mkdir(Variables::SOURCE_PATH)
 Dir.mkdir(Variables::WIKI_PATH)
 Dir.mkdir(@RELEASE_PATH = "#{Variables::OUTPUT_PATH}/#{Variables::PROJECT_NAME}_#{args["version"]}")
 Dir.mkdir(@DOCUMENTATION = @RELEASE_PATH + "/Documentation")
 Dir.mkdir(@VALY = @RELEASE_PATH + "/Valy")
 File.copy('nunit.xsl', "#{Variables::OUTPUT_PATH}/nunit.xsl")
end

Before we can begin our build and copy bonanza we have to prepare some directories into which we want to copy to. Just to avoid all those nasty exceptions later on.

The first to lines “import” some useful things that we require for our IO operations. The fileutils is a IO class that comes with rake and proves extremely useful. So we create a few directories and set the required variables for later use. The last thing we do is to copy the nunit.xsl to the output directory.

If you are wondering what those Variables are then let me disappoint you. There are just constants defined in another file so they do not clog up the main rake script.

module Variables
  ## Project paths
  OUTPUT_PATH = "../Release"
  SOURCE_PATH = "#{OUTPUT_PATH}/Code"
  LIB_PATH = "../Sources/Lib"
  WIKI_PATH = "#{OUTPUT_PATH}/Wiki"

  ## Third party tools
  NUNIT_EXE = "#{LIB_PATH}/NUnit/nunit-console.exe"
  DOT_NET_PATH = "#{ENV["SystemRoot"]}\\Microsoft.NET\\Framework\\v3.5"

  ## Build properties
  CONFIG = "Debug"
  PROJECT_NAME = "valy"
end

Getting the sources from the repository

As mentioned before valy is hosted with Google code in a mercurial repository. To make my life (and the scrip) easier I have tortoiseHG installed locally.

So let’s take a look at the script that gets my sources from the repository

desc "Gets the sources from the valy repository"
task :get_sources => [:prepare] do
   Helpers.clone_repository("https://valy.googlecode.com/hg", Variables::SOURCE_PATH)
   Helpers.clone_repository("https://wiki.valy.googlecode.com/hg/", Variables::WIKI_PATH)
end

To make it easier the Helper module defines a method clone_repository that looks quite simple.

# Clones the given mercurial repository
def Helpers.clone_repository(repository_path, output_path)
  puts "Cloning repository #{repository_path}"
  unless system "hg clone #{repository_path} #{output_path}"
    puts "Clone FAILED"
    puts $?
  end
end

I must say that I like this piece of code. It’s simple and effective. I take advantage of the fact that I can do a system call to hg and it will get the repository for me. I am using the system command for this because it returns a boolean and in the case of failure stores the error message in the $? global variable.

And that’s it. Now you have the sources on your local system.

Building the solution

This is actually represented in two tasks:

  1. Set the version number in the assemblyinfo.cs
  2. Build the solution using MsBuild

The two tasks again look “quite” easy.

task :set_assembly_attributes => [:get_sources] do |task, args|
  Helpers.set_assembly_version "#{Variables::SOURCE_PATH}/Sources/valy/CommonAssemblyInfo.cs", args["version"] if args["version"]
end

desc "Compile solutions using msBuild"
task :compile=> [:set_assembly_attributes] do
  solutions = FileList["#{Variables::SOURCE_PATH}/**/*.sln"]
  solutions.each do |solution|
   Helpers.build_solution(solution)
  end
end

Both tasks depend on the Helpers module that we will look at later. For now lets concentrate on the task at hand 🙂

The :set_assembly_attributes task is the only rake task (until now) that uses parameters represented by the args in the task block. So if the version is not given the default version will remain at 0.0.0.0. To illustrate lets look at some calls to the rake script:

c:\valy\build>rake version=1.0.0.1
=> dll version = 1.0.0.1

c:\valy\build>rake
=> dll version = 0.0.0.0

Before we look into how I set the assembly version let me state that I have seen all the libraries and custom task out there and found them to complicated form my purpose. So just 4 the fun of it I did it my way.

def Helpers.set_assembly_version assembly_info_file, version
  unless File.exist? assembly_info_file
    raise "File #{File.extend_path(assembly_info_file)}, not found";
  end
  buffer = ""
  buffer = File.open(assembly_info_file, 'r'){|f| f.read.gsub(/0.0.0.0/, version)}
  File.open(assembly_info_file, 'w'){|f| f.write buffer}
end

As is visible from the code above I use a simple regex replacement to change all occurrences of 0.0.0.0 to whatever I provided the script as the version. It is not perfect nor pretty. What I hate the most about it is the fact that I need the buffer, I would rather read and write in one single stroke. But this will do for now.

After seeing the clone_repository method the build_solution is no big surprise.

def Helpers.build_solution solution_path
  puts "Building solution : #{solution_path}"
  if system "#{DOT_NET_PATH}/msbuild.exe /noconlog /nologo /p:Configuration=#{CONFIG} #{solution_path} /t:Rebuild"
    puts "Build SUCCEEDED"
  else
    puts "Build FAILED"
    puts $?
  end
end

Looks familiar? Well it is. This is the first indication that I will have to refactor this in the future to make it “prettier”. But for now it works.

Running unit tests

This final tasks is not yet complete. After the tests are run the xml output is not transformed into HTML using the XSL file provided at the beginning 😦 But the rest of the task looks as following.

desc "Testing the build assemblies using NUnit"
task :test => [:compile, :prepare] do
  tests = FileList["#{Variables::SOURCE_PATH}/**/*tests.dll"].exclude(/obj\//)
  Helpers.run_tests tests, Variables::OUTPUT_PATH + "/TestReport.xml" unless tests.empty?
end

As mentioned before this is still work in progress…

Basically what happens is that I search for all Dlls which names end in tests and exclude the ones found in the obj folders.

Enter the Helper that actually runs the tests.

def Helpers.run_tests tests, report_file
  puts "Running tests"
  system "#{NUNIT_EXE} #{tests} /nologo /xml=#{report_file}"
end

Basically just runs the nunit console command with some parameters. So nothing special here. Yet.

And that is all I prepared for this post. Next time we will look at how I:

  • Get the test coverage
  • Harvest the build files
  • Package them into a zip file

thx for reading.

Building a .net sollution using RAKE

When working on a project you do accept that you have to do some choirs that you would rather not. When working on something “just4fun” this same assumption is just not true. If I am spending my free time behind the computer then I want to do things that I want to do. One of those things that I hate to do are reports and deployment packages.

The sad truth is that you need both. So what can you do about it? From my standpoint you have two options:

  1. You just do it by hand and bear the pain
  2. Automate it!

As “The pragmatic programmer” and “The productive programmer” are teaching us automation is the way to go! So we have to look at build automation. In the past I would just open a text editor and start typing a ANT build script. But for valy I wanted to do something new. And the reasons why I wanted to get from ANT are the following:

  • XML is good for structuring data but are really bad when trying to capture a process
  • It is quite hard to get a reasonable structure into the XML file
  • It takes quite some experience to reasonably read the ANT file

I hope you get the general idea that XML is not a good way of describing a build process. ANT is a great tool but the XML format is killing it for me (hope they provie a DSL in the future).

So after long consideration I opted for RAKE. Rake is a Ruby based DSL for build automation. If you have ruby installed then getting RAKE is as simple as installling an addition gem. But setting up RAKE is not a part of this post.

After opting for RAKE I had to determine what my build script will do and if I will have more than one to get the job done. Some hours later I came up with the following list of tasks it has to do:

  1. Get sources from the mercurial repository
  2. Build sources
  3. Run tests
  4. Run nCover
  5. Assemble documentation
  6. Create a deployment package
  7. Compress

Not exactly mission impossible but still a challenge.

Before we continue let’s get something clear. The scripts posted here are still work in progress and my change. If you want to follow my progress, all scripts are published at http://code.google.com/p/valy/source/browse/#hg/Build. And ofcourse you can copy and use at your delight, just let me know if you made some improvements.

I will not use any words on how I structured the code because I lost to many words already 🙂

Because this post is getting quite long I have decided to break it into multiple posts.

So until next time.

The PM whisperer

Yes project managers. Don’t we love them?

We tell ourself that they are important to the project but still we find it kinda hard to work with them. Why is that? My personal theory is that they are people employed to break the developers “flow” every half an hour and at the end of the week ask the mandatory question “Is it done yet?”. This is the time when we have to display a Jedi like self-control. But still we like them. Why is it that we can’t seem to work with them? Why do we constantly argue with them or just turn around and do their biding? Why I ask you?

And the answer is simple. They are the lesser evil. Most developers do not care about the business side of their work. We just want to write good code! We just want to come to work sit behind our keyboards and turn coffee into code! So we created the project manager to manage us! Take care of our basic need to not care about all the stuff that is not code. But lately I see that the PMs have developed self awareness and are trying to think. This is dangerous. Do not get me wrong not all PMs are evil. Some were developers before they were twisted and warped into PMs (pore souls).  No the real enemy is the 30 year old graduate of a business school that is trying to manage the team and has no interest in the work or the product. He just wants reports and epilepsy inducing charts!

So what can we do about it? Well I see two options:

  1. Get read of the management and code like its 1996
  2. We learn to work with them

Sadly option 1 is not a option. Why? Because I am afraid that a platform debate would kill 80% of the development community and visual basic would win. And we cant allow that!

So we are stuck with option 2. But how do we do this? Simple we will apply the same technique that biologist used to study new species! We just have to do the following steps:

  1. Learn the basic information – in our case this means we will gather all the information we can about them. Goggle and Wikipedia are your friends
  2. Observe! – because we work with them it will not be hard to observe them in their natural habitat. So keep your eyes pealed and notebooks ready at work
  3. Look for nests after breeding season – OK this is just wrong and well gladly skip this part
  4. Go online and the library – already done that in step one. But a recheck could do no harm
  5. Ask the experts – because this is a new observation and not much literature exists on this subject finding valuable experts could prove a bit of a challenge
  6. Keep learning – the nature of our business is to learn new things so this should not be a problem

There is a PHD somewhere in there.

But alas we have not the time do this. So we have to take some shortcuts. Basically we will call on our immense deducticall faculties to give some pointers on how to get it right.

Communication

First we have to learn how to communicate with them. The main problem being that we use a language of abstractions and mathematical formulas and they use a language of pie charts and excel sheets. I lovingly call their language  piesheet. So how do we start a conversation without an universal communicator?  We should try to find the lowest common delimiter. In our case this is the project. We all work for it and we all want to see it get done if for nothing else then for the sake of getting reed of the monster so we can start work on a new one. Each on the team has to know what the project is about and what its purpose is. This part was easy, because most of it is dependent on the customer or target audience.

Now comes the first major tripping stone in the communication, “estimates”. They call them estimates I like to call them wild guesses. Well not even a guess because its easier to guess the lottery number than to give an accurate estimate. Lets take the following conversation:

PM: Bob, the customer wants an extension on the billing system. How long do we need for that?
DEV: What kind of extension?
PM: Oh nothing big (my development senses are tingling) they just want to be able to add an additional billing type.
DEV: OK?! What kind of billing type?
PM: They would like to have the possibility to split the payment between a cash payment and a credit card debit.
(This would be a perfect time to ask the all important question WHY? But for the sake of keeping it short we just assume)
DEV: So basically they would like to split the payment between two debiting stations?
PM: I guess. So how long would that take?
DEV: I would say no more that five days.
PM: Great. I will speak with the customer right-away.

So lets take a look at what each of them have taken from this conversation:

PM: OK the change will take no more than 5 person days and the cost will be 5 x 700$ = 3500$ to that we will ad 20% of risk management and 20% for quality control. So the final price will be 3500$ + 20% =  4200$ + 20% = 5040$. So the change will cost no more than 5040$.

DEV: How the freaking hell did they come up with that? What were they thinking when they ordered this stuff. Well OK we have 5 days and me and my team will make it in five days. So the calculation goes something like this:
3 developers working for five days at an average rate of 10 hours a day (when was the last time you left the company after eight hours?).  5 * ( 3 * 120$) = 1800$. But wait this is not as innocent as it seems. We have to take into account that the daily “business cost” of a developer is 700$ and so this little endeavor will take on a whole new dimension: 5 * ( 3 * 700) = 10500$ .

So we come to the situation that the change has cost twice as much as originally estimated. Why is that? For once the communication is just plain broken. The other one is that we are expected to make estimates on the fly. And don’t give me this meetings bullshit. You can not expect a single person to have the whole application structure in his head. A good estimation takes time. Time that is just not given. Then we could deliver a better estimation but not an accurate one. So basically we are screwed. But I know that estimates are crucial. What I can’t understand is that our misguided estimates are then presented to the customer as de facto.

Example time: When your car breaks and you go to your local car repair shop to get it fixed you first ask for an estimate. And that is what you get. You get an estimate of what it could cost. You decide based on that estimate, and then after the car is fixed you get the bill with a number that usually differs from the estimate. So why in the name of all that is holly do we do it the other way around? Still waiting for the answer to that one!

The second part of the communication issue is the need to explain things. This is shown in two ways:

  1. You explain everything multiple times
  2. You have to explain low level development stuff in piesheet (reference to language above)

From my experience most PMs are not interested in the technical stuff until they have to explain it to someone (a big salute at this point to my current team).  So they just set up meetings and do not appear to them or show no interest in the development process that will produce the product he is managing.

So it happens that first you talk to the customer for 2 hours then you come to the office and just want to work. But no! You can take a chair and explain everything again to the PM. And after you hammer the knowledge into him you can go off and write the meeting minutes. So a two hour meeting will take anything from 4 to 6 hours of your 8 hour day. And then you are expected to do 6 hours of work on top of that. Do the math and tell me whats wrong here.

The other one is when the PM suddenly develops an interest in the implementation. Now you have to find a way to explain the code structure and other code specific things. This is just wrong. We operate at different levels of abstraction. Do you ask your surgeon if he will use a #5 or #9 scalpel? I don’t! Usually my only question is: “Will it hurt?”. Thats all the information I need. And to be honest I do not want to know how he will do his job. I just want it to be done.

And there is the question of how will you explain your “hack” you had to do to get the application to print on toilet paper? Do you really want to go through that traumatic experience again?

But enough about that lets take a look at another problem we have to solve, documentation.

Documentation

Documentation is a big part of the software development process. Humans forget, document don’t! So we get the point of documentation. But every thing has its limits. It usually happens that there is to much documentation produced by the team and no one reads it. When you write a 5 page essay about a half hour meeting you cant expect us to read it. We were there for crying out loud. Sometimes documentation is written just for the sake of documentation. To have something to put into the document management system and point at it when you can’t answer a question. This is kinda counterproductive. If I want a given fact I do not want to read through pages upon pages of documentation to find out that the application background should be blue with green starts. Which brings us to the documentation format.

In my opinion word is a place where information goes to die. After a document is written it takes enormous effort to keep it up to date. And when it takes effort you have to force a developer to do it. Developers have a live up to date documentation of the system. We like to call it source code. It’s a shame that no one else in the world can read it. So what do we do about it? I like the idea of the project wiki. An informal place where information can be stored, and changed effortlessly.  Some documentation in the form of document have to be created and maintained. But not all! I do not want to fill out a 5 page form just to get a refactoring done. And after I take my time and fill out the form I still have to justify my purpose in-front of a board of PMs. So whats the point of it?

Basically I have the felling that all the documentation is there so that someone could theoretically track all decisions the team had made in the project. And now I ask you. What would cause that to happen? Nothing! Even if people die they ask the developers and they can then tell them. No one goes through the million of pages of documentation.

So let keep the documentation at an manageable level.

Context switching

What is that you ask? I do not know about you but the majority of developers I have talked to and worked with are men. And men are notoriously lousy at multitasking. That basically means that we can do one thing at a time. Like dos or windows 3.11. So we are happily coding away in the “flow” and then comes a question from across the room. You try to ignore it the firs time but your flow is broken. So you turn around to answer to a question that has absolutely nothing to do with your current work. Because your are a man you have to unload your current work context and load the question context, this can take a minute or two. Then you answer the question, which is in the most case’s a simple yes or no question. After the question is answered you turn around and try to figure out where you left out. It’s like if you are reading a book and suddenly have to sneeze. It will take some time to find the exact word you left of. Same happens here. Just that the process takes everything from 1 to 15 minutes. Not a big deal but if you add all of those minutes end to end they add up to a couple of days in the project where you just try to figure out where you left off.

The funny thing about context switching is that it is not broken if you stand up from the computer and do something that does not include your brain like drinking a coffee, take a smoke or just get rid of some extra weight in your bowels.

The human concentration is a funny thing.

The final verdict

Freaking hell you know I don’t have any! This is like the newer-ending story. There is just no end. All you can do is to work with your current situation. Or get read of your PM and pledge for temporary insanity.

I must say that I am one of the luck ones. Where I have a PM that cares for the people in the team and not just for the charts and excel sheets. I am really one of the luck ones. Not to say that there are not some rough edges in our team to. But we can manage.

If nothing else I hope you had a little laugh reading this. And if you one of the select few then I hope you have seen some trough in my silly little rant!

Thanks for reading and don’t forget to offer me a job 🙂