Skip to content →

Category: Programming

His nightmares with engineering estimates

Hiten Shah wrote an article titled “My nightmares with engineering estimates” where he blames everything on estimates. Now I get that he is using a little hyperbole to gather interest on his next post which is going to reveal The One True And Righteous Way™ but I need to get a few things off my chest.

Before we get into this I do speak from experience. I’ve been building software for 30 years in all sorts of roles and team sizes. I’ve been thinking about this estimating stuff for a long time as well. See my 2008 post on estimating.

No Estimates

Hiten describes how they got started with KISSmetrics without creating estimates and how they got to a point where it was going to take 90 days to make the system performant for customer demand.

We were screwed. All because of no estimates.

I have to call BS here. They got to this point because they traded speed to market for quality (by his own admission) and didn’t think about the non-functional requirements (such as performance). Not many of us have the problem of too many customers. Sounds like a great problem to have.

Had we estimated during our 30-day buildout instead of after, things could have turned out really differently. The business could have grown faster and been bigger today.

I have a hard time believing this as well. Having estimates doesn’t mean you have a high quality product that meets all the customer’s needs. I’ve worked on many systems over the years that were estimated at the start of the project and it still didn’t meet the overall goal of satisfying the customers or stakeholders.

Hiten lists 3 no estimates pitfalls:

  • No Tradeoffs Made
  • Too Much Time Communicating
  • Tasks Aren’t Broken Up

Part of product management’s job is to evaluate the opportunity vs. the cost which means making trade offs. Estimates are one input into that decision making process. I would claim it is a second level factor not the primary driver as he appears to be asserting.

Comments closed

Windows Services Running as Local System and Environment Variables

As sometimes happens I installed an application on a Windows server and several days later another program stopped working.

I did my research and was able to determine that the installer for this new program had altered my PATH variable such that a specific DLL was now loading from the wrong place with an incompatible version causing the old program to stop working. Fix the path – everything works. All in a day’s work.

Except…

While I was able to successfully run the program from the command prompt the actual use was different. In fact this program was called from an Apache module that was shelling out to it. In this context the program was still failing. After checking to see if there was some Apache setting that was controlling the PATH variable and finding out that you can’t actually change environment variables in Apache on Windows I was able to confirm that the PATH value in the Apache context was different than the system PATH.

Now I knew that if you change the system PATH you need to close and reopen your command windows to reinitialize the environment variables so I assumed that restarting the Apache service would cause the same thing to happen. Not so much.

As it turns out my Apache service was running as Local System and evidently all the environment variables are set at startup time. That meant I needed to reboot the server. Unfortunately I can’t do that until our maintenance window several days from now and people need the function to work today.
Luckily there were several layers of code between Apache and the actual program that was failing. One layer was a C# application, so making use of the Environment.SetEnvironmentVariable("PATH", newPath, EnvironmentVariableTarget.Process) and then shelling out I was able to temporarily change the PATH to something that will work.

Now I just need to remember I did this 2 years from now when something else changes…

Comments closed