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!"

Side-effects and exceptions have to be completely unexpected to be real fun...

Developers of software for medical applications sometimes show a good sense of humor as the following lines in a highly mission critical Session-Manager show:

bool IsParticipantAttachable(Doctor doc)
{
  if (!Session.Attached(doc))
  {
    Session.Attach(doc); // attach the doctor to the session
    return true;
  }
  else
    throw new IllegalSessionStateException("doctor not attachable");
  return false;
}

... and now guess what happened to the piece of code that tried to ask the system twice, if a doctor could be attached to a session or not...

if - else is really a great thing! You can't use it too much!

Senior developers sometimes show their ablilties by writing extremely clever methods. This provides their junior-fellows with a good source for education and real admiration:

bool CheckNumberOfElements(double[] container, int maxLength)
{
    if (container.Length > maxLength)
        return true;
    else
    {
        if (container.Length < maxLength)
            return false;
        else
        {
            if (container.Length == maxLength)
                return false;
            else
            {
                if (container.Length != maxLength)
                    return true;
            }
        }
    }
}

Better Performance Using Optimized Exception Handling

Speed up your application by removing exception handling in release builds. 

try
{
  //some database access code
}
catch (Exception ex)
{
#if DEBUG
  // Never happens. Hit the debugger if it does.
  System.Diagnostics.Debugger.Break();
#endif
}

Meeting Deadlines (Part 2)

Any project deadline can be met by introducing a "the developers just have to work more focused" factor (F).

For example, given the following:

• A 10 month project with 3 month (D) to go,
• 500 developer work hours (A) available each month,
• a remaining effort (R) of 3000 hours,
• a burn down chart showing that the remaining effort is reduced by 250 hours each month (V).

Based on this the following calculation shows that the project will not meet its deadline.

Dv = R/V = 3000/250 = 12 month > D

But as a project manager you should never trust in burn down charts. Instead always use the amount of developer time assigned to the project for your calculations. This leads to the following calculation:

Da = R/A = 3000/500 = 6 month > D

Still the deadline is not met. But there is hope. Tell your developers to "work more focused" and adjust that factor to what ever you need to meet your deadline. In our example:

Df = R/(A*F) = 3000/(500*2) = 3 month = D

As you can see after telling your developers to work only two times more focused (a reasonably small number) the project is right on schedule.  

Meeting Deadlines (Part 1)

As a project manager you can easily fix deadline problems  by creating an expressive user story. Here is an example.

As a user I want (insert what ever you need) to be implemented before (insert any date).

Iteration plans, release schedules and other disturbing factors of project management can be ignored when applying this method.

Temporary Variables

An excellent example of how to use temporary variables:

bool add = false;

// .. some lines of code 
if (hasPrivilege(Update)) {
  add = true;
}

if (add) {
  Add(Share);
  Add(Cover);
  Add(Locations);
  Add(Count);
  Add(Source);
  Add(Comment);
}