Puzzle 2

A really difficult one this time!
The code defines a Logger class and a macro that gets the static instance of the logger and passes the text to its Log method with the log level TRACE_LEVEL.

Unfortunately the code does not compile due to a syntax error.
You can copy the code and try it with your favorite C or C++ compiler.
I get an error that l is not defined, and interestingly there is an 'else
without an if' !

#include <stdio.h>


// define a class for logging
// provides static instance via Instance method
class Logger
{
private:
 static Logger* sInstance;


public:
 Logger() {};
 ~Logger() {};


 static Logger* Instance()
 {
  if (!sInstance)
   sInstance = new Logger();
  return sInstance;
 }




 void Log(int level, const char* text)
 {
  printf(text);
 }
};


#define TRACE_LEVEL 5


#define TRACE(text)  Logger* l = Logger::Instance();  l->Log(TRACE_LEVEL, text);




Logger* Logger::sInstance = 0; //static initialisation




int main(int argc, char* argv[])
{
 if (argc == 1)
  TRACE("to few parameters");
 

 else
  TRACE("at least one parameter");
 



 //do something sensible
 return 0;
}

A little hint: there's nothing wrong with the Logger class or the macros, the bug is within the main function!

Happy puzzling!

Agile Checklist Part3
In a recent project we used an interesting mixed approach that worked quite well.

Upfront we estimated roughly the effort required for all the features known at that time based on past experience, and used this to schedule the iterations and to make a first attempt to assign features to iterations. Thus we could satisfy project management with a date for when overall work would be completed and also knew what resources we needed.

We made further refinements and adjustments at the beginning of each iteration taking into account progress and experience made in previous iterations and new requirements, but tried to stick to the dates for the planned iterations (i.e. time-boxed approach). Instead minor features or nice to have requirements would be dropped if necessary.

One lesson we learned was the importance of getting all team members up to speed (i.e. familiar with the approach, tools, domain etc) in order to start into an interation without misunderstandings and misconceptions. Initially we had not got all the resources planned and phasing in people as you go made continuous integration rather difficult.