- Details
Thinking about Poisson statistics I was wondering how much use a clock would be that would count the seconds with counting statistics or Poisson statistics. That is: it has the irregularity of radio-active decay. Some people put their watch a few minutes ahead of the true time to make sure that they are never too late, but the problem is that they can start counting on that after a while. A true random clock might be unreliable enough that you would need to always stay carefully ahead….
Read more: Can a clock with Poisson counting statistics replace your watch?
- Details
Computer infrastructure used in universities is not part of a market, let alone of a "transparent market" in which everyone has a clear view on what alternatives exist and what their relative merits and costs are.
Nobody in a university research group finds it strange to pay for pens and paper.
Nobody in a research group finds it strange to pay for state-of-the art lab equipment.
But very often computer services have been offered for free. Like water, and electricity, they have been discounted into general costs of running the university.
This situation is unsustainable in a world in which life-science research becomes driven by big data. And it also becomes unsustainable in a world where large storage and computer infrastructure suitable for routine jobs can be rented commercially.
The sustainable way to the future is to properly budget for data handling and storage. Budgeting for computing needs means people are required to balance cost and value, like with every other aspect of a research project.
- Details
At the RAMIRI training (Realising and Managing International Research Infrastructure) I followed in Trieste this week, one sentence particularly resonated with me. It was by Kimo Koski (CSC Finland) who was remarking that it takes effort to keep an organization customer focused as it grows.
Starting at about 100 people an organization can keep it self fully busy without ever serving a customer.
While I was working for Bruker AXS, our Sales director Paul Ulrich Pennartz used to say something related sometimes when he was in a cynical mood:
Without those pesky customers we would finally be able to concentrate on our work.
If you've ever wondered why small companies are more responsive than large ones, I think these two people summarize the cause quite well.
(Note: both quotes were reproduced in essence, this is not literally what they said)
- Details
When more than one task must be completed, it is always better to do one before the other. I discussed that earlier in the post Parallel processing in a project team.
An individual customer with a new question could think that it is even quicker if you fit his project in between. We have to make them aware that if we allow interruptions of any kind in an agile sprint, nothing will ever be completely done. What can we tell them? There will be other people with new requests while we are working on your task.... should we honor their requests to interrupt our work too?
They should understand: agile sprints are not interrupted. They are either completed, or canceled.
Image from Flickr by brittgow
- Details
Chemistry as a noun has two completely distinct meanings in every day life:
- A good social relationship:
"It was visible that there was chemistry between those two people"
- Something related to a compound that is supposedly bad for people or the environment. "Chemical" is often used as synomymous with poisonous:
"A chemical leaked from the container into the sea, endangering the fish"
How come these two meanings of the same word have such extremely different connotations? After all, the scientific word chemistry represents any kind of reaction between two compounds and does not have any positive nor negative meaning in itself. Water is a chemical. Life is chemistry.
As a chemist, I wish I could change the negative connotation of molecular chemistry in the news. But if I really do not succeed, maybe I can influence the social meaning of chemistry to make things consistent:
"There was chemistry between those two! When they first met, she tried to poison him. As soon as he recovered he exploded in anger."
Somehow I feel this would not be as satisfying.
[image credit: Nic McPhee on flickr]
- Details
How important is it to prioritize?
Lets assume we have 4 ideal projects A, B, C, D, and an ideal project team. Each of these projects takes 3 months to complete. They are all equally important. We work on them in parallel. When will the projects be ready? Project A will be ready after 12 months. Project B will be ready in 12 months. Project C will be ready in 12 months. And Project D will be ready in 12 months.
Now, what happens when we prioritize and work on the projects in alphabetical order? When will the projects be ready now? Project A will be ready after 3 months. Project B will be ready after 6 months. Project C will be ready after 9 months. And project D will be ready after 12 months. Everyone except the customer of project D will be better off! Fantastic, isn't it?
Unfortunately, this is not the perception of your customers. Each of them sees a 3 month project and wants it finished in 3 months. The customer in project D does not want to hear "we will start on your project in 9 months". All too often, priorities therefore change. Every month, at a project team review, you will be forced to reprioritize. What is the effect? Project A will be ready after 9 months. Project B will be ready after 10 months. Project C will be ready after 11 months. Project D will be ready after 12 months.
What a waste. Don't fall into this trap. Prioritize, and stick with the choice.
[Image credit: goldstardeputy]
- Details
A software shop like ours should deliver what customers want... but it may be difficult, because they often do not ask what they want. This is because customers think they know what causes a problem and they think they know the best way to solve it. They then formulate their request in an attempt to help us.
An example: I once had customers asking me whether I could change my software so that it would round the numbers that it would use to position a robot. It would have been easy to satisfy that request, but I decided to ask why? This proved to be a good idea. I found out the customers were copying the numbers into some other software package. Rather than doing what the customers asked, I ended up writing a direct interface to the other software. This made life of the users much easier yet, without limiting the possibilities of the robot.
We can not blame customers for not knowing what is easy and what is difficult to implement. Both ways. They can think that something is very easy, when in fact it is fundamentally very hard. But it also happens that they do not dare to ask a question they think is hard, when in fact it would be very easy.
If you want to make the best possible software, you need to keep asking "why" until your user's report has been changed to "If I do A, I get B. But instead of B I would like to see C (because I need D)". This will help you to decide how customer satisfaction can be maximized. The maximum may be much higher than your customers expect.
- Details
One of the first stages in the development of a new tool (software or hardware) is a functional specification. The functional specification matures in discussions between the developers (department of R&D) and the customer representatives (often the departments of marketing and sales).
Of course a functional specification is useful: it is very hard to develop something new without an idea of how the new tool will be used and what it will be compared with. However, defining a functional specification can also be taken too far. In some organizations, the functional specifications are spelled out in the tiniest details. At the end of a long formal procedure, the book of specifications is signed like a contract between marketing and development. The development can only be started when the list of signatures is complete and will be performed in splendid isolation from the world of potential users. Why do organizations do specifications this way? It is often an attempt to separate the responsibilities of the departments, so that if anything fails the appropriate party can be blamed. If the final product does not meet the functional specifications, this can be blamed on the developers. And if the product does not succeed even though it meets all the functional specifications, this will be blamed on marketing.
I have a serious problem with this approach: using this procedure, how can one ensure that the product will be useful? After two years without interaction, development may produce exactly what marketing asked for (making all deadlines and within budget), but the market has changed and does no longer need the designed product. Or technology has changed, and better specifications would have been within reach and are offered by the competition. Or maybe marketing truly made a mistake, and asked for something the world is not waiting for. In these cases, clearly the development department can not be blamed! But if you develop an obsolete product this way, where does that leave the organization as a whole? And if this is not the best solution for the organization as a whole, will it be good for the development department? Even though everyone did exactly what was expected, people may be laid off because development costs can not be recovered.
The solution is, as often, to keep a middle road. Using e.g. Agile or LEAN development methods, developers can stay in constant communication with marketing. Iterative and modular design procedures can be used to verify that the new tool does what it should, without relying on the capacity of people to describe specifications in words beforehand. And because the communication with the market is not lost during the development process, the tool will have a significantly higher chance of actually being useful at the moment of introduction.
Image (by QuiteLucid on Flickr): "a camel is a racing horse designed by a committee".
- Details
After every radical change in an organization, there is a need for a phase of quiet thoughtful improvements. Expecting miracles from huge corporate reorganizations is a fallacy that leads to reorganization upon reorganization potentially resulting in complete destruction of the organization.
Have you ever played a game of Pac-man? It is a simple game where you control a little eater eating dots on the screen, while ghosts are chasing you. The game is an excellent mirror of business life in a changing environment:
- In Pac-man, you are trying to improve your health at every step by eating a dot and staying out of the way of the ghosts.
- In business life, you are making small changes to your products and procedures to sell more and stay out of the way of your competitors.
There is a further analogy:
- In Pac-man, sometimes things get stuck. Ghosts are closing in from all sides, and there is no escape. At such a point, you can use the teleport: a panic key that takes you to a random spot in the scene in an instant.
- In business life, sometimes things get stuck. Competitors are closing in and it seems there is no way out. At such a point the CEO will call (often quickly without consulting all those that are involved) for a radical reorganization.
In business there is an important lesson we can learn from the teleport feature in Pac-man: A teleport is far from a guaranteed save! It can bring you into a very dangerous situation. The goal of the teleport is not an immediate improvement in the flow of the game, it is to escape from a hopelessly stuck situation, from impending disaster. Directly after a teleport, you have to act and make steps to regain control. Similarly, in business a radical reorganization will rarely take you to a better situation immediately. A reorganization is meant to shake up the bowl and escape from a hopelessly stuck situation (often invisible to many of the employees). After the relatively thoughtless jump that has to be executed quickly to avoid an immediate game over, the organization will need to go into a thoughtful phase in which small improvements are made to optimize the situation.
If you realize that a reorganization has not brought you immediate gains, try to refrain from making further reorganizations. Instead, look for opportunities for small changes, and give it some time.