Deadline? What for?

The scenario:

• A planned project budget of some 25 million Euros


• A consortium of 20+ industrial partners (including all the really big global players in this area


• A project-discussion time of more than 6 months before the meeting described here


• 5 workdays until the final deadline for submitting the project proposal - no possibility of a late handin


• No coordinating partner yet


• Not even a very simple draft or outline of a proposal yet

Excerpt 1 of the consortium meeting: Trying to find a coordinating partner

... we have to agree on the coordinating partner, so please, who is willing to do it?

Why should we have a coordinating partner?

Because this is mandatory!

Are you sure?

Yes!

Sorry, we shouldn't waste our time on that, let's discuss it via email, we don't have to find the coordinator today. Let's just write a name into the proposal and then we'll see. We have more important things to discuss today...

Excerpt 2 of the consortium meeting: Trying to agree on a deadline

... we have 5 days left until we must submit our proposal - so all the partners have to describe their workpackages and send it to the coordinator, who will then compile the proposal

But we don't have a coordinator

Ok, that's right - so I'll coordinate this proposal compilation myself. Please send me your descriptions. And I would say, the deadline is in 2 days

Deadline? I don't think, we should have a deadline. We all do our best and when we're done, we'll send you the results

But when? Keep in mind that there's much work to do to make this proposal look good!

No, I'm against a deadline, what about the rest?

... nobody else said anything ...

Well, ok, then we obviously agree that we don't have a deadline. We'll send you our descriptions as soon as we have finished them

What do you think happened to the proposal? :-)

Why would you use lock if you can take a bool...?

Some developers have perfect in-depth knowledge about multithreading and synchronization as the following piece of C#-code shows:


while(dangerous)
;
dangerous = true;

// operations in critical section here...

dangerous = false;


... as you can see, the people who invented lock(...) just think way too complicated - in reality it's much easier! You only have to know that one of the very important properties of bool variables is that several lines of code that use the same variable are compiled down to a single atomic operation :-)
Ah - and I forgot to mention the other important property: in case of an exception it is guaranteed that all bools are automatically set to false during stack unrolling... :-)

When In Doubt, Do Nothing

If you are unsure about what you are doing it is better to do nothing then to do something wrong. Express this in your code in order to communicate your doubt clearly to your colleagues.


Like in this example:

void OnItemClick(object sender, EventArgs e)
{
  string selected;
  try
  {
    selected = Parse(e.Item.Value);
  }
  catch (Exception ex)
  {
    Log("Clicked Item not found", ex);
    throw;
   }

  switch (selected)
  {
    default:
    break; 
  }
}

It's so easy to define delimiters...

Spotlight on a day in the lives of two developers - one on the server-side, the other on the client-side...


Requirement to be fulfilled: Two files have to be transfered over a TCP-connection. Both are zip-files and the transfer is a plain raw-data transfer.

Proposal of the client-side developer: "Just pack the info about the file-lengths into the header"

Answer of the server-side developer: "Are you crazy? Why should I do that? It's much better to just define a delimiter that is sent after the first file. Then you immediately know where the second file starts"

Question of the client-side developer: "But how would you define a delimiter? We work with raw data-transfer, so it isn't possible to define one that is guaranteed not to appear in the stream as real data"

Answer of the server-side developer: "Hah - just take qayxswedcvfrtgb - this one for sure does not appear in any zip-file"

... as a proof that the server-side developer was just plain wrong - not only theoretically but also practically - the client-side developer just took a bunch of the zip-files to be transfered and ran a grep for this string over them - guess what happened... sure there were several appearances of this "delimiter"...

... with this result in hands the client-developer tried to convince the server-developer again that the "delimiter"-solution is plain nonsense...

... and got the answer: "ok, this string seems to have been too short, we take qayxswedcvfrtgbnhzujm,kiol.- instead, then it works"

... needless to say what happened to the data transfer...

Almighty Constructor...

A quick look at the starting point of a flight-simulator (written in C++) showed the following - and I saw this simulator running before analyzing the code, so I knew that this main(...) must do something...:

int main(int argc, char* argv[])
{
  FSim sim;
}

Huh?

For those of you with too little imagination - here's the explanation:
The constructor of the class FSim started and ran the whole simulator by constructing other objects, which themselves did the same. So the whole program was an incredibly long chain of constructors and quitting the program just let the innermost constructor run to completion, which in turn let all the others run to completion, which resulted in a constructed variable sim, which ended the program.

Only the best of all developers are able to write such extremely clever solutions!

Senior managers and strategies...

Excerpt of the yearly strategy-meeting of a well-known research-institution:

Senior manager: "Let's sum up, how last year's strategy worked out - could you please give some short comments on that?"

Researcher: "Sorry, but last year we agreed on nailing our strategy down, but we never did. Additionally we tried to get our feet on the ground in 2 areas of research, which didn't work out and we tried to fix our resource-problem with the classes, which also was not solved."

Senior manager: "Please... don't think in problems! Think in solutions!"

(... short discussion with no result ...)

Senior manager: "Ok, fine! Good to hear that our last year's strategy was a real success - I think we just keep the same strategy for the next year, it seems to be perfect! Let's discuss the next topic."

Managers and signals...

Short excerpt of a meeting on problems with a piece of server software that just shipped a few days before the meeting:

Developer: "Our biggest problem is the signal 11 problem - we really must invest a lot of time to clean-up our code, otherwise the whole thing will be a disaster soon..."

Technical director: "You always want time for solutions that are not needed! In fact it's easy to fix that problem: write a signal handler!"

Developer: "But of course we've already got a signal handler... but this just catches the signal, it doesn't cure anything...???"

Technical director: "Why not? If you catch it, you can ignore it and nobody will notice!"