A Day in the Life

A day in my life. Thoughts on leadership, management, startups, technology, software, concurrent development, etc... Basically the stuff I think about from 10am to 6pm.

10/25/2005

Grid Computing: What I like about GOOP

GOOP is the acronym that Dan has used to talk about Grid Object Oriented Programming which is what the Digipede SDK supports. Soon I’ll be going out and spreading the word about Digipede and to prepare for that I’ve been researching the history of grid computing and the Globus project in particular. Globus shares information between compute nodes via protocols. This works great for heterogeneous systems and for the problems Globus is trying to solve. Globus is trying to do for resource sharing what the Internet has done for communication. And here is the big problem. The Internet was the highway, but the World Wide Web was the vehicle. It is the Internet that is protocol based and the Web which is API based. The Internet took off only when it became accessible via the APIs. Digipede has provided an object-oriented API for grid computing.

Now back to GOOP. Think about the number of programmers trained in object-oriented programming verses the number of programmers trained in network protocol development. The fact that programmers can use a well documented and understood methodology will allow them to grid-enable their applications quickly. The Digipede Framework SDK’s API works the way that programmers already work. This is important. Your programmers will be able to grid-enable existing applications faster because GOOP follows the same methodology.

Yes, I am very partial to the Digipede solution and it’s not because it’s my job. I really think this is a powerful paradigm shift that can have a fast and immediate positive affect on a company’s bottom line. The fact that you don’t have to buy servers to accommodate peek times but can roll that work over to existing desktops is an incredible cost saver. (We call this scaling-out.) The fact that the API is simple and follows OOP methodology means that you don’t have to hire expensive consultants or totally rewrite your applications. The fact that once your applications have been grid-enabled, computationally intensive processing times are reduced from hours to minutes. (Can you say increased productivity?)

Yea...I love GOOP.

Labels:

10/24/2005

Company Leadership: Make Sure the Shoe Fits

Once upon a time there was a self-funded startup. The startup became the leader in the Windows and OS/2 code generation market space with a nice big contract with IBM and many happy software development customers. One day the CEO decided that he wanted to take the company to the next level. So he started looking around for “experienced” executives that could help him. He got a President from Dun and Bradstreet, a VP of Engineering from IBM, and a new CFO (he is a mystery character because I don’t remember where he came from). The new big company gurus came in and started making changes. “Be gone telesales! We are now using deep carpet sales.” So the sales cycle went from minutes to months. Gone was the predictable revenue stream. Individual sales, the bread and butter sales, were beneath the startup and were no longer pursued. The executives from the larger companies shifted the sales force into Enterprise Sales, which is what they understood. The VP of Engineering, fresh from IBM, declared that company’s products would not support pointers. (We generated C and latter C++ code.) In about a year the little startup went from a couple million in the bank to a couple million in debt, several rounds of layoffs, and finally bankruptcy where the remaining assets were sold.

The moral of my story is that if you are going to hire someone for a top level position who does not have experience in startups, you are taking a huge risk. Either mentor him until he gets up to speed or let him learn at someone else’s expense. Time and time again I’ve seen folks hired into small companies from large companies and their approach to business is out of step with the needs of the small company. Unless they have an experienced executive above them who can mentor them through the mental changes, they are going to have a hard time, possibly fail, and most definitely cost money. So what are some of the differences between a large company and a small company?

Large companySmall company
Lots of money and resources.Little money and limited resources.
Time for planningLimited time if any.
Rigid organizational structure. Fluid organizational structure.
Clearly defined processes.Processes?
Well established relationships with vendors.Nope.
Long-term clients.Nope.
BrandingNope.

* These are generalizations

Small companies and startups NEED leaders who understand how to use limited resources, to prioritize tasks, to pursue goals; ultimately to be creative problem solvers who WILL find a way. If you are interviewing for executives remember to look for people with the right experience not just big name experience. Make sure that you find folks who are not afraid to learn and who are willing to provide flexible contributions. Someone who can say, “That’s not my job” ... will not be there when you need him.

10/19/2005

Software: C# Code to Walk an Excel CommandBar

I took Guogiang Wu’s code I found in this post: Programming Office Commandbars - get the ID of a CommandBarControl and ported it to C#. I also made a few changes.

1. I dump the information to a temporary file.
2. I use indenting to indicate levels. It’s easier for me to understand that way.

public void DumpBars() {

   StreamWriter stOutput = File.CreateText("\\temp\\CommandBar.txt");
   int iCmdCount = mApplicationObject.CommandBars.Count + 1;

   stOutput.WriteLine ("CommandBar Controls");
   string strIndent = " ";
   for (int iCount = 1; iCount < iCmdCount; iCount++) {
      DumpBar(mApplicationObject.CommandBars[iCount],
         stOutput, strIndent);
   }

   stOutput.Close();
}

public void DumpBar(CommandBar cmdBar, StreamWriter stOutput,
   string strIndent) {

   stOutput.WriteLine(strIndent + " CommandBar Name: " + cmdBar.Name);
   int iCmdCount = cmdBar.Controls.Count + 1;
   strIndent += " ";
   for (int iCount = 1; iCount < iCmdCount; iCount++) {
      DumpControl(cmdBar.Controls[iCount],
         stOutput, strIndent);
   }
}

public void DumpControl(CommandBarControl cmdControl,
   StreamWriter stOutput, string strIndent) {

   stOutput.WriteLine(strIndent + " Control Caption: " +
      cmdControl.Caption + " ID: " + cmdControl.Id);

   if ((cmdControl.Type == MsoControlType.msoControlPopup) ||
      (cmdControl.Type == MsoControlType.msoControlGraphicPopup) ||
      (cmdControl.Type == MsoControlType.msoControlButtonPopup) ||
      (cmdControl.Type == MsoControlType.msoControlSplitButtonPopup) ||
      (cmdControl.Type == MsoControlType.msoControlSplitButtonMRUPopup)) {

      CommandBarPopup cmdPopup = (CommandBarPopup) cmdControl;
      int iCmdCount = cmdPopup.Controls.Count + 1;

      strIndent += " ";
      for (int iCount = 1; iCount < iCmdCount; iCount++) {
         DumpControl (cmdPopup.Controls[iCount], stOutput, strIndent);
      }
   }
}

10/14/2005

Company Leadership: From the Top Down

For most of my career I’ve worked for small companies, usually between 30 and 200 people. Occasionally up to 900 which I suppose makes that a mid-size company. Only one of those companies ever made it to an IPO. My guess is that the reason for that mostly had to do with where I was on the east coast and the time, the early 90s. Some were bootstrapped, and some were “experimental” departments from larger organizations (Reuters and IBM). I never had a stock option until I moved to California and accepted a position at OnDisplay. I’ve had the misfortune/fortune to have seen a lot of mistakes made on all levels, been sold as an asset, and seen good products just fade away. I will be writing about some of those experiences. I think that it’s important that they be documented because it frustrates the hell out of me to watch current companies make the same or similar mistakes as other companies have made. Especially now, we’ve got the Internet folks, we have blogging, we have an incredible amount of opportunities to learn and gain from others’ experiences.

I believe in leadership and you’ll have an opportunity to read a great deal about it on my site. Most problems are created because of lack of leadership at some level within the organization. Everyone has leadership responsibilities; to think otherwise seriously reduces a company’s ability to react creatively and immediately to new situations and problems. If a person is not capable of accepting personal responsibility; then that person is not capable of leadership and needs to be let go. Let them mess up someone else’s company.

Personal leadership is the ability to attend to your responsibilities. To make intelligent and informed decisions that surpass the expected results. Whenever possible, deliver more then is expected of you. There are times that it’s okay to do something so that it’s “good enough”. But that decision should be made with the people that the decision affects. For example, when building a product prototype you don’t have to make every feature work perfectly, you just have to prove that the idea will work.

As you look up (or down) through your organization...what do you see? Do you see a clearly communicated company directive, department directive, and team objective? If you don’t then you should ask why. Let’s just assume that you have a company full of responsible leaders but things just aren’t going as you expect. Where is the break down? Is it because they don’t know what they are trying to accomplish, or that they don’t have the resources to fulfill their purpose? Maybe they don’t understand their roles and they don’t know who to ask. Is this a communication problem or a process problem?

I consulted with a company a couple years ago and I just couldn’t believe the things that were happening there. The company has maybe 150 people, very nice facility, good location and some really good and smart people. But what they also have are kingdom builders. People who are looking out for themselves and not for the company. The fact that those people still have jobs is the fault of the executives who allow it to continue. What amazes me is the amount of money the kingdom builders are burning through. Who is watching the money? Now, I interpret this as a good company with some fiscal irresponsibility. The executives who are supposed to direct the company’s commercial growth have not exhibited leadership. I’m not sure they even realize the waste. But most of the staff does and probably the non-kingdom building managers do too. Now I know some executives who read this will think that this company’s leaders probably have some bigger plan, but I have to say that I really doubt it. This waste has been going on for years and there is no visible ROI in sight. Executives and staff have been replaced, unfortunately some good ones. Leadership has failed with some at the middle-management level because they are thinking of themselves and not of the company. Leadership has failed at an executive level because they have not identified the problem or put in place processes that would stop it. And for some at the staff level, leadership has failed because they are frustrated and just don’t care anymore.

This is NOT an uncommon problem. What this company needs to do to solve its problems is bring in a management consultant who has experience with small technology company problems. Their problems aren’t going to be fixed by some new mission or vision statement. They need to sit down and figure out what their business is, what it will be, what they have now, what they need and don’t need. After that they need to figure out who among their current employees are leaders and who are kingdom builders. Fire the kingdom builders and charge the remaining leaders with the mission of fulfilling the corporate, department, and team objectives. They need a management consultant to help them with this because they need someone who is standing outside the problem; who can hopefully, see things more clearly.

Software: Excel Add-In Not Loading? Try this...

I’ve been playing around with Excel Add-ins and I have had quite the frustrating last 5 hours. I put some code into my Connect class that caused the add-in to throw an exception. This caused Excel put up a message box telling me that the add-in was not playing nice and should it be removed from the list? I thought I said “No”. I certainly did something wrong because after that fun little message my add-in stopped coming up. Great. So 5 hours later, being unable to find anything via Google, it suddenly struck me that I should just create another add-in project and see what was different. That did it. So you don’t have to waste time if you run into this. Add the following code to your registry:

Under KEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\Office\Excel\AddIns\MyAddIn.Connect add the following values:

String value: Description "MyAddIn rocks!’
String value: FriendlyName “MyAddIn”
DWORD value: LoadBehavior 0x00000003

This got me back to my original development settings. Oh the Joy of it all! (that is sarcasm)

10/12/2005

MSDN Event for ASP.NET

Today I attended a free MSDN Event for ASP.NET 2.0. What an INCREDIBLY COOL product. I am blown away and really looking forward to the release. I know a lot of folks who build web pages like to type everything in. That’s soooo not me. I am the queen of copy/paste and drag-and-drop. I prefer to spend my time solving the big problems and not worrying about figuring out stuff someone else has already figured out. For someone like me the latest release of ASP.NET is a dream come true. Lots of controls that can be dragged onto forms, Intellisense that almost writes the code for me and some really cool integration with different types of data stores. Very exciting. After today’s session I’m actually thinking about renewing my MSDN subscription so that I can get the final releases (and patches).

I am also looking forward to building an ASP.NET sample for the Digipede Network. As you know from my previous posts I’m heavy into Excel samples right now, but I hope to get that finished up soon. I am also hoping to put some AJAX into my ASP.NET sample. I suspect that AJAX and the Digipede Network can make some really cool things happen.

The other thing I got out of today’s MSDN Event is the realization that the world has changed. What??!?!? Yea, I’m of the old school where you have to do it alone. No guts no glory. Well, that’s just wrong. I realized today that if I were to do my career over I would attend every technical event I could, I would join all the user groups, write more, and give presentations. I would also have stayed in school as long as I could. I kept meaning to get my Masters but...life just happens and the next thing I knew I’ve got no time. With software development work being off shored we American engineers have to find ways to distinguish ourselves. Knowing how hard it was for me to find work I can’t believe that the people who identify up and coming careers listed computer programmers. (I just searched for the article and couldn’t find it...)

So advice for the young and fresh....never stop learning, always share, and make a lot of friends.

Here are some links from the event:

Bay.NET User Group
San Francisco Networking Technologies Users Group
Anand Iyer's Blog

10/09/2005

Company Leadership: Refactoring a Software Development Department

This essay addresses what is required to “fix” a failing software development department. There are two major failure points in a software department: the people and the processes. Either or both can have problems that directly affect the success of product delivery and quality, and team cohesiveness. Warning signs include:

• Missed dates.
• Abundant bug counts.
• Employee turnover.
• Employees shorting hours.
• Low moral.

To overcome the obstacles, management has to first identify the specific problems. The identification process is much like debugging an application. It’s important to remember that the root problem(s) may not be visible in the identified problem set. But the relationships will be there. It is management’s responsibility to discover the problems and fix them. If you are an engineer working for a manager that will not address the issues; you can either try and fix the problem or find a new job. My recommendation is that if you don’t have any power and can’t get any power...then leave. I have tried to fix problems without the support of the management team and got nothing but frustration and stress for my efforts. NOTHING is worth your health.

As the manager you must also consider the possibility that YOU are the problem. You must lead. Not manage. Even if your title contains “Manager”, it doesn’t make you the leader. You can not build a team unless you have their trust and respect. To accomplish this you must lead them. You must make sure that you talk to them, address their concerns, and shield them from the crap that is rolling downhill...on you.

Assuming that you are a proactive manager and you’ve identified the root problems. You have to play out different scenarios before attempting to implement a fix. Every action has a reaction. So even if you have identified that one person is a disruptive influence, firing that person may not be the best solution. You have to take into consideration the contributions the individual is making to the team and the project as well as the group dynamics. If the disruptive individual is considered a leader then it may be in your best interest to turn that person into an ally. If you handle the situation carefully you can transfer the other's leadership position to yourself. Remember, you can NEVER take leadership. It is earned.

If you have serious problems you should fix any glaring process problems first, deal with the people next and then finally finish up the smaller process problems. Engineering folks tend to have very high intelligence so don’t try to bullshit them. There is a good chance they are way smarter than you when it comes to understanding systems and processes, it’s what they’ve been trained for. By focusing first on the processes that are getting in their way you have taken action that will let them know that you are there to support them. This will help you start to win their trust. Most engineers are happy building and creating. They don’t like office politics and they don’t like rules that don’t provide any value. Clear the way for their success, earn their trust, and they will deliver for you.

RoboNexus and the DARPA Grand Challenge

Today history was made! What an amazing accomplishment. I didn’t expect anyone to finish the DARPA Grand Challenge and to my amazement three teams did it. If you are not familiar with the DARPA Grand Challenge it is a race for fully automated robotic vehicles to complete a 150 mile course, in less than 10 hours, with no human assistance. The prize this year was $2 million dollars. Last year the furthest any team had gotten was 7.3 miles. No one else was even close. I was at RoboNexus with my oldest son when it was announce that Stanford’s team had completed the course in about 7 hours. It was assumed that Stanford won but later there was an announcement that 2 other teams had crossed the finish line and Stanford may not have won. It’s all very exciting.

I think robots are the next personal computing technology wave. There are a lot of companies selling kits, HomeBrew clubs, and people passionate about their hobby. I think the movement is very similar to the personal computer movement. Maybe the mantra will be, "A robot in every home!" My son is only 4 ½ (he’d want me to add that half, it’s very important to him) and the people at RoboNexus really were great with the kids. The exhibitors took the time to educate them and make it interesting to them. Even the big companies whose customers are industry and government were absolutely fantastic. I wasn’t sure what to expect. I’ve been to a lot of conventions and I have never been to one that was kid friendly before. Hats off to all the companies that had their people stay, to the exhibitors who took the time to make robotics accessible, to the hobbyists and students who shared their enthusiasm and demonstrated their projects.

Building on an exciting and educational day, I just ordered the LEGO MindStorm Robotics Invention System, I think my kids and I are going to have a blast. And I spent some time thinking about that Roomba by iRobot...I'm not really all that attached to vacuuming! And the demonstrations were very convincing. The Roomba allows me to fantasize about a pet hair free home without all the heavy lifting. Or more accurately...pushing!

10/04/2005

Software: It's Just a Tool

I’ve been reading the materials coming out of this year’s iGrid event and I can’t help but reflect on technology trends I’ve observed over the years. In college I learned Pascal, COBOL, LISP, and FORTRAN. Microcomputers (PCs) were considered toys and only good for teaching the graphics class. My first job out of school I worked on an 8086 using C and Assembler in MS-DOS. I cut my teeth on OS/2 and was the architect for the first OS/2 code generator KASE:VIP for PM. I’ve worked on several flavors of Unix but most recently my world has been a Microsoft world. Through all of this I’ve listened to people religiously committed to a language or operating system and I find the arguments just silly.

Is Java better then C++? Is C# better than Java? At that end of the day the decisions about what to start with: OS, language, and tools is usually only relevant at the beginning of a brand new product development cycle. The average developer does not work on brand spanking new products. She inherits systems already in place and any changes to the existing systems are limited by the business cases. Is Java better than C++? I don’t know and I don’t care. What I care about is the viability of the currently implemented system. Is there a business case (a money saving or making reason) to make a technology change? If there is then start migrating, if not don’t change anything. Software is a tool to solve problems and make money. Period.

When I look out on the grid computing market space I see a lot of different types of solutions. Grid computing is extremely cool stuff. Google is using it behind its search engine. Researchers are doing really neat stuff. There are open-source, Linux, HPC, Solaris, and Microsoft grid systems available right now. There are choices. With those choices will come people who passionately advocate one solution over all others. Poppycock! Before you commit to a grid solution you need to assess your business requirements, your financial position (remember open source doesn’t necessarily mean free), currently available assets (people, knowledge, hardware, and software) and decide on a grid solution(s) that best suit those needs.

Remember, technology is a tool. Alone it won’t feed your family. If you use it to build something and then sell it, you will generate revenue. Like the hammer you have stashed in your garage. Unless you build something...the hammer is just collecting dust.

10/01/2005

Software: More Excel Then You Could Shake a Stick At!

I have done more work with Microsoft Excel in the last month then I had EVER done in my entire career. Once I figured out the model, it’s been much easier to write code. But man! I’ve been switching back and forth between .NET and COM, C# and VBA; and it all looks a little different between them. In VBA a method might take one parameter but in C# it might take 14. What! Yea. If you want to call Application.Run() from VBA only the first parameter (the function name) is required. The other 30 parameters are optional. Calling Application.Run() from C# however requires that all 31 parameters be defined. Yep. Fortunately you can just fill in the last 30 values with Type.Missing but it is really weird and makes the code hard to read. If you were going to call Run() often without parameters, your code would look much cleaner if you put the Application.Run() call into another subroutine.

For example:

private void RunFunc(string funcName)
{
   mExcelApp.Run(funcName,
      Missing.Value, Missing.Value, Missing.Value, Missing.Value,
      Missing.Value, Missing.Value, Missing.Value, Missing.Value,
      Missing.Value, Missing.Value, Missing.Value, Missing.Value,
      Missing.Value, Missing.Value, Missing.Value, Missing.Value,
      Missing.Value, Missing.Value, Missing.Value, Missing.Value,
      Missing.Value, Missing.Value, Missing.Value, Missing.Value,
      Missing.Value, Missing.Value, Missing.Value, Missing.Value,
      Missing.Value, Missing.Value);
   return;
}

Here is a VBA snippet that checks to see if a worksheet exists in the workbook. It just seems like there should be a better way to tell me that a requested worksheet doesn’t exist in the workbook than to use a GoTo. (Yes, I know it's standard for VBA, it's just not clean.)

On Error GoTo CreateWorksheet
Set inputSheet = Application.ActiveWorkbook.Worksheets("mySheet")

CreateWorksheet:
Dim iSheetCnt As Integer
iSheetCnt = Application.ActiveWorkbook.Worksheets.Count
ActiveWorkbook.Sheets.Add After:=ActiveWorkbook.Worksheets(iSheetCnt)
Set inputSheet = Application.ActiveWorkbook.ActiveSheet
inputSheet.Name = "mySheet"

Here is the same code in C#:

// See if the DigipedeInput worksheet exists
try
{
   inputSheet = (Excel.Worksheet)
      mWorkerWorkbook.Worksheets.get_Item("mySheet");
}
catch (System.Exception /* ex */)
{
   // This gets thrown if the sheet doesn't exist which is fine.
   // Create the worksheet
   int iSheetCnt;
   iSheetCnt = mExcelApp.ActiveWorkbook.Worksheets.Count;

   Excel.Worksheet lastSheet;
   lastSheet = (Excel.Worksheet)
   mExcelApp.ActiveWorkbook.Worksheets.get_Item(iSheetCnt);
   inputSheet = (Excel.Worksheet)
      mExcelApp.ActiveWorkbook.Worksheets.Add(Type.Missing,
      Type.Missing, Type.Missing, Type.Missing);
   inputSheet.Name = "mySheet";
}

Notice that in VBA I have to use a GoTo statement because if a worksheet is not found an error is returned? Notice in the C# that I have to catch an exception? I REALLY don’t like either of these two techniques. I’m going to sleep on it but I suspect that I’ll end up writing a little function to check for the existence of the worksheet. It will probably go something like this:

int iSheetCnt = mExcelApp.ActiveWorkbook.Worksheets.Count;
string strSearchName = “mySheet”;
bool bFound = false;
for (int iCounter = 0; iCounter < iSheetCnt; iCounter++) {
   if (strSearchName.Compare(
      mExcelApp.ActiveWorkbook.Worksheets(iCounter).Name) == 0) {
      bFound =true;
      break;
   }
}

But basically I’ll look for the worksheet and return the appropriate information.

This is actually turning out to be a really fun project. So even though figuring out the nuances between Excel's different manifestations has been a challenge I think the end results are going to be really cool.