Parkinson's law says that all work expands to fill all time available for its completion.

This has be proven statistically to be very true, so nobody can doubt it. However some of the consequences of this law often go unnoticed as the law's wording and meaning gets twisted and turned over to suit one's needs.

We all know that project estimation is akin to solving NP-complete problems. You only know the exact answer after you have finished all the work. There are many shortcuts around the problem, but the exact answer requires you do all the work, like in an NP-complete problem the exact answer can be found only by examining ALL combinations.

Now suppose you have a project to do, that *really* needs 5 calendar months to complete, working at the best of your abilities, no interruptions, etc. What Parkinson's law says is that if your manager gives you 6 months to complete it, then your work will 'somehow' expand and you will do 6 months instead of 5, still working at the best of your abilities. You might add a few extras here and there, some more performance testing, whatever, it doesn't matter what. The work will expand to 6 calendar months.

From your point of view, this extra month adds significant value to the end result. However from your manager's point of view it adds more COST than value. And your manager is trying to get everything done at both the absolutely minimum quality level acceptable by the client and at the absolutely minimum cost so that she can maximize profits for the company (and her fat bonus too).

But there are costs and costs. One cost your manager cares about is the actual grand total, but then there is another cost she cares about: unpaid overtime, or to put it diplomatically 'human capital utilization'.

The grand thinking of high-level managers is that when developers are working normal hours the company is losing money. It is clearly losing money because according to Parkinson's law it is clear that the developers are doing less actual work, expanding it to fill their day, up to 'normal working hours'.

If developers could be pushed to work 10 hours instead of 8 every day, then even though Parkinson's law still applies, they will get more work done every day. This means the company improves it's human capital utilization and thus saves costs.

Now let's get back to the project level. No one knows the time required, so the manager, the client and the development team negotiate and agree to an estimate. Let's say 12 months.

After 12 months the project is ready, up and running, and the development team is celebrating. The manager might be celebrating too, but at the back of her head one thing is clear. She overestimated the project and the project expanded to 12 months according to Parkinson's law. If it could be done in 12 months then it could easily be done in 11 months or even 10 months.

The manager clearly FAILED to minimize costs. The manager will now be perceived by her peers (and her boss) as being SOFT because she clearly didn't push the team hard enough.

The project succeeded but the manager FAILED!

Now comes the nice part... Suppose that a time traveler from the near future visited the manager at the negotiation phase and told her "You can do it in 11 months". The manager fancied this guess and in fact the project was successfully completed in 11 months. On Time again... Failure again... for our poor manager... If it was done in 11 months then it can clearly be done in 10, maybe even 9 months...

So you can now see the great corollary to Parkinson's law, which we could call "The Law of Late Projects":

Management will always try to make a project late.

This is usually done by choosing a very optimistic deadline or, if the project seems to run smoothly, by introducing more work, changing the requirements, changing key people, replacing experienced team members with rookies, etc. You name it. As soon as a project appears to be on track the manager starts to panic; She is losing money for the company; She appears soft; She must ACT.

Have Fun!
Dimitris Staikos

Hi

I always had a strange fascination about batch files in Windows. I like automation, but for some reason I don't like using an elephant gun (Perl, Powershell) to shoot a mosquito. Plus I like the automation stuff to work on any PC, without having to install anything new. The Windows shell commands look totally crippled, but there is more to it than meets the eye.

ping 127.0.0.1 -n 10 -w 1000

-n determines the number of pings, -w the timeout in msec for the pings.

However -w will determine the timeout only when there is no response to the ping. If there is a response, then the ping command does not waste time and move to the next repetition.
So clearly this is not an accurate way to create a delay and you can test this with a trivial batch file as I will explain below.

What the batch file does is not that important (you can write a delay command in Win32 in about 3 lines of code), but the reason for this post is mainly to showcase several batch file techniques.

Specifically:

• How to extract a substring from the value of an environment variable.
• How to do math in a batch file.
• How to invoke a subroutine inside a batch file

Here is how these tricks work:

• %envvar:~X,Y% retrieves a substring of length Y from %envvar% starting from position X (zero-based).
• "set /A" can do integer math in the shell.
  For example if you type "set /A 201*3" the shell will output 603. A quick integer replacement for your beloved calc.exe.
  "set /A envvar=math_expression" will do the math and store the result in the specified environment variable. Don't forget that environment variables appearing in the expression have to be included inside %%.
• A batch file "subroutine" starts with a label declaration and "returns" with a GOTO :EOF statement. You call the subroutine by typing CALL :MYROUTINE 
  Executing GOTO :EOF in the "main" execution flow is just a cool way to exit the batch file.

Given the above goodies you can easily implement for/while loops in a batch file.

You should keep in mind one particularly nasty habit of the windows shell that has to do with environment variable expansion. The shell will expand an environment variable when it READS the command, NOT when it executes it.

This means that in the following block:

set VAR=before
if "%VAR%" == "before" (
  set VAR=after
  if "%VAR%" == "after" @echo Sorry, but echo will not be executed
)

the highlighted comparison will FAIL, because the whole if-block is read in one move and expanded before it gets executed, so the comparison will actually look like if "before" == "after".

You can start CMD.EXE with the /V switch to enable delayed expansion, but I didn't want my DELAY batch file to depend on switches.

So, in my batch file I will also use PING in order to introduce a small delay and not go into a tight loop.

Here is what the code looks like:

@echo off
setlocal
if "%1" == "" goto :EOF

SET lastrecordedtime=%time:~6,2%%time:~9,2%
SET elapsedtime=0

:LOOP
rem Generate a small delay so we don't busy LOOP
ping 127.10.20.30 -n 1 >nul

rem Pickup the current time
SET currenttime=%time:~6,2%%time:~9,2%

rem This happens sometimes and the calculations go wrong
if "%currenttime%" EQU "%lastrecordedtime%" goto :LOOP

rem Use GOTOs so as not to have trouble with delayed environment expansion
rem Since the strings are zero-prefixed the string comparisons are equivalent to numeric comparisons
if "%currenttime%" GTR "%lastrecordedtime%" (
CALL :TIMEINCREASED
) ELSE (
CALL :TIMEWRAPPED
)

rem Elapsed time might be greater than the requested so remaining time becomes negative
SET /a remainingtime=%1*100 - %elapsedtime%
if "%remainingtime%" == "0" goto :EOF
if "%remainingtime:~0,1%" == "-" goto :EOF

CALL :UNPATCHOCTAL

SET lastrecordedtime=%currenttime%
goto LOOP

:TIMEINCREASED
CALL :PATCHOCTAL
SET /a elapsedtime=%elapsedtime% + %currenttime% - %lastrecordedtime%
goto :EOF

:TIMEWRAPPED
CALL :PATCHOCTAL
SET /a elapsedtime=%elapsedtime% + %currenttime% + 6000 - %lastrecordedtime%
goto :EOF

:PATCHOCTAL
rem Remove leading zero so as to avoid feeding invalid octals to set /a
rem There might be as much as three "disturbing" zeros.
set saved_currenttime=%currenttime%
set saved_lastrecordedtime=%lastrecordedtime%
if "%currenttime:~0,1%" == "0" set currenttime=%currenttime:~1,3%
if "%currenttime:~0,1%" == "0" set currenttime=%currenttime:~1,3%
if "%currenttime:~0,1%" == "0" set currenttime=%currenttime:~1,3%
if "%lastrecordedtime:~0,1%" == "0" set lastrecordedtime=%lastrecordedtime:~1,3%
if "%lastrecordedtime:~0,1%" == "0" set lastrecordedtime=%lastrecordedtime:~1,3%
if "%lastrecordedtime:~0,1%" == "0" set lastrecordedtime=%lastrecordedtime:~1,3%
goto :EOF

:UNPATCHOCTAL
rem Return the original string values so that string comparisons work ok
set currenttime=%saved_currenttime%
set lastrecordedtime=%saved_lastrecordedtime%
goto :EOF

I extracted both the seconds value and the hundreds of a second value, because my initial version would not be very accurate for small delay values (1-5 sec). Since both strings are zero prefixed I can directly concatenate them to generate the effect of (sec*100 + hundreds_of_sec).
The batch file takes the number of seconds as a parameter, but it is trivial to change it so that it accepts the hundreds of a second.

Unfortunately this BATCH file takes a little CPU time (3-5% on my PC) so it might not be convenient for some purposes. Maybe someone will come up with a better way to introduced a guaranteed-small delay, instead of pinging the local host.

Oh, and in case you didn't know, the whole 127.x.x.x range is considered a loopback address, so you don't have to type 127.0.0.1 every time. Type something else and look cool to your astounded friends :-P

Finally I should say that I tested the batch file (and it works of course) on Vista and XP.

If you want to test the accuracy of the batch file, then type another batch file as shown below and check things out for yourself:

@echo off
echo Delaying for %1 seconds
echo %time:~6,2%:%time:~9,2%
call delay.bat %1
echo %time:~6,2%:%time:~9,2%

Have Fun!
Dimitris Staikos

QUIZ
You can tell that something is wrong when:

1. Something that usually takes half an hour is not finished after 5 hours OR
2. Yet another piece of technology is functioning in unintended ways.

A couple of days ago I read a tip about 4 mistakes that can kill VM performance.
#4 was: The default power option of Windows Server 2008 upon installation is set to "Balanced".
Sure as hell it was set to Balanced, so I corrected that one.
But tonight something else happened that was related to power management.
A backup to network folder was taking far too long.
How nice... One more problem to solve...
I check the network utilization and see that it was 100%.
Now that's a bit unusual... Just a bit...
I take a better look and what do I see?
Link Speed 10Mbps!!!!!
Excuse me??? Where did that come from?
To cut a long story short, the Intel network adapters came with a default setting that made them reduce the link speed if the machine is idle. The machine was certainly not idle, but still the link speed was reduced... go figure.
I deactivated the setting and got back my 1Gbps with a healthy 30% utilization and my backup was finished in the next 10 minutes.

That's why I say too much power management will kill you...

Have Fun!
Dimitris Staikos