bc-programming

Companies and businesses want to prosper. At the core, being a successful business means that you make a sizable revenue; But, when those start to falter, how do businesses determine the cause? They generally measure something; for a programming firm, this may be lines of code written. For a restaurant, perhaps the time it takes for a customer to be seated, and so forth. And on the surface, it makes sense. The problem is, it only makes sense,in theory. Why? because both methods are trying to tack a quantitative statement onto something that cannot be measured in this way; additionally, they forget the human factor. Let's look at a hypothetical situation; Programmer Joe. Programmer Joe has worked at a Software startup since it's early days, and enjoys his job. However, one day, the CEO calls them all into the office to discuss declining revenue. Realistically, the revenue is declining because a competitor has just released a product that directly competes with the startup's flagship software package. However,  management believes that the loose leash they've been keeping the programmers on is to blame; so one of the idea men determines that they should implement a management technique known as metrics. In this case- they start with something basic; each programmer's performance will be judged directly correspondent to the number of lines of code they write. Programmer Joe continues his work as normal; he notices some of his co-workers checking in code that re-rolls standard library routines, and cuts out excess code like this. One day he's called into the Project Manager's office. "Joe... I don't know quite how to explain this- maybe you can. Somehow, you've managed to accumulate a [i]negative[/i] lines per day metric... any idea how that is possible?" "Well, I've noticed a lot of redundant code being checked in, and trimmed it down. the code still works the same way- it's just faster; also, I've managed to fix half the bugs on the list just by doing that." The Project Manager may, in this case, take this particular information to the higher levels. they decide that the metric is flawed- what they need ot measure is lines of code written minus the number of bugs introduced. A feature request arrives from a client near the end of the day, at 4:30PM. the Project Manager asks if Joe can look over the request and if he can maybe stay late to try to get some of those features implemented. So Joe spends the next three hours creating a prototype for the new feature and once he has the main functionality down he checks the code in and goes home. The next day, Joe continues his work on this new feature. However, he is once again called into the Project Manager's office. The Project manager hands Joe a large stack of papers. "you know what those are, Joe?" "No..." "Those are the bug reports filed on code you've checked in recently." "All the code I've been working on recently has been a prototype... I haven't yet gotten it fully integrated into the rest of the system." ... I think you can see where I was going there. basically, the fact is that havign a measuring metric that measures small fiobles in the entire process is doomed to cause hiccups within that process and even bring business to a standstill. In this case, rather then worry about the number of lines of code written or the number of bugs introduced, it might be better to focus on fixing the bugs and adding features; the number of lines of code in a project does not directly correspond to the quality of that project as a whole, and in some cases can even do so inversely. In a strange coincidence, a local Coffee shop that Programmer Joe visits on his way to work had noticably changed. When Joe used to go though their drive thru to grab his morning coffee and a box of donuts for his colleagues, the staff were friendly and often asked him how things were going. Recently, however, Joe has felt like a piece of scrap metal on an assembly line. Once he got to the pay window, he would often hear audible grumbles of discontent as he simply reached into his pocket for his wallet. His donuts have often been obviously simply thrown in the box with little care, too. Joe couldn't understand it, since these were the very same people that would serve him before. Eventually, Joe decided to go elsewhere for his morning coffee. The previous paragraph is not an entire fabrication; in fact, I work at a location that does just this. They time every single drive thru customer's time at the window, and it's treated as the single most important measurement of performance in the entire store. I'd even go so far as to say it seems to be used to reflect directly customer satisfaction. However, this simply is not the case. The franchise, in particular, places a recommended limit of 42 seconds for waiting at the window. a reasonable time frame, depending on the volume of customers. However, at my location it has now been decreed that we shall not take longer then 30 seconds or, from what I hear of others, they will be verbally "abused" about it. In any case, a little backstory is probably in order. Lately it would appear that revenue has been dwindling; there are far fewer customers then I remember coming in, at all times of the day. Additionally, various seemingly pedantic rules have been places on our release of such seemingly trite things as butters and napkins. It's fair to assume in this case that they obviously want to bring business back up again- and that is certainly something anybody in that position would try to do. However, with that said, they are going about it wrong. In the Retail and Customer Service industry- where almost all revenue is coming from consumers who purchase your product by coming to your establishment, the all-time, 100% most important thing for business is customer satisfaction. No exceptions. Interestingly enough, since this has started, I've gotten dozens of complaints from Customers who visit regularly about the shoddy way they were treated while going through the drive thru at some other time during the day. This certainly is not the fault of the workers at the time; since, as I said, they are essentially being "forced" to try to reduce times to <30 seconds. But when you get customers, the main source of revenue for the store, complaining about something that is the result of a change to the store policy that was introduced to try to increase revenue it is pretty solid evidence that the technique has failed miserably. The problem here is not that those in charge know, as well as anybody else, that customer satisfaction is the single most important thing to the stores success, but rather in that they have tried to assign a single metric to measure this particular quality. And they do not correspond. I certainly won't argue that customers prefer fast service— it certainly is on their list of hopes when they enter a drive-thru to be out as fast as possible— but I think what one needs to realize is that having their orders (literally) thrown into their car for the sake of speed of service doesn't please the customer. They aren't going to think, "well, golly, they threw the sandwich right into the passenger seat and refused to carry on a quick little bit of small-talk while I waited, but damn, it took only 30 seconds, so I am going to say I am satisfied". I'm sorry, but this does not happen. As long as a customer is not waiting an exceedingly long time for their purchase, they tend not to notice it. Think of it this way- there is the old adage where you can either have fast service, good service, or right service, but you can only choose two. I put forth that, for many consumers it also holds true that when one of these is omitted, and the other two are done in a way that exceeds their expectations, they are likely to generally be satisfied. For example, if a customer is greeted with courteous fervor, and perhaps a friendly conversation ensues in addition to their order being made perfect, they are less likely to notice that they had to wait in the line for a few minutes. Now, if they had to wait that same amount of time and they were treated brashly, they are more likely to take offense. In fact, the single most important thing to almost all customers is not the time they wait, or even the fact that their order is made perfectly to their specifications, but rather to be treated as people, and not as some mindless consumer whose particular interests and concerns are of no importance. The sad fact is using this particular measurement metric encourages the workers to do the latter. The thing is, there are even further flaws in the mechanism. First, the device doesn't even work half the time, so times come out skewed and sometimes two vehicles get counted in the same interval. Additionally, since the time measured is the entire time the customer is at the window, this is not simply a measure of the efficiency of the workers to get the product to the customer but also a test of how quickly the customer can pay for their product. if a customer needs to dig for change for 10 extra seconds after the employees have successfully finished their entire order and simply await payment, why is this 10-seconds attributed to the detraction of the employees? "Because we have no way of knowing" the people who read the recorded times may say. The issue here is that obviously if there is one fact you don't know about what the measurement indicates then there are certainly more, and in fact it could even be put forth that the measurement is completely meaningless. a Customer could be at the window for 10 seconds and still not be pleased, be it because of the shoddy service received while being squeezed through in a tiny window of time, or because they got their order mixed up with another, or some other error instigated by the fact that inhuman demands are made of people there. On the converse, a person could wait for a entire minute at the window and still be perfectly pleased with their service, so using the measure of window time as some sort of barometer by which to judge the performance of a business is downright ridiculous, and this only multiplies when one considers that such time-based constraints are not placed on those consumers who decide to enter the establishment for their service. And while the latter example has certainly acquired far more attention for personal reasons, it certainly is no more or less ludicrous then the software companies implementation; performance metrics have been tried in nearly every industry and in every industry they have failed to provide the hoped for results. The key here is that the measure is not strictly of customer satisfaction or even of revenue; but more directly, of the value of the business. Value is a perception and must be communicated and measured to be perceived as value. Value measurement is the process by which management decides on operational performance measures that will enable them to secure the the owners return on investment. Value measures must be aligned with the business strategy positioning the business. Measurement includes measuring lead factors and lag factors. Lead factors identify performance measures that will proactively provide an indication of whether objectives will be achieved or not. Lead factors allow management to receive warning sign proactively. Lag factors measure how successful management was in terms of creating value. Financial reports are the ultimate lag measures of success. When a business lead measures indicate that the business is performing well but the business lag factors are showing the contradictory then it is time to review the lead measures. The value measurement process determines the behaviour of the business and aligns the behaviour of human capital with the value expectations of all stakeholders e.g. owners, management, customers, employees and partners. Value should be measured and reported on from every stakeholder's perspective. A true balanced scorecard will drive performance improvements for all five stakeholder dimensions. This all applies to ANY business, regardless of industry. Flipping quickly back to software, an excellent overview of the problems present with Performance metrics as used in that industry can be found here: http://discuss.joelonsoftware.com/default.asp?biz.5.304155.19

Companies and businesses want to prosper. At the core, being a successful business means that you make a sizable revenue; But, when those start to falter, how do businesses determine the cause? They generally measure something; for a programming firm, this may be lines of code written. For a restaurant, perhaps the time it takes for a customer to be seated, and so forth. And on the surface, it makes sense.

The problem is, it only makes sense,in theory. Why? because both methods are trying to tack a quantitative statement onto something that cannot be measured in this way; additionally, they forget the human factor.

Let’s look at a hypothetical situation; Programmer Joe. Programmer Joe has worked at a Software startup since it’s early days, and enjoys his job. However, one day, the CEO calls them all into the office to discuss declining revenue. Realistically, the revenue is declining because a competitor has just released a product that directly competes with the startup’s flagship software package. However,  management believes that the loose leash they’ve been keeping the programmers on is to blame; so one of the idea men determines that they should implement a management technique known as metrics. In this case- they start with something basic; each programmer’s performance will be judged directly correspondent to the number of lines of code they write.

Programmer Joe continues his work as normal; he notices some of his co-workers checking in code that re-rolls standard library routines, and cuts out excess code like this. One day he’s called into the Project Manager’s office.

“Joe… I don’t know quite how to explain this- maybe you can. Somehow, you’ve managed to accumulate a [i]negative[/i] lines per day metric… any idea how that is possible?”

“Well, I’ve noticed a lot of redundant code being checked in, and trimmed it down. the code still works the same way- it’s just faster; also, I’ve managed to fix half the bugs on the list just by doing that.”

The Project Manager may, in this case, take this particular information to the higher levels. they decide that the metric is flawed- what they need ot measure is lines of code written minus the number of bugs introduced.

A feature request arrives from a client near the end of the day, at 4:30PM. the Project Manager asks if Joe can look over the request and if he can maybe stay late to try to get some of those features implemented. So Joe spends the next three hours creating a prototype for the new feature and once he has the main functionality down he checks the code in and goes home. The next day, Joe continues his work on this new feature. However, he is once again called into the Project Manager’s office.

The Project manager hands Joe a large stack of papers.

“you know what those are, Joe?”

“No…”

“Those are the bug reports filed on code you’ve checked in recently.”

“All the code I’ve been working on recently has been a prototype… I haven’t yet gotten it fully integrated into the rest of the system.”

…

I think you can see where I was going there. basically, the fact is that havign a measuring metric that measures small fiobles in the entire process is doomed to cause hiccups within that process and even bring business to a standstill. In this case, rather then worry about the number of lines of code written or the number of bugs introduced, it might be better to focus on fixing the bugs and adding features; the number of lines of code in a project does not directly correspond to the quality of that project as a whole, and in some cases can even do so inversely.

In a strange coincidence, a local Coffee shop that Programmer Joe visits on his way to work had noticably changed. When Joe used to go though their drive thru to grab his morning coffee and a box of donuts for his colleagues, the staff were friendly and often asked him how things were going. Recently, however, Joe has felt like a piece of scrap metal on an assembly line. Once he got to the pay window, he would often hear audible grumbles of discontent as he simply reached into his pocket for his wallet. His donuts have often been obviously simply thrown in the box with little care, too. Joe couldn’t understand it, since these were the very same people that would serve him before. Eventually, Joe decided to go elsewhere for his morning coffee.

The previous paragraph is not an entire fabrication; in fact, I work at a location that does just this. They time every single drive thru customer’s time at the window, and it’s treated as the single most important measurement of performance in the entire store. I’d even go so far as to say it seems to be used to reflect directly customer satisfaction. However, this simply is not the case. The franchise, in particular, places a recommended limit of 42 seconds for waiting at the window. a reasonable time frame, depending on the volume of customers. However, at my location it has now been decreed that we shall not take longer then 30 seconds or, from what I hear of others, they will be verbally “abused” about it.

In any case, a little backstory is probably in order. Lately it would appear that revenue has been dwindling; there are far fewer customers then I remember coming in, at all times of the day. Additionally, various seemingly pedantic rules have been places on our release of such seemingly trite things as butters and napkins. It’s fair to assume in this case that they obviously want to bring business back up again- and that is certainly something anybody in that position would try to do.

However, with that said, they are going about it wrong. In the Retail and Customer Service industry- where almost all revenue is coming from consumers who purchase your product by coming to your establishment, the all-time, 100% most important thing for business is customer satisfaction. No exceptions. Interestingly enough, since this has started, I’ve gotten dozens of complaints from Customers who visit regularly about the shoddy way they were treated while going through the drive thru at some other time during the day. This certainly is not the fault of the workers at the time; since, as I said, they are essentially being “forced” to try to reduce times to <30 seconds. But when you get customers, the main source of revenue for the store, complaining about something that is the result of a change to the store policy that was introduced to try to increase revenue it is pretty solid evidence that the technique has failed miserably.

The problem here is not that those in charge know, as well as anybody else, that customer satisfaction is the single most important thing to the stores success, but rather in that they have tried to assign a single metric to measure this particular quality. And they do not correspond. I certainly won’t argue that customers prefer fast service— it certainly is on their list of hopes when they enter a drive-thru to be out as fast as possible— but I think what one needs to realize is that having their orders (literally) thrown into their car for the sake of speed of service doesn’t please the customer. They aren’t going to think, “well, golly, they threw the sandwich right into the passenger seat and refused to carry on a quick little bit of small-talk while I waited, but damn, it took only 30 seconds, so I am going to say I am satisfied”. I’m sorry, but this does not happen. As long as a customer is not waiting an exceedingly long time for their purchase, they tend not to notice it. Think of it this way- there is the old adage where you can either have fast service, good service, or right service, but you can only choose two. I put forth that, for many consumers it also holds true that when one of these is omitted, and the other two are done in a way that exceeds their expectations, they are likely to generally be satisfied. For example, if a customer is greeted with courteous fervor, and perhaps a friendly conversation ensues in addition to their order being made perfect, they are less likely to notice that they had to wait in the line for a few minutes. Now, if they had to wait that same amount of time and they were treated brashly, they are more likely to take offense. In fact, the single most important thing to almost all customers is not the time they wait, or even the fact that their order is made perfectly to their specifications, but rather to be treated as people, and not as some mindless consumer whose particular interests and concerns are of no importance. The sad fact is using this particular measurement metric encourages the workers to do the latter.

The thing is, there are even further flaws in the mechanism. First, the device doesn’t even work half the time, so times come out skewed and sometimes two vehicles get counted in the same interval. Additionally, since the time measured is the entire time the customer is at the window, this is not simply a measure of the efficiency of the workers to get the product to the customer but also a test of how quickly the customer can pay for their product. if a customer needs to dig for change for 10 extra seconds after the employees have successfully finished their entire order and simply await payment, why is this 10-seconds attributed to the detraction of the employees? “Because we have no way of knowing” the people who read the recorded times may say. The issue here is that obviously if there is one fact you don’t know about what the measurement indicates then there are certainly more, and in fact it could even be put forth that the measurement is completely meaningless. a Customer could be at the window for 10 seconds and still not be pleased, be it because of the shoddy service received while being squeezed through in a tiny window of time, or because they got their order mixed up with another, or some other error instigated by the fact that inhuman demands are made of people there. On the converse, a person could wait for a entire minute at the window and still be perfectly pleased with their service, so using the measure of window time as some sort of barometer by which to judge the performance of a business is downright ridiculous, and this only multiplies when one considers that such time-based constraints are not placed on those consumers who decide to enter the establishment for their service.

And while the latter example has certainly acquired far more attention for personal reasons, it certainly is no more or less ludicrous then the software companies implementation; performance metrics have been tried in nearly every industry and in every industry they have failed to provide the hoped for results. The key here is that the measure is not strictly of customer satisfaction or even of revenue; but more directly, of the value of the business.

Value is a perception and must be communicated and measured to be perceived as value. Value measurement is the process by which management decides on operational performance measures that will enable them to secure the the owners return on investment. Value measures must be aligned with the business strategy positioning the business. Measurement includes measuring lead factors and lag factors. Lead factors identify performance measures that will proactively provide an indication of whether objectives will be achieved or not. Lead factors allow management to receive warning sign proactively. Lag factors measure how successful management was in terms of creating value. Financial reports are the ultimate lag measures of success. When a business lead measures indicate that the business is performing well but the business lag factors are showing the contradictory then it is time to review the lead measures.

The value measurement process determines the behaviour of the business and aligns the behaviour of human capital with the value expectations of all stakeholders e.g. owners, management, customers, employees and partners. Value should be measured and reported on from every stakeholder’s perspective. A true balanced scorecard will drive performance improvements for all five stakeholder dimensions. This all applies to ANY business, regardless of industry.

Flipping quickly back to software, an excellent overview of the problems present with Performance metrics as used in that industry can be found here: http://discuss.joelonsoftware.com/default.asp?biz.5.304155.19

A few minutes ago I posted a small Visual Basic 6 class module that could be used to register an applications objects in something called the "Running Object Table" Or ROT. Rather then go on a long monologue in that post I've decided that this is an excellent topic for a blog entry, with pictures and whatnot. The forum thread I created is here, and provides the source to a useful class module that can be used to expose your objects on the ROT. In order to fully understand what the ROT is and it's usefulness, it's important to have a basic understanding of COM. At the moment COM is really a "legacy" technology, and Microsoft much prefers that people develop .NET assemblies instead. Of course, what MS fails to mention is that it's unlikely that COM support will be withdrawn from any foreseeable version of windows, simply because it is so deeply rooted and so necessary for applications, including Microsoft's. In any case, having a solid knowledge of COM is not something that is going to become useless or even irrelevant anytime soon, so it cannot hurt even a non-programmer to understand some of the basic semantics involved. Originally, COM wasn't really released with any fanfare; in fact, it was simply the "bed" upon which the more prevalent technology at the time, OLE (Object Linking and Embedding) was based. OLE really is an awesome technology, but the problem is nobody really knows how to use it. Anyway, the main idea was that each application knew how to deal with it's own files; for example, excel knew spreadsheets, word-perfect knew word processing, etc, and the idea was that instead of trying to get applications to implement the various different application "powers" (such as having built-in word processors and the like), they could simply call on another application to do it. For example, if you made a useful chart in Excel 5.0: Dun click here for a bigger image, yee-haw Now, of course you could make a chart with the spreadsheet, but let's say you wanted to embed the spreadsheet into your word document. In pre-OLE versions of word, you could copy-paste a picture of the spreadsheet, but if you ever needed to change it you'd need to go right back to excel, find the file you originally used, make the changes, copy it, paste it, reformat the bloody document again because pasting it has totally screwed up your pagination, etc. Basically it translates to a huge pain in the ol' keester. So Microsoft decided, hey, you know what, let's make it so you can actually place the spreadsheet document itself into the word document, and you can edit the spreadsheet and have it update in the word document automatically. One of the development team leaders for excel at the time said, "that might be a bit difficult" at which point they fired him and hired somebody else. I'm making this up, obviously. the quip was more along the lines of him trying to discuss his previous extra-marital relations with the project managers mother. Or maybe it was their wife, in either case it's generally not something you bring up around the water-cooler even in faint whispers, let alone in the middle of an important business meeting about important businessy things, like who keeps taking the bloody stapler. Anyways, Microsoft eventually perfected the technology that they called OLE. (oh yeah, and just so everybody is aware, it's apparently pronounced "olay"... so don't try to embarass yourselves. I still personally pronounce it Ohh- Ell- eee, but hey, I'm a rebel. Also pronouncing it "olay" is just begging for jokes about "oil of OLE" or perhaps even matador references. It just feels like it was chosen for comedic reasons.) using OLE, you could link your excel spreadsheet to your southern US based newspaper, by using the very popular "Copy" command from Excel, and then using "paste Special" in word, you could get the following dialog: As you can see, there are a number of choices here. the relevant one to this discussion is to insert it as a "Excel 5.0 Worksheet"- the default for the two radio buttons on the side is to actually "paste" the item into the document; here I've chosen to paste a link. pasting the spreadsheet into the document directly (rather then linking it) still allows you to edit the spreadsheet, but the spreadsheet data itself is saved right in the word document when you save it. Because linking the object instead offers one extra point of failure and because I like living on the edge, I always opt to link the documents even if I have no good reason to. In any case, the resulting newsletter is this: beautiful! such magic is the very essence of OLE. In fact, one could even take advantage of OLE in their Visual Basic Applications, starting with Version 2.0, which included, among other useless "professional" controls, the OLE client control. Mirror, Mirror, on the wall, whose the leetest of them all? "But I thought this entry was about the ROT" you ask. to which I reply, shut the hell up, will you, I'll get to that eventually, and the less you try to fictitiously interrupt me the quicker I can try to ease the topic back to the present day and the running object table. Don't worry, I haven't forgotten about it. Anyways; as I was saying, COM was basically what this OLE magic is based on, and was in fact the "plumbing" that made OLE work. OLE was only the visual manifestation of COM; therefore it was the part that was oooh'd and ahhh'd, (although the actual response was more a hum and a haw, since nobody could really figure the bloody thing out). COM just sort of sat in the background. unnoticed, watching OLE take the spotlight, earn all the respect and get all the beautiful women and free cream soda. Microsoft created something called "OLE Controls" whereby various User Interface widgets could be created using a number of OLE Interfaces with confusing names and functions, like an IPersistFile that didn't deal with files, IOLEActiveObject, and other weird esoteric interfaces. Things started looking up with the creation of "ActiveX Controls" which are exactly the same as OLE Controls, but don't require all the silly interfaces to be implemented (at least, not as many of them). Pretty much all you needed to implement were a few basic interfaces. With the release of Visual Basic 5.0, this task became even easier; soon enough ActiveX Controls were sprouting up out of basements everywhere with dubious security and hardly little effort or skill. Unfortunately this had the effect of backfiring on Microsoft as they had forgotten that IE3 sorta just allowed ActiveX Controls to do what they pleased; in the long run, Internet Explorer gave ActiveX a very bad name. The technology itself is sound; however, one consumer (Internet Explorer) has an awful track record when it comes to actually being intelligent with what is actually run. First MS decided, "ha! we'll just make it so they have to sign the control as safe with this little tool" much to their surprise, the people who were doing illegal things already by creating spyware as ActiveX Controls gladly downloaded the tool and signed them, even though the EULA was quite clear that you couldn't sign malicious files. "dear gawd! these people are MAD! mad I say! have they any idea the legal repercussions of agreeing to a shrink-wrap EULA implicitly in a completely non-legally binding way?" exclaimed... well, somebody at MS, to which the common reply was "Tom, we know you've been taking staplers home." In either case, ActiveX got noticed, and while IE was a massive failure when it came to using ActiveX, ActiveX was perfectly safe on the desktop itself; in fact, it's still quite prevalent. Go ahead and look on your own windows machines- ActiveX Controls are found in "OCX" files. many are even installed by default. Because ActiveX was more a Programming technology then a silly little User Interface gimmick like OLE, programmers liked to pick apart it's innards like a vulture likes to take it's pick from the smorgasboard of delightful organs that are present on a freshly killed wildebeest. Programmers learned of the various COM component technologies that powered ActiveX and OLE before it. It was around this time that COM itself became the "technology of choice" when it came to interoperating with the various components of windows. So much so that COM itself became deeply rooted in the Operating System; with the actual Shell interfaces that allow for such things as IE plugins and Browser helper objects and Shell Extensions being implemented as COM interfaces. COM itself establishes a binary standard between modules; it essentially lays out how objects are to look in memory, so that other objects can use them. In a strange coincidence this layout was nearly identical to the way the Visual C++ compiler laid out it's Class instances. Unlike C++ itself, or java, or .NET, for example, however, COM does not really facilitate for most things that people seem to require in order for something to be "object oriented". For example- there was no Implementation inheritance. There was interface inheritance, to be sure, but they didn't add implementation inheritance because they believed that to replace parts of the functionality of a pre-existing class with your own while leaving parts of the original code intact requires a knowledge of what that code does beyond what you can see, and really there is no debating that fact on the level. Now then, enter OLE automation, which was really just COM with a fancy name. OLE automation basically meant that you could "control" other applications from another application, completely cross-process. For example, nowadays you can write a VBScript that interfaces with Microsoft word to open a document, make changes to it, save it, and close it. This is possible through OLE automation, because the Word Program exposes itself to other applications, who, strangely enough, are not revolted by Word's nether regions. Visual Basic has allowed for the creation of ActiveX programs since Version 5; what Word would be equivalent to as a Visual basic project would be an "ActiveX EXE". there are both ActiveX EXE and ActiveX DLL projects; they act quite similar to one another, in that the various methods of using their objects are the same in either case. the main difference between them is that an ActiveX EXE is, for obvious reasons, a completely separate process, while a ActiveX DLL is contained in the same process and every process that uses it. This means that all data passed back and forth to an ActiveX EXE needs to be marshalled across a process boundary. Very time consuming, but at the same time the EXE can perform operations asynchronously from the application itself, which, in the case of Visual Basic, really only has a single thread. When a ActiveX Server program is running, the general idea is for it to add itself to something called the "Running Object Table". This ia global table that stores all the various active COM objects that can be retrieved. For example, Word, Excel, Access, etc, all place their "Application" objects into this table. Visual Basic ActiveX EXE programs, however, for whatever reason, do not. This despite Visual Basic having a function that can acquire objects from the running object table, the GetObject() Function. GetObject The GetObject Function is probably one of the strangest functions with the oddest behaviour and the quirkiest set of rules of all the functions in the Visual Basic Language. The syntax seems simple enough: GetObject([Pathname],[class]) pathname, we can guess from our encounters with Excel and word with OLE, would probably accept a OLE enabled document. and lo and behold, passing a excel, word, or other OLE server application document returns that document object. the class parameter however requires some explanation regarding it's background. All COM objects have at least one thing associated with them; a CLSID, which I guess stands for "ClassID", but could just as easily stand for "Chickens Like Seeds In Dung". This CLSID is required when instantiating (creating an instance of) the object. Some objects have another, optional, more human readable representation, known as a "progid" (god knows what it stands for. I'm going to say "People Really Ought to Give It a few Days" or something. This is far easier to read then the CLSID. a ProgID might be "Excel.Application", whereas it's CLSID is {00024500-0000-0000-C000-000000000046} (although technically it fits in 8 bytes, this is the conventional "human readable" form of a CLSID. Now, you can call me dull, dense, made of cheese or fond of yogurt, but I don't think I'm too far off-base in saying that the progID, While having an utterly ridiculous acronym expansion that I just made up, is a lot easier to read then the CLSID. In any case; the Class argument to GetObject() is actually a ProgID. So the question is; how does one call this function to get a running instance of the program? If you do: Set X=GetObject("","Excel.Application") a new instance of Excel starts in the background and your given it's application object. However, it turns out the first parameter is optional... you can in fact do this: set X = GetObject( ,"Excel.Application") and your given a instance of Excel that is already running, if available. If not, you get an error. You can trap the error and perform either the former empty string version of the function call or use CreateObject() to create a new instance explicitly though, if necessary. Now, given that GetObject() when used in that scenario acquires the object from the running object table, it becomes evident why it will not work for Visual Basic objects; as previously discussed, the visual basic Runtime never actually anything to the ROT. This means it's necessary to do so yourself by explicitly adding it to the ROT using the COM API. Now, although I wrote the class I describe in the forum post 5 years ago, I distinctly remember that from beginning to end only took about 30 minutes. Most of the COM code I have in there was ripped directly out of a module in my BASeEdit XP project I was working with at the time. One tool I found useful while I was working on it was a little Utility that came with Visual Studio 98 called "ROT Viewer". Since IT doesn't appear to be available online anywhere, I have taken the liberty of uploading it myself. Even the non-programmer can get a few minutes of mild amusement out of the program. With Vista and 7, you need to start the program with Administrator rights, otherwise it doesn't show anything. Try it out; start word, excel, (I wonder if MS works has a COM server...) and any number of other programs, and watch them get added to the table, close out the programs, watch them leave... OH THE EXCITEMENT!

A few minutes ago I posted a small Visual Basic 6 class module that could be used to register an applications objects in something called the “Running Object Table” Or ROT. Rather then go on a long monologue in that post I’ve decided that this is an excellent topic for a blog entry, with pictures and whatnot. The forum thread I created is here, and provides the source to a useful class module that can be used to expose your objects on the ROT.

In order to fully understand what the ROT is and it’s usefulness, it’s important to have a basic understanding of COM. At the moment COM is really a “legacy” technology, and Microsoft much prefers that people develop .NET assemblies instead. Of course, what MS fails to mention is that it’s unlikely that COM support will be withdrawn from any foreseeable version of windows, simply because it is so deeply rooted and so necessary for applications, including Microsoft’s. In any case, having a solid knowledge of COM is not something that is going to become useless or even irrelevant anytime soon, so it cannot hurt even a non-programmer to understand some of the basic semantics involved.

Originally, COM wasn’t really released with any fanfare; in fact, it was simply the “bed” upon which the more prevalent technology at the time, OLE (Object Linking and Embedding) was based. OLE really is an awesome technology, but the problem is nobody really knows how to use it. Anyway, the main idea was that each application knew how to deal with it’s own files; for example, excel knew spreadsheets, word-perfect knew word processing, etc, and the idea was that instead of trying to get applications to implement the various different application “powers” (such as having built-in word processors and the like), they could simply call on another application to do it. For example, if you made a useful chart in Excel 5.0:

Now, of course you could make a chart with the spreadsheet, but let’s say you wanted to embed the spreadsheet into your word document. In pre-OLE versions of word, you could copy-paste a picture of the spreadsheet, but if you ever needed to change it you’d need to go right back to excel, find the file you originally used, make the changes, copy it, paste it, reformat the bloody document again because pasting it has totally screwed up your pagination, etc. Basically it translates to a huge pain in the ol’ keester.

So Microsoft decided, hey, you know what, let’s make it so you can actually place the spreadsheet document itself into the word document, and you can edit the spreadsheet and have it update in the word document automatically. One of the development team leaders for excel at the time said, “that might be a bit difficult” at which point they fired him and hired somebody else. I’m making this up, obviously. the quip was more along the lines of him trying to discuss his previous extra-marital relations with the project managers mother. Or maybe it was their wife, in either case it’s generally not something you bring up around the water-cooler even in faint whispers, let alone in the middle of an important business meeting about important businessy things, like who keeps taking the bloody stapler.

Anyways, Microsoft eventually perfected the technology that they called OLE. (oh yeah, and just so everybody is aware, it’s apparently pronounced “olay”… so don’t try to embarass yourselves. I still personally pronounce it Ohh- Ell- eee, but hey, I’m a rebel. Also pronouncing it “olay” is just begging for jokes about “oil of OLE” or perhaps even matador references. It just feels like it was chosen for comedic reasons.)

using OLE, you could link your excel spreadsheet to your southern US based newspaper, by using the very popular “Copy” command from Excel, and then using “paste Special” in word, you could get the following dialog:

As you can see, there are a number of choices here. the relevant one to this discussion is to insert it as a “Excel 5.0 Worksheet”- the default for the two radio buttons on the side is to actually “paste” the item into the document; here I’ve chosen to paste a link. pasting the spreadsheet into the document directly (rather then linking it) still allows you to edit the spreadsheet, but the spreadsheet data itself is saved right in the word document when you save it. Because linking the object instead offers one extra point of failure and because I like living on the edge, I always opt to link the documents even if I have no good reason to.

In any case, the resulting newsletter is this:

beautiful! such magic is the very essence of OLE. In fact, one could even take advantage of OLE in their Visual Basic Applications, starting with Version 2.0, which included, among other useless “professional” controls, the OLE client control.

“But I thought this entry was about the ROT” you ask. to which I reply, shut the hell up, will you, I’ll get to that eventually, and the less you try to fictitiously interrupt me the quicker I can try to ease the topic back to the present day and the running object table. Don’t worry, I haven’t forgotten about it.

Anyways; as I was saying, COM was basically what this OLE magic is based on, and was in fact the “plumbing” that made OLE work. OLE was only the visual manifestation of COM; therefore it was the part that was oooh’d and ahhh’d, (although the actual response was more a hum and a haw, since nobody could really figure the bloody thing out). COM just sort of sat in the background. unnoticed, watching OLE take the spotlight, earn all the respect and get all the beautiful women and free cream soda. Microsoft created something called “OLE Controls” whereby various User Interface widgets could be created using a number of OLE Interfaces with confusing names and functions, like an IPersistFile that didn’t deal with files, IOLEActiveObject, and other weird esoteric interfaces.

Things started looking up with the creation of “ActiveX Controls” which are exactly the same as OLE Controls, but don’t require all the silly interfaces to be implemented (at least, not as many of them). Pretty much all you needed to implement were a few basic interfaces. With the release of Visual Basic 5.0, this task became even easier; soon enough ActiveX Controls were sprouting up out of basements everywhere with dubious security and hardly little effort or skill. Unfortunately this had the effect of backfiring on Microsoft as they had forgotten that IE3 sorta just allowed ActiveX Controls to do what they pleased; in the long run, Internet Explorer gave ActiveX a very bad name. The technology itself is sound; however, one consumer (Internet Explorer) has an awful track record when it comes to actually being intelligent with what is actually run. First MS decided, “ha! we’ll just make it so they have to sign the control as safe with this little tool” much to their surprise, the people who were doing illegal things already by creating spyware as ActiveX Controls gladly downloaded the tool and signed them, even though the EULA was quite clear that you couldn’t sign malicious files. “dear gawd! these people are MAD! mad I say! have they any idea the legal repercussions of agreeing to a shrink-wrap EULA implicitly in a completely non-legally binding way?” exclaimed… well, somebody at MS, to which the common reply was “Tom, we know you’ve been taking staplers home.”

In either case, ActiveX got noticed, and while IE was a massive failure when it came to using ActiveX, ActiveX was perfectly safe on the desktop itself; in fact, it’s still quite prevalent. Go ahead and look on your own windows machines- ActiveX Controls are found in “OCX” files. many are even installed by default. Because ActiveX was more a Programming technology then a silly little User Interface gimmick like OLE, programmers liked to pick apart it’s innards like a vulture likes to take it’s pick from the smorgasboard of delightful organs that are present on a freshly killed wildebeest. Programmers learned of the various COM component technologies that powered ActiveX and OLE before it.

It was around this time that COM itself became the “technology of choice” when it came to interoperating with the various components of windows. So much so that COM itself became deeply rooted in the Operating System; with the actual Shell interfaces that allow for such things as IE plugins and Browser helper objects and Shell Extensions being implemented as COM interfaces.

COM itself establishes a binary standard between modules; it essentially lays out how objects are to look in memory, so that other objects can use them. In a strange coincidence this layout was nearly identical to the way the Visual C++ compiler laid out it’s Class instances.

Unlike C++ itself, or java, or .NET, for example, however, COM does not really facilitate for most things that people seem to require in order for something to be “object oriented”. For example- there was no Implementation inheritance. There was interface inheritance, to be sure, but they didn’t add implementation inheritance because they believed that to replace parts of the functionality of a pre-existing class with your own while leaving parts of the original code intact requires a knowledge of what that code does beyond what you can see, and really there is no debating that fact on the level.

Now then, enter OLE automation, which was really just COM with a fancy name. OLE automation basically meant that you could “control” other applications from another application, completely cross-process. For example, nowadays you can write a VBScript that interfaces with Microsoft word to open a document, make changes to it, save it, and close it. This is possible through OLE automation, because the Word Program exposes itself to other applications, who, strangely enough, are not revolted by Word’s nether regions.

Visual Basic has allowed for the creation of ActiveX programs since Version 5; what Word would be equivalent to as a Visual basic project would be an “ActiveX EXE”. there are both ActiveX EXE and ActiveX DLL projects; they act quite similar to one another, in that the various methods of using their objects are the same in either case. the main difference between them is that an ActiveX EXE is, for obvious reasons, a completely separate process, while a ActiveX DLL is contained in the same process and every process that uses it. This means that all data passed back and forth to an ActiveX EXE needs to be marshalled across a process boundary. Very time consuming, but at the same time the EXE can perform operations asynchronously from the application itself, which, in the case of Visual Basic, really only has a single thread.

When a ActiveX Server program is running, the general idea is for it to add itself to something called the “Running Object Table”. This ia global table that stores all the various active COM objects that can be retrieved. For example, Word, Excel, Access, etc, all place their “Application” objects into this table.

Visual Basic ActiveX EXE programs, however, for whatever reason, do not. This despite Visual Basic having a function that can acquire objects from the running object table, the GetObject() Function.

GetObject

The GetObject Function is probably one of the strangest functions with the oddest behaviour and the quirkiest set of rules of all the functions in the Visual Basic Language. The syntax seems simple enough:

GetObject([Pathname],[class])

pathname, we can guess from our encounters with Excel and word with OLE, would probably accept a OLE enabled document. and lo and behold, passing a excel, word, or other OLE server application document returns that document object. the class parameter however requires some explanation regarding it’s background.

All COM objects have at least one thing associated with them; a CLSID, which I guess stands for “ClassID”, but could just as easily stand for “Chickens Like Seeds In Dung”. This CLSID is required when instantiating (creating an instance of) the object. Some objects have another, optional, more human readable representation, known as a “progid” (god knows what it stands for. I’m going to say “People Really Ought to Give It a few Days” or something. This is far easier to read then the CLSID. a ProgID might be “Excel.Application”, whereas it’s CLSID is {00024500-0000-0000-C000-000000000046} (although technically it fits in 8 bytes, this is the conventional “human readable” form of a CLSID.

Now, you can call me dull, dense, made of cheese or fond of yogurt, but I don’t think I’m too far off-base in saying that the progID, While having an utterly ridiculous acronym expansion that I just made up, is a lot easier to read then the CLSID.

In any case; the Class argument to GetObject() is actually a ProgID. So the question is; how does one call this function to get a running instance of the program? If you do:

Set X=GetObject("","Excel.Application")

a new instance of Excel starts in the background and your given it’s application object. However, it turns out the first parameter is optional… you can in fact do this:

set X = GetObject( ,"Excel.Application")

and your given a instance of Excel that is already running, if available. If not, you get an error. You can trap the error and perform either the former empty string version of the function call or use CreateObject() to create a new instance explicitly though, if necessary.

Now, given that GetObject() when used in that scenario acquires the object from the running object table, it becomes evident why it will not work for Visual Basic objects; as previously discussed, the visual basic Runtime never actually anything to the ROT. This means it’s necessary to do so yourself by explicitly adding it to the ROT using the COM API.

Now, although I wrote the class I describe in the forum post 5 years ago, I distinctly remember that from beginning to end only took about 30 minutes. Most of the COM code I have in there was ripped directly out of a module in my BASeEdit XP project I was working with at the time. One tool I found useful while I was working on it was a little Utility that came with Visual Studio 98 called “ROT Viewer”. Since IT doesn’t appear to be available online anywhere, I have taken the liberty of uploading it myself.

Even the non-programmer can get a few minutes of mild amusement out of the program. With Vista and 7, you need to start the program with Administrator rights, otherwise it doesn’t show anything. Try it out; start word, excel, (I wonder if MS works has a COM server…) and any number of other programs, and watch them get added to the table, close out the programs, watch them leave… OH THE EXCITEMENT!