Dennis Forbes on Pragmatic Software Development
Subscribe to RSS
 
Wednesday, September 21 2005

One of the most entertaining reads as of late has been the blog of one Mini-Microsoft: A well-written anonymous Microsoft insider with an axe to grind about the way the company is being run, and with some disagreements about the direction the company is headed. "Let's slim down Microsoft into a lean, mean, efficient customer pleasing profit making machine! Mini-Microsoft, Mini-Microsoft, lean-and-mean!" he petitions from the front page.

 

Mini's position isn't novel in the world of corporate worker bees. Malcontent about one's workplace, one's superiors, and compensation is close to a universal gripe. What makes Mini's rantings interesting, aside from the often humorous writing, is that it emanates from a company long considered the exception - the company that defied all of the normal rules of corporate culture. Microsoft was the one organization, we heard, where you didn't have the traditional stratification between the lordly executive - forever blameless and masking incompetence through endless restructurings - and the lowly drones that were treated as replaceable cogs. Microsoft’s developer culture, where the productive intelligent developer was king in the quest to make the best software products, was the benchmark towards which every .COM dreamer aspired when they laid out their plans for world conquest. Microsoft was the “It” employer that Google has become.  

 

Of course as organizations mature they sometimes evolve in ways that aren't compatible with some of their employees. When that happens, pretty much inevitably over an organization’s lifespan, the disgruntled will often take to the airwaves (blogwaves?) to air their grievances, grouching and griping to all who’ll listen about how great things used to be, and how things should be done if management weren’t such idiots. While they might eventually adapt, or the organization might change to accommodate them, the disaffected are far more likely to eventually move on. That sort of transition is inevitable, and as no-one should consider an employer/employee relationship a lifetime commitment, it shouldn’t come as that much of a shock.

 

Having said that I don’t think that’s the case here and it really sets Mini’s blog apart from the endless reams of ex-BigCorporation employees publicly airing their historic dirty laundry. Mini has not only earned the admiration and support of a lot of Microsoft faithful, but his position is empirically supported by Microsoft’s underperformance as of late. No doubt Microsoft does have a serious problem, and is truly an organization in crisis. Perhaps the impression will change after a cluster of long overdue products are released over the next 16 months, but it certainly is the impression today.

 

The roots of the problems are obviously varied for such a large organization, but it is nonetheless enjoyable to armchair theorize. I was given the opportunity a short while back while I was speaking with a Microsoft rep. I was asked what I thought Microsoft’s #1 problem was (must be on the call sheet question list or something). My reply was simply integration – Microsoft is so dedicated to integrating all of their products and technologies starting at v1.0, tying and cross-integrating, that the speed of development slowed to a crawl. One doesn't have to work at Microsoft to understand the threat this presents. Suddenly every delivery slip suddenly affected dozens of products, and every technology risk took on a vastly increased role. The critical dependencies between projects because pervasive, and communication channels to design and deliver products and technologies increased exponentially.

 

Couple this with the fact that the upper-level of Microsoft has become so paranoid about their dependency on platform monopolies that they are seemingly incapable of letting their incredibly capable development teams solve problems in the most effective manner. Microsoft is, for reasons I discussed previously, by far its own biggest competitor, so everything any team does you can be sure had to be approved and agreed upon based upon the strategic interest of the status quo (in particular the Office and Windows hegemony). It wasn't surprizing, for instance, when the powers that be at Microsoft reigned in the hugely successful Internet Explo

Thursday, September 22 2005

Find has some serious usability problems in most applications, particularly those that deal with complex content.

The general usage goes something like this: You are looking for a particular piece of text in a document or a webpage, so you pull up the handy find dialog, type in the desired text or pattern, and hit go. The text is found, hopefully, so the document scrolls some content into view. In amongst the reams of content there is the text that you are seeking, graphically inverted to draw attention.

Of course in a lot of current content, with varying sized text and different backgrounds and context, the colour inversion is next to useless. You're left with nothing more than the hint that the desired text is somewhere on the current page (some apps, though not all, put the found text in the center of the screen, but often that isn't possible due to document bounds. Other apps don't even properly scroll the found text into the view window, so you have to scroll backwards and forwards a bit to see if it's there). We're living in a world of extraordinarily powerful desktop computers: Use some of that fat client power and highlight the find hits better! Putting dancing angels around it. Have clippy run out and jump atop the found text (I'm only partly kidding). Do something to avoid the braindead functionality we have today. And please don't scroll the found text so that it's right behind the modeless find dialog box.

Thursday, September 22 2005

I've removed the Google Adsense ads (they might still appear in some historic entries because of the way Radio Userland updates content - unless I change something affecting the page it won't upstream for just a template change. NOTE: They also appear in the "greatest hits" static collection). I removed them because they're ugly and distracting*, and they offered such a marginal return. I also didn't like that they could be taken as promoting a bias, in a small way implying deference and submission to Google. 

You might ask "Well then why did you add them in the first place?" Good question, and thanks for asking! Let's just say that I don't have total faith in the Do No Evil creed that Google publicly espouses. I can't help but think that Google has a financial incentive to boost the search ranking of pages that host Adsense content (it's brilliant really - You go to Google and do your search, awash in Adsense, all to shuttle off to sites filled with Adsense. It's an Adsense world, baby!). I like these pages to have some search significance, so this concerned me. Add the fact that Google needs to quickly index pages hosting Adsense ads (to allow for contextually keyed ads), offering another possible advantage of hosting their ads. Alas, I'm going to trust the impartiality of Google's search algorithms...

* Isn't it remarkable how Google snuck in as the underdog in search, and then slowly started integrating text ads. "They're different," the masses cried. "They're unobtrusive and low bandwidth!" Yet here we are today and Google is now serving up loads of full-graphic ads, all views tracked by the Google Brain (the same one that knows what you search for, your email account if you use gmail, and so on), and yet the Google honeymoon continues. I think Google has achieved some enormous technical achievements, and some of their products are extraordinary (Google Maps is a fantastic use of existing technology, making the competition look like garbage), but I just don't buy into the mythology that Google is somehow exempt from the forces that drive every other corporation.

  .NET   Blogging   IT   Personal   Software Development   SQL 
Friday, September 23 2005

After finding a couple of minutes over the past couple of nights (tough when you have two young children), I finally got the survey/poll component put together, as you can see from a couple of the entries with attached surveys. Obviously these are mostly for entertainment purposes, and will only marginally track with reality (e.g. the motivated are more likely to vote, and they're more likely to encourage like minded people to vote, etc). Although none of the samples demonstrate it, the surveys allow for a multi-question format, which would allow for statistical correlations (e.g. "90% of the people who want to work for Google also say that Google is definitely not evil").

In any case it's a nice little multi-tier project with a Microsoft Access backend (as that's what my host provides), though I need to put together a SQL Server plug-in data module as well, which will be trivial (actually I'm using the OLEDB provider and a config file connection string, and technically the queries are all standard SQL, so with the same schema the same module should work. It's late and I'm tired, so I haven't really thought this through). It uses copious caching, so it's actually fairly performant (especially for a relatively low volume blog like this). Anyhoo, after I clean it up a bit, and add a basic administration page, I'm considering releasing the source. I'm sure there are plenty of craptacular competitors that do the same thing, but I think it's pretty elegant.

Saturday, September 24 2005

One of my goals with the survey component was to ensure that it was extremely lightweight, consuming the absolute minimum of resources. Doing so requires not only a good database design and access patterns, but also necessitates the addition of potentially error prone caching and optimization code: Building a little survey component is trivial, but trying to do so while ensuring that you hit the database as seldom as possible, all while personalizing for each user and avoiding "vote stuffing", gets a lot more interesting (and, quite honestly, fun. Straightforward projects are never fun).

I mention this because it's always a tough debate - a good percentage of issues in the field have occurred because of this sort of optimization, with caching in particular being the root of a lot of issues.

As an aside, I don't plan on sticking a survey on each and every entry - in fact they should be quite rare, such as when a topic is particularly contentious. The survey with this entry is just for fun.

  .NET   Blogging   IT   Software Development   SQL 
Saturday, September 24 2005

This past Thursday - September 22nd, 2005 - saw a panic among the public here in Southern Ontario, with lines snaking out of every gas station. An onslaught of customers that continued until the tanks were empty. Major roadways were clogged with parked cars, and commuting became even worse than it normally is. It was, quite honestly, an embarrassment.

The root of the problem was largely fictitious hearsay, coupled with a couple of isolated, price-gouging gas outlets. "They're selling it for $3.00 a liter in <insert some remote town>!" people would eagerly relay. I heard this hearsay, coming from a person who heard-it-from-a-person, from five separate people that day, each time with a different town hosting the unconfirmed harbinger of pricing doom (and of course the first clue that something was amiss was the origins of the pricing myth - it was always some remote town. Do remote towns have a more integrated communication network, and thus can respond to market details or pricing information more quickly than in the city? Of course not, and the opposite is generally the case, yet here were people all rushing in droves to the local gas outlet selling gas for $0.99, thinking that they were taking advantage of it before the station operator got wise to the inside information that only they, and the thousands around them, knew). 

The worst culprit of all was the media: CHUM FM, a major radio station in this area, seemed to be commenting on the mythical hike in the price of gas every half an hour - not only the entertainment disc jockeys, but even the news reporters. Not once did I hear them actually confirm, or refute, these rumors. Given the importance and presumed responsibility required of media in that sort of case, I found this absolutely deplorable. They were, of course, just playing along with the theme of the major outlets like CNN, which have been stoking the gas pricing fears to manufacture news, pulling out every halfwit commentator they can find to tell the audience that "if the hurricane hits the refineries and if it does considerable damage and if...then gas prices could go up". A hurricane killing and damaging isn't news enough, so the gas-price angle is being exploited to the max. Were hurricanes just invented this year or something? I'd swear I heard of prior art...

Of course the public is more vulnerable to this sort of message now, given the spike to $1.50/liter here in the wake of hurricane Katrina, so people just accepted it and instantly started relaying it, making their own plans to fill up their car, boat, van, and lawnmowers. Soon the rush was on to buy more fuel in a day than is normally bought in a week, and tanks were emptied, which fuels panic even more. Ridiculous.

I think there are two lessons (among many others) that can be learned from this situation:

  • Those few stations that did hike their prices, some to $1.75 or so, to exploit the situation, should be punished severely by consumers. Let me make it clear - I don't think those gas station owners were evil or immoral, and honestly I think there is a lot of logic to their actions (if people are going to line up and eagerly pay $1.75, then why not charge it?), but I'm thinking in terms of consumers and our ability to enact a consumer democracy through our wallets to avoid this in the future: If your local gas station exploited the panic, never, ever buy gas or anything else there again. There are a lot of alternatives for most consumers. Of course I know that no one would bother with this sort of behaviour, immediately falling on the destructive "my vote doesn't make a difference" mentality.
  • We really, really need monitoring and control (not central control of prices, but rather monitoring to ensure that it really is a competitive supply/demand industry without collusion, and that the market forces are rational) of gas prices. Gas is not like regular consumer goods, and is absolutely critical to our society. I've made a proposal for this before.

Ultimately I think we need to accept that as more of the world develops, without an increase in the ongoing supply of fuels, the price will simply continue to go up. That seems inevitable, and I'm sure in 5 years we'll look back at $2.00 a liter fondly. But we need to ensure that the shock is absorbed well and accommodated, and that nefarious agents aren't profiteering from panic.

  Personal 
Sunday, September 25 2005

I've always had a terrible memory.

I frequently have to calculate how old I am when asked (versus simply remembering), and I regularly quiz myself on the birthday of loved ones, trying to pound the information deep into my memory banks. People's names only really stick with me after several dozen encounters, and faces aren't much better. An embarrassing number of times I've encountered childhood acquaintances and distant (or even near) family and failed to realize who they were.

Lunch

It certainly isn't that I intend to be disrespectful - my brain just isn't wired to put information into long term storage on first (or second, or third...) encounter, and it punts (or loses the pointer to) older data. In many cases it's like a filter on the long term archive simply refuses to persist the information, and less practical information simply never gets logged away regardless of my conscious opinion about it. For instance I am a longtime fan of the Family Guy and the Simpsons, but it's very rare that I can verbatim quote a funny scene, outing me as a poseur to the quote spewing human-SNPPs. At most I remember generalities ("That episode about all the people coming to look at the leaves").

This is just the way my DNA (along with environment) made me.

I've been this way since the beginnings of my memories (ironic, no?). In junior high I remember doing very well in tests based upon figuring out the algorithms and techniques on demand (e.g. during a critical test) myself. I did this using heuristics of what I was taught, rather than the more traditional rote application of literal knowledge. Well, to be honest a part of it was laziness, but a lot of it was just the way my brain is wired to learn. I carried this technique on to high school and post-secondary, and then to every industry certification since. It has served me very well.

This fundamental of my thought process carries over to software development as well, which is why I write this here - I am not, and have never been, a walking MSDN Library. Simple terminology for everyday patterns and practices escape me if they aren't the sort of thing that one realistically uses in regular conversations with peers (e.g. outside of the occasional architectural astronaut bravado buzzword talk). When quizzed what software development books I like most, it is rare when I can name more than one title (and the recollection is usually based upon logical correlations of content with likely titles. e.g. "The book about how 9 women can't make a baby in one month...month...The Mythical Man Month!"), yet I've read dozens of software development and process tomes. It's even less likely that I remember the author ("who wrote TMMM? Steve O'Connell? No? Let me just hit Google...").

To draw from a more common example, I often get asked "Have you ever...", based upon my experience in this industry, and I have little to offer on-demand in regards to specifics: I simply do not remember the fringe function calls of projects past, even if I battled it in a dozen different ways. I consult computerized references regularly (MSDN Library, Google, Google Groups, and so on), even for everyday library functions and classes, and maintain archives of old code to remind myself of solutions and techniques I discovered previously (e.g. "I solved something similar in a project 3 years ago..let me check the source"). I even built a from-scratch implementation of AES (the cryptography artist formerly known as Rijndael), and submitted changes to the reference code, yet I remember absolutely nothing about that cryptography codebase now that it isn't pertinent for me.

So given all of this, is the point that I'm like a perpetual newbie, always starting at square one? Absolutely not. Instead of remembering literals and absolutes, I remember heuristics and mental hints - little brain guideposts that allow me to solve difficult problems in very little time. In code I catalog which projects (both those of my own and others) solved particular problems, and I can quickly reference them and get definitive answers (rather than speculative answers). While I'm not the sort of type that can endlessly recite facts and details about esoteric kernel calls, I do manage to find exactly the information that I need immediately using modern tools (I've always been great at making search engines sing. One manager many years back was sure that I was hoarding some techniques, because I always managed to find solutions to vexing problems. The key was that I had enough mental hints to narrow down to specifically where the solution was hidden). My memory technique, coupled with an excellent problem solving ability, has made me an extremely productive, capable developer and application designer. Let's say I'm a cheetah, and tools like the MSDN Library and Intellisense are hugely beneficial in my hunting arsenal. I'm a cheetah with a crossbow.

There is another type of developer - let's call them the elephant. The elephant remembers everything about every technology, every function call, and exactly how to solve specific types of problems in a very literal way. The elephant can remember every detail of things that interest them (e.g. Star Trek trivia), and could probably operate fairly effectively without any sort of online, or even offline, help. The elephant often makes a very capable developer, and is a very capable complement to any teams. The elephant functions based upon precedent and a cumulation of literal knowledge.

Of course there are an endless number of points in between, such as there are with most human traits.

I mention all of this after hearing yet another peer recounting their experience with a prospective employer. Like many before, they were given an "aptitude" test (because years of experience and a 4-year university degree just don't demonstrate much anymore, apparently) where the test was a paper/verbal quiz of select esoteric elements of languages and libraries.

I just don't get this.

Are organizations looking to hire an expensive organic version of manpages? Do they really, truly think that this is a logical way of evaluating skill? Are they afraid that all reference material will disappear and they'll be at the forefront of reimplementing mankind's knowledge?

Come on industry, grow the heck up. Quit these nonsensical and meaningless tests. Just because someone on your team could think up what they think are "clever" questions to trip up prospects doesn't mean that this is even marginally effective at pruning your candidates (you might as well roll dice). Getting developers to code on paper (when many of them have awkward, barely functioning handwriting given that they've been typing for most of their lives) is just as destructive, despite all of the dubious arguments used to support it..

I can draw from personal experience as well: Several years back I did an interview with a firm (for a position that I turned down), and I still remember that the answer to one particularly hilarious question was the SQL Server function PATINDEX. I've designed and implemented several large scale, very advanced database systems on SQL Server, using the most advanced techniques and practices. In none of them did I use the function PATINDEX (it's one of those functions that you'd better have a very good justification for using. It largely appears in very poor designs). It's not that I hadn't come across it - I had in several tragic designs that I was called in to fix - but it certainly wasn't top-of-the-mind material. Yet here it was, being used as a test of whether I had an "advanced" knowledge of SQL Server. This is fairly typical nowadays, where candidates will find their knowledge "tested" by being quizzed about some fringe technology that the interviewer happened to be working on that week.

If you want to assess your candidates, give them a realistic environment - call them in, give them a workstation, and ask them to solve a particular problem. Let them use the online resources that they would regularly have available (e.g. no online rooms of experts waiting to help them in their assessment, unless they can promise to have the same once they're on fulltime), give them the normal reference material, and let them go wild. At the end look at what solution they've developed. If necessary screen capture their activities (with their knowledge) so you can see their process. Hire the people who work in the way you want. Even better hire the people who yield the results you want, regardless of their personal techniques.

Of course if you really do operate without reference material, you code on lined paper, and you largely deal in esoterics, then perhaps you might want to continue with the current norm of interviewing.

Earlier EntriesLater Entries

Dennis Forbes - Dennis Forbes is a Toronto-based software architect and technology writer