IT consultancy companies should learn from used car dealers!

June 6, 2012 at 1:49 pm | Posted in Agile, Ramblings | Leave a comment

Let’s suppose that your old car one day suddenly stops working and it is beyond repair. So now you are in the market for a new (or second-hand) car. You have a mental model of what you are looking for: it should be roomy enough for your family and 2 dogs, it should be safe and of course your new car should have sufficient power. Together with your wife you decide that you want a MPV. So you walk into the nearest car dealership. To your surprise it is a rather nondescript building and when you enter it the showroom is completely empty. Luckily enough there is this friendly car sales guy and you start to talk to him: “Hi, we are looking for a new car and …”. Before you can finish your sentence he raises his hand to stop you, smiles at you and walks back to the counter. He returns with a key and hands it over to you. “Here is the key of your car. If you just follow me, I will show it.” Completely flabbergasted you and your wife are led into a parking lot behind the building and he points to a Mazda MX-5 Miata. You start to protest and try to explain that your 3 children and 2 dogs are not going to fit into a convertible, but he ignores your protests. “I’m sorry Sir, as you can see this is the only car we have got. And I think it is just right for you. Good luck!”

Now the above scenario might sound a bit absurd, but this is what I see a lot in IT consulting: your current project has come to an end and in some magic gathering that often goes by the name “Project Allocation Meeting” or “Resource Meeting” the sales guys and girls at a typical IT company have decided that the very first project that comes along miraculously is the perfect fit for you. And you can already start tomorrow. Sounds familiar with that single car that is for sale in an otherwise empty dealership?

Lets first have a look at the criteria for a good project allocation process:

  1. Limited waste because of non-billable hours. The business model for IT consulting is rather straightforward: revenue equals the number of billable hours multiplied by the hourly rate of a consultant, summed over all consultants. Both parameters are not very scalable, so it is tempting to maximize the number of billable hours by leaving no gaps between projects.
  2. The right fit: projects should be challenging enough so that a consultant can develop his skills. Working below his level is going to make him leave the company eventually. Working far above his level will only result in a burn-out. In general: the assignment should be a good fit in the career path of the consultant. That will make him move valuable to customers so you can ask higher rates later.
  3. Physical location: a project at a nearby customer will limit traveling time and will result in overall happiness. Long traveling times will make it unlikely that the consultant is going to put in some extra hours for either the customer or his own company.
  4. Other criteria like for example: does the customer’s culture fit with that of the consultant. Putting a consultant who thrives on freedom into a limited or formal organization like an insurance company is not going to make him very happy.

You will notice that the first point is a rather short-term optimization. The next three points are going to have way more impact on an IT consulting company but the effects are not immediately noticeable. Therefore an IT company will have to make a careful trade-off between optimization for billable hours (which is easy, a straightforward computer algorithm can do this for you!) and long-term sustainability and profit. This is quite difficult and one of the reasons that most consulting companies behave like this weird car dealership I introduced at the start of this blogpost. That brings me to the conclusion.

So we can choose the company we like to work for, the place we want to live, or our own car. And yet in IT consulting others are deciding what assignments best fit us. What I would like to propose is a very simple project allocation process with a minimum amount of overhead: All project information is always visible to every consultant. Very similar to a car dealer that has many cars on display. So you can pick the right car or in this case: the right project for you. That comes with the freedom of waiting for a better opportunity and passing a project. Of course that also comes with the responsibility for balancing the number of non-billable hours. That could be done by putting a cap on that number or by introducing some kind of rewarding mechanism.

Most important is that an IT consultant can perfectly well make these trade-offs himself. Self organization and responsibility at the lowest possible level instead of old Soviet style planning!

Bug reporting: 8 ways to annoy your software development team

March 14, 2012 at 12:04 pm | Posted in Programming, Ramblings | 18 Comments

As usual this blog post should be read with a large grain of salt. It is a collection of bad practices I have seen during many software development projects. There are positive exceptions. For example when the testers are part of the development team and the whole team is committed to delivering valuable software instead of two opposite parties trying to fight each other. Having said that, the ugly situation mostly happens in fixed-price contracts where the bug versus feature discussion often takes place.

Disclaimer: all the examples are made up. Any resemblance with bug reports from projects I did is pure coincidence 😉

So here is some practical advice for acceptance testers on how to maximally help a software development team:

1. Since you have spent a lot of time finding this bug, prioritize it at least as Major. Of course Critical or Blocking is even better so that the development team will realize it is urgent and pick it up immediately. Luckily most bug tracking systems (for example JIRA) have priority Major as the default setting so you don’t have to spent too much time thinking about this. Example: a missing help text on what the field ‘zipcode’ means should be marked as major because it is going to leave the end user clueless.

2. Make sure that the description of the bug is short. A single word is better than a long descriptive sentence. The advantage is that it forces the developer to open this issue every time to understand what it means. This will help him to not ignore this bug just by reading the description. For example ‘Login’ is a much better description than ‘Login failure when I fill in a non existing username’.

3. Don’t let yourself be fooled and use improvement, change or new feature when filling in the issue type. Everything you find is a bug. Otherwise your organization (the customer) will have to pay for it, especially in fixed-price contracts. There are two situations to be handled here: if it is in the specification, then it obviously is a bug if a feature is missing or not accordingly to the spec. If it is not (clear) in the specification then you can always defend it by saying ‘it is obviously that this is not acceptable for the end user, so it is a bug’.

4. Never provide details in your bug report! This might put developers on the wrong track. It is much better to let them find out themselves what caused this problem and how to reproduce it. After all, they are the experts. That will also give them a strong incentive to deliver better software the next time. A good example is of course the good old ‘Doesn’t work’ or ‘Program crashed’.

5. You can (and should!) often re-open an existing bug-report. This is just a practical thing and saves you some time. Especially if you have a good generic bug description (Like for example ‘Login’ mentioned before) this is very convenient. But don’t be bothered if the new bug isn’t related to the old one. You are just helping the developers to limit the total amount of bugs and re-opening fixed issues gives them a nice historic perspective. Software developers like re-use and DRY (Don’t Repeat Yourself), so should you as a tester.

6. Another practical tip: combine multiple bugs in one single bug report. Again you are helping the developers here because many bug reports might give a bad impression. It also helps to give them focus: suppose the login functionality in your application doesn’t work, then it is also a good moment to combine that with fixing a spelling error on that same page and probably adjust the colors a bit so they are more conform the specification.

7. Bug-reports are also great ways to communicate, especially with introvert developers. So you can create a major bug with a question like “What does the specification say about this Cancel button?”. That will help them to think about the spec, enable single/double/triple loop learning, etc. It might take some time, but someday they will appreciate what you did for them.

8. Another great way to stimulate software developers in a positive way is to use bug reports to give them some good advice. For example “Feature xyz is not very easy to use.” This example can be easily marked as ‘Critical bug’ and it will sparkle the creativity of the development team to come up with a great solution. That is also the reason that you, as a tester, shouldn’t give away any information on how this feature should be improved because you want to empower the developers instead of extinguishing  their creativity.

I’m sure there are many more ways to improve the communication between testers and software developers. Don’t hesitate to share them!

Help, my manager has a vision!

February 19, 2012 at 5:26 pm | Posted in Ramblings, Uncategorized | Leave a comment

I started my career about 20 years ago. The first week I got an email from my group leader in which she told us that she had scheduled a meeting with an important topic. This was back in ’91 or ’92 and there were quite a few layoffs due to the crisis and first Gulf war around that time. So a couple of days later when the meeting actually took place and the whole group (that was 3 people!) looked at her in anticipation and a bit of fear. And then she started the meeting with “It is important that we as a group have a mission statement.” I only remember that we looked at each other slightly uncomfortable and thought what the hell is she talking about.

In the following 20 years I have been in this situation many times, so I thought this would be a nice opportunity to write down a simple step-by-step plan to handle such a situation.

Step 1: the Steve Jobs test

This is a very simple test and only takes a couple of seconds. Is your manager a major pain in the butt but at the same time you get a lot of energy when he or she is around? In that case he might actually have a vision which is worth listening to. And even if you don’t listen, if he really is like Steve Jobs his vision will take off anyhow. On the other hand, if your manager is a dull bureaucratic type of person who never had an original idea in his life, it might very well be that he recently has read Steve Jobs biography and mistakenly thinks that he can do that as well.

Step 2: gather the facts

Maybe your manager did read the biography. If not, his silly ideas must have originated somewhere else. There are a couple of possibilities: if you noticed many consultants around the office during the last weeks or months, they might be the source. The other possibility is that there has been an announcement at the company level. You might have noticed an e-mail from the CEO in your mailbox, or maybe even a new company logo. Typically a vision trickles down to the workfloor, where each management layer will take anywhere between a week and a month. This also means that your manager probably doesn’t have a choice: he must have a vision, aligned to the company vision.

Step 3: try to understand the vision

This sounds like a useless step, especially if it is already so obvious to you that your manager isn’t Steve Jobs. However, this only takes a couple of minutes and it is important for the next step. The goal of this step is to find out if by mere coincidence, your boss still has laid out a brilliant vision. Just like the Infinite Improbability Drive this might give tremendous energy to your unit, your department of your organization.

Read the document or presentation. If it is larger than 1 page or 1 slide you can already stop. This is not a vision. Next scan the document for words like ‘better’, ‘cheaper’, ‘faster’, ‘most cost effective’, ‘best in class’, ‘thought leaders’, etc. etc. Real visions don’t include those words.

In the unlikely event that the vision is real (it is motivating and inspiring) you can skip step 4. You are a lucky person with a great manager! Congratulations!

Step 4: handling the situation

You are still reading this because apparently your manager’s vision is as was to be expected: meaningless. Now you have a couple of options to handle this. Let me explain them for you:

Wrong way to react

Telling your boss straight-out that his vision is stupid and a waste of your time is not going to help. Of course his vision is never going to happen but you don’t want to be the person he is going to point to as a scapegoat. It is also not going to help during your yearly performance appraisal.

OKish way

Usually you can quite safely ignore your manager’s vision. Main reason is that there will be a new manager and a new vision anyhow within 1 or 2 years. If you want to have a little bit more fun you can start a lively discussion on the difference between a vision, mission and a strategy, because most likely your manager will have them mixed up. You don’t need a degree in business administration to do this. However, don’t overdo this in large groups because it might make your manager feel stupid.

Right way

However the best way to react is to fully embrace your manager’s vision! First you express your enthusiasm: tell him his vision is very motivational to you. Tell him that he really should share his brilliant ideas with the world for example by writing a white-paper or a blogpost. Make sure that you do this in such a way that he will have to do all the work and won’t be able to delegate it to you. Also make sure that you don’t overdo it: telling him that he should get the peace nobel price for his ideas is probably a bit too much and might raise his suspicion.

After you have shared your enthusiasm you can now weave in your personal agenda. Here is where the results of step 3 come in: if one of the keywords for example is ‘thought leader’ than you can use this to explain that this cool conference in Hawaii on some state-of-the-art technology you want to go to is really helping to support his vision. If you feel self-confident you can also rephrase this as ‘with this practice I can help you to operationalize your vision so that as a group we can really meet our business goals.” Additional benefit: you can refer to all your support during your performance appraisal.

Final words: don’t take me, this blogpost, your manager or yourself too seriously 🙂

Have fun!

Looking back on my 2010 New Year’s resolution

December 31, 2010 at 3:29 pm | Posted in Ramblings | 2 Comments

End 2009 I came up with 8 quantifiable goals for this year. Now it’s time to look back on how well I did. Let’s first show the burn-down chart and then I will explain the results:

As you can see in this graph (the blue line) I got close to 75 % of my goals, with about 25 % left. These are the 8 goals I had defined:

  1. 400 LinkedIn contacts. I started with 370 contacts begin 2010 and currently I have 457 contacts. So I exceeded this goal easily. The main reason for this is that I had quite a lot of short consultancy jobs this year so I met many people.
  2. finish reading 50 books. Didn’t make this. I ended up with 29 books, mostly because I used public transport less than expected. When you get to drive 2.5 hours a day for an assignment it’s pretty hard to find any time to read. You can see this happen in the above chart around week 20.
  3. run my ‘usual route’ (about 10 km) 80 times. This means that I have to run almost twice a week. Which I didn’t make. The counter stopped at 59. On the plus side I started this year with running 10 km in 50 minutes but I ended up at close to 45 minutes.
  4. 150 followers on Twitter, coming from 64. I fully met this goal and currently have 164 followers.
  5. 3 publications or presentations. Fully met: I gave a presentation at Agile 2010 in Orlando, a presentation on Clojure for JFall 2010. And finally I published an article (first of a series of 3) about Clojure in Java Magazine.
  6. I promised two GIMP# releases. Unfortunately I only managed to release GIMP# 0.17.
  7. I wanted to push the number of visitors for this blog from 50 to 100. Again I partly succeeded. The average number of visitors this year was 71 a day. My blog on the evilness of fixed-price projects attracted almost 6000 visitors in a single day. My lesson learned is that I really have to blog more often to get this number up.
  8. And finally I had planned to learn 2 new programming languages. I ended up with only 1, but boy, what a wonderful language it is!

For 2011 I have a couple of new and ambitious goals in mind. In the mean time: Happy New Year to all my readers!

Fixed price projects? No, thank you!

November 18, 2010 at 9:23 pm | Posted in Programming, Ramblings | 18 Comments

In IT it is quite customary for a customer to ask several suppliers for a bid on a project. Often he wants a fixed-price bid, which means that functionality, quality and price are all fixed. More often than not there is also a deadline. The rationale behind this approach is that the customer wants to transfer the project risk to his suppliers. Of course this doesn’t work out in reality.

There are many other reasons to dislike this approach. For one, it puts the customer and supplier in an opposite position right from the start. This later on shows in struggles about bugs versus features, different interpretations of the requirements, high costs for even the tiniest change request, etc. To be short: I have never seen this work in the 20 years I have been involved in IT. At best you have a win-lose situation, most of the time it results in a lose-lose for both supplier and customer.

 

In this blog I will not go into the ethics of fixed-price contracts. Scott Ambler wrote a nice article about that in Dr. Dobbs back in 2007. Instead I will present the results of a simple statistical model. These results will show that right from the start a fixed-price project is set to fail.

This model is based on the following assumptions:

  1. Estimating is difficult. At the start of a project it is easy to be wrong as much as 50 %. Based on accurate requirements that don’t change (!) it is possible for trained estimators to come up with an estimate that is 20 % accurate at the most. And this is only when they can estimate many similar projects.
  2. The second assumption is that suppliers over- and underestimate around the real effort that is needed to finish the project. We have modeled this as a normal distribution.
  3. If there is more than 1 bid, the customer will select the lowest bid. This may sound short-sighted. And it actually is, but it is also reality.
  4. Supply and demand are balanced. This means that suppliers don’t have to offer a lower price when there isn’t enough demand. It also means that they can’t ask high prices for the same reason.
  5. All suppliers have the same productivity and hourly rate.

I created a Google docs spreadsheet which generates 500 test-runs with each 10 suppliers. Next I calculated the minimum for every test-run for 1 supplier, 2 supplier, etc. until 10 suppliers. Finally I averaged all these minimums to get a reliable number.

An example: the real amount of work was set by definition to 100. When selecting a standard deviation of 10, an average run of [100 95 92 90 89 99 87 86 85 84] is generated. This means that with 1 supplier on the average the bid will be 100 % of the real effort. With 2 suppliers, the chosen bid will already be 5 % too low, and so on.

The results for standard deviations ranging from 0 to 50 are shown in next graph:

What immediately becomes visible is how bad the situation actually is. Take a typical case where 5 suppliers compete for the same project. Combine this with a standard deviation of 35 (remember the mean is 100). In that case the bid that wins offers to do the project for 60! In other words, 40 % lower than the actual price. No wonder he will end up fighting with his customer after a couple of months.

In my next blog I will drop the assumption that demand and supply are balanced. I will show that an unbalance in favor of the suppliers will have a devastating effect. I will also show that suppliers hardly profit from the opposite situation.

Remember, if anyone asks you to do a fixed-price project: just say no 🙂

The end is nigh

June 26, 2008 at 9:33 pm | Posted in Ramblings | Leave a comment

Just recently is finished “Svartir Englar” by Ævar Örn Jósepsson (I read the Dutch version) although I was pretty bored after the first twenty pages. After finishing the book I realized that I should have stopped after those initial pages since this has just been a waste of my time. The question then came up how many books I was going to read about the end of my life.  In his book “Metamagical Themas” Douglas Hofstadter learns us that it is actually pretty straightforward to come up with answers to questions such as “how many books are there in all the libraries in the world”. In my case it is far more easy: I will probably live for another 40 years and I finish 1 book per week on the average. So I still have about 2000 books to go. Might be a bit more or a bit less, but for sure I’m not going to finish 10.000 books.

How much shelf space will those books take? Let’s suppose those books are 2 cm thick on the average. That makes a total of 40 meter shelf space I need. In my house I have a wall that is 5 meter long. If I can put 8 shelves against that wall it will be completely covered with books. So my whole life that I have in front of me only fills one single wall.

Maybe I should start selecting my books a bit more critical 😉

25 years of programming

March 8, 2008 at 11:01 am | Posted in Programming, Ramblings | 6 Comments

I started programming in 1983 on a Sharp PC-1251 with an amazing 3486 bytes RAM. It had a Basic interpreter and we had to use it for a Calculus course at the university.

Sharp PC-1251

So that’s 25 years ago. That made me suddenly wonder how much code in different programming languages I have written in all those years. A completely useless question of course, but fun nevertheless. I don’t have all the code available anymore so I have to estimate some numbers from memory. The numbers I present include comment and blank lines.

The list:

  1. C: 100.000
  2. C#: 70.000
  3. Java: 20.000
  4. C++: 20.000
  5. Pascal: 5.000
  6. PV~Wave: 5.000
  7. Basic: 2.000
  8. Matlab: 1.000
  9. Lisp/Scheme: 1.000
  10. Assembly: 1.000
  11. Fortran: 200
  12. Perl: 100
  13. Python: 20
  14. Boo: 20
  15. Nemerle: 20
  16. F#: 20
  17. Ruby: 10

This totals 225k lines of code in 25 years.In other words, about 10k LOC’s per year, or 30 lines per day. Other interesting questions that could be asked:

  • how much of this code is still in use
  • how much of this code is forever lost
  • how much of this code is still archived somewhere on a company network
  • how much code would this have been if it all had been written using language xyz
  • how many bugs did I introduce over the last 25 years 😉

GIMP# and Visual Basic.NET

February 8, 2007 at 12:41 pm | Posted in C#, GIMP, Ramblings | 6 Comments

About 10 years ago I had Fortran on my resume but I always felt a bit embarrassed about that. I didn’t really like the language, to put it very mildly. When people inquired about my Fortran knowledge I always mumbled something like `just the basics’ and tried to steer the conversation into another direction. There was this other language I had the same feelings about. It is called Visual Basic. Why? Mainly because I associate Basic with people educated in any topic but computer science. Often these people seem to be hired by software houses that don’t care about the quality of their employees, as long as they can make money out of them. And as long as there are customers that don’t really care about the quality of the software that is written, they get away with it. Mind you, I’m not saying that you need a degree in computer science to become a good programmer. One of the best programmers I’ve ever met had an unfinished degree in sociology. Continue Reading GIMP# and Visual Basic.NET…

URL blocking

February 1, 2007 at 11:28 am | Posted in Ramblings | 8 Comments

Sometimes you need to download a useful program from the internet, say Google Talk, and install it on your PC at work. And suddenly you are confronted with company policies about certain url’s that are blocked. I very well understand that you shouldn’t visit the Playboy site during working hours, but sometimes these url filters really become annoying. Of course I could have downloaded Google Talk from a different site that wasn’t filtered, but there is another straightforward approach: Continue Reading URL blocking…

Kids and permanent markers…

January 15, 2007 at 10:20 am | Posted in Ramblings | 5 Comments

I’m not happy at all. My 3 yo daughter has scribbled on my tft screen with a permanent cd/dvd marker. Hopefully when I’m back from work I can remove it. I know quite a few people read my blog, so if there are any useful tips to remove the ink from my screen, I would be very grateful.

Edit: thanks everyone for the tips! In the end the marker pen was quite easily removed by alcohol-free baby wipes. Now we only need some educational advice to prevent these kind of things to happen in the future 😉

Next Page »

Blog at WordPress.com.
Entries and comments feeds.