Assess That Position

Monster has some good stuff sometimes. Their emails arrive in my inbox regularly and every now and then something good pops up. Here are some excerpts from "Know When to Take the Assignment," which is officially about considering temporary assignments:

It's critical to your professional identity and your career that you not allow yourself to fall for mediocre clients and mediocre projects.

You have to strive for impact.

Assignments should either give you experience with new skills, help solidify your expertise and focus on a particular discipline or fill in gaps where you know you don't have enough experience.

Ask questions such as:

• What qualities do the most successful employees in your company possess?
• How does the team I'll be working with handle conflict or differing opinions?
• How does the company recognize employee accomplishments?
• What is the management style of the person I'll be reporting to?
• Describe the personalities and styles of the company leaders.
• What are the company's values?
• Which philanthropic charities does the company support?

Good advice for any position, not just a temp or contracting assignment.

How to Hire an IT Sales Professional

How to Hire an IT Sales Professional? I wish I knew the answer to this. Most sales people, good and bad, are usually very good at talking and selling themselves. That means you could be their meat and end up getting snowed. So what can you believe?

They need a book of contacts to harvest leads, certainly. You need to know it's real. They need to show you good references, a whole bunch, and you need to follow up on those and sniff out the candidate's track record. You've already been assured by him that it's stellar, you need to verify that.

Does she listen? Sales people are great at talking. The bad ones do that much better than anything else. The good ones hear. Does she understand the nuances when you explain things? Does she get the details, not just the concept?

Has he been there and done that? Are you looking at a guy who has been in a completely different industry and assures you, by analogy and example, how his experience transfers to your industry? Be wary. It can work, but it's another hurdle, another red flag.

What is the candidate's personality? I hear about these archetypes for sales people, the hunter and the farmer. The former is aggressive, the hard sell type. The other is nurturing, establishes consensus and build relationships. I don't know why there is this idea of mutual exclusivity. You really don't need a hunter or a farmer after all. You need a skilled business rep who can communicate and close deals, knows when to push and knows when to wait, knows when to step up and knows when to turn it over to others in your organization. He can drive a hard bargain as well as cooperate. He is respected, not disdained.

What is the candidate expecting? Is he sitting in his chair all day? Is he out and about? Commission, tools to help him do his job (company car?), periodic review of his goals... and you? What are you expecting? Getting the wrong person is a big setback and can take a long time to recover from. Hire him on a trial basis, set the goals, and make the decision to retain or terminate at the close.

Here is an example of a job description for a sales rep at MWI. It's pretty clear:

What We're Not Interested In

• Somebody to watch the phones. We've already got someone doing that for minimum wage.

What We Are Interested In

• Somebody who is out of the office 90% of the time meeting with people.
• A lead generator and closer. Find new business, get them interested, and close the deal. We'll take care of the rest.

What We're Offering

• 20% commission on project-based sales. You sell a $20K website, you get $4K.
• On SEO there is an initial commission plus a six-month residual. You close a $5K per month SEO deal and you get a commission equal to the monthly fee, plus 20% of the monthly fees for the next six months. That means if you closed one $5K/month deal per month you'd be bringing in $132K per year in commissions. A salesperson with the right experience, connections, and skills should be able to do double or triple that.
• Health benefits. Candidates who prove themselves during a two-month trial period will be offered full-time employment which includes health benefits.
• And of course, the soft stuff. A nice work environment, a growing, exciting industry, cool co-workers without egos, and almost complete autonomy.
• If you'd like to get a better idea of how we sell our search engine marketing services, download our search engine marketing sales presentation.

That's good. Get someone who will do that!

Kick the Oil Habit?

This study by the Pacific Northwest Laboratory, a "research organization" (I guess you'd call it) that is jointly run by the DOE and Battelle, finds that the U.S. could power 84% of its vehicles if they were "plug-in hybrids." This is one of a number of promising ideas. I'd still want at least a back up gas tank for those times the power goes out around here.

Management Getaway

Let us, then, be up and doing,
With a heart for any fate;
Still achieving, still pursuing,
Learn to labour and to wait.

A Psalm of Life
William Wadsworth Longfellow

Longfellow could have been writing about the antithesis of the move into management that knowledge workers typically feel is their inevitable career path. Away from the daily problem solving and coding, and the "just get it done" mentality that is often unfortunately imposed. An "escape" to a world where they can have meetings, interface with suits, say the word "verticals" a lot and pretend their documents and MS Project files are part of the vision that drives the organization's success. Woefully misguided are these aspiring managers.

The trouble is, completely flocking from the daily doing and the gusto attitude of the alpha geek can often turn one into the "just-get-it-done-according-to-my-'plan' " managerial type. These managers may, due to their deteriorating expertise, gradually help prevent an organization from integrating its skills and internal knowledge that it needs to compete in the tech industry. In other words, the manager fleeing from his inner geek may help his company disintegrate, in many senses of the word. Like minded managers will coach him along that path, blissfully thinking they are right. People who are now becoming gradually less informed are making key decisions.

Good tech companies do not let managers get themselves completely out of the tech side of the business. They make an effort to keep them in the game at some level. Take Scott Guthrie at Microsoft. Scott is in charge of the teams that build the .NET CLR, ASP.NET, IIS, WPF and more. That's a lot of responsibility. Yet he spends significant time every week writing code, to stay sharp and help make better decisions. Good managers understand that the business dictates some of the skills they must maintain. A tech business dictates that you have to maintain quite a bit of tech knowledge if you are going to make good decisions and therefore be a good manager.

The trouble for organizations is that good managers are hard to come by. "Good" means many things. It includes realizing independently what will make you effective. It also includes delegating things that are not completely part of your expertise and granting autonomy to those implementing these pesky details. Good managers know that this means helping those who will make their team look good, and sharing in that success. Bad managers think they have to appear to think of, know, say and direct everything.

The result is that the fine knowledge plebes often have to communicate with managers that really don't understand their jobs anymore, and sometimes with managers who are just ineffective and blissfully unaware. They have checked out, and they mistakenly think that is a logical progression for their managerial career track. The temptation to "graduate" into management often begets a lackadaisical outlook. Things change rapidly. The luxury of checking out of the process of keeping up is a siren song of organizational ruin.

If you are going to be an effective manager in the tech field, you need to keep your chops sharp. Not daily nuts and bolts sharp, but the more you understand the more effective you will be.

Consensus

Brad Abrams at Microsoft has a great post about how to build support for an idea on his blog.

Exception and ApplicationException

I had this straight in .Net 1.x: Derive custom exceptions from System.Exception, not from ApplicationException. The reasoning: you want your exception hierarchies to be wide and shallow, not deep, and that ApplicationException didn't add anything to Exception anyway. Jeffrey Richter notes that the difference between the two types of exceptions were originally to signal a CLR exception vs. one thrown from an application, but that this distinction was not followed consistently. Therefore, stick with System.Exception.

In .Net 2.0 we seem to have conflicting directives from Microsoft, which I am assuming is an error. The MTS 70-536 exam study materials point out (on p.24 of the training kit book) that we should derive from ApplicationException. Seems to fly in the face of the previous recommendation and based on the original .Net 1.x recommendations which were revised. The latest MSDN docs appear to recommend deriving custom exceptions from System.Exception.

I'm going to stick with System.Exception as the base class for custom exceptions. Don't know why I ended up bothered by this today.

Apple Rocks but What is Missing?

More concerns about the iPhone, which I otherwise love as already stated:

• Battery à la the iPod, or can we replace it when it's old and tired?
• Support for Office docs?
• Support for Exchange Server?
• Can we expand it by installing our own software (like Palm, Symbian, and Microsoft phones all allow)?
  

Fools and Fanatics

The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.

- Bertrand Russell

C# and VB.Net

Though this is now a barely simmering debate, my thoughts about which great .Net language to choose is pretty simple -- choose the better one.

For almost a decade I wrote applications using nothing but VB 3, 4, 5, and 6, or VBA (in Access), or VBScript (in old ASP), along with HTML a smattering of javascript, and quite a bit of SQL (T-SQL and Access SQL) for every application. But it was largely some form of VB, all day long, that I used to create my bread and butter apps. Before that was Paradox (PAL), Basic, and some macro languages for business apps. VB, though, became my career.

When .Net came out of beta in late 2001, I began a project writing a source code repository with content in both VB.Net and C#. I had to not only learn the .Net framework but also a fair bit that I was able to avoid in VB about object oriented design and programming (two different but very related things). For me, the new framework and OOD/P paradigm were the most effort, but learning two new languages thrown on top added to the effort.

Yes, two new languages. VB and VB.Net, while similar in syntax, are very different beasts.

So, as a long time VB/VBA/VBScript programmer learning both VB.NET and C#, it seems a no-brainer which one I took up and looked to as the better language...

It is C#. Why?

• It is more concise, I would even say more elegant than VB.Net. The verbosity of VB.Net becomes stressful. The scannability of well-contructed C# is very good in comparison. I can, in short, read well-done C# code much more easily than well-done VB.Net.
  
• The amount of crappy VB.Net code due to VB developers diving into .Net is astounding, and VB.Net unfortunately lets you get away with a lot of sloppiness. I may get to explaining that in another post, I have a lot to say about it...
• Developer tools tend to be done for C# more than VB.Net. In fact, many only support C#. Though that is changing, VB.Net support is often an afterthought.
• The background compiler in VB.Net can sometimes be nice when you're making quick changes, but it is more often intrusive and stressful while coding. For example, if I want move off an incomplete line to copy and paste something else, I don't need the squiggles or the closing parens added when VB.Net doesn't know what I mean; tools like CodeRush are interfered with by the background VB.Net compile thread, especially in Visual Studio 2003; moreover, try VB.Net on a large solution (I have) and you will run into serious frustration and the need to restart Visual Studio regularly during your day to clear the futzed state the IDE gets in.
• C# has always caught things like unused variables, unreachable code, and non-void methods that don't return a value as warnings or errors. VB.Net may have solved one or two of these in the 2005 release, though.
• Option Strict and Option Explicit. These legacy VB-isms should have been thrown out. Other than the need for this in some Office Automation code, I can't see why you would ever want to not have these both ON. And way too many classic VB developers who come to .Net don't turn them on at both the project and source file level.
• I hate the line continuation character, and you think I would have gotten used to it from VB, but I just never have liked it. Especially in .Net when you're working with attributes, the C# syntax is much less confusing, more writable and just easy to do.
• Array syntax in VB and VB.Net, they just should never have used parens instead of square brackets when VB.Net came along. The thing that ticks me off most is when I go back to a C# project after working on a VB.Net project and keep smacking myself when I use parens for an array and hit compile errors. I hate that.
  

What do I like better about VB.Net than C#?

• Sometimes I actually like the background compile! But not usually, and I wish it could be simply turned off.
• Delegates and using WithEvents to simplify event handling. In VB.Net, that is a real boon to developer efficiency.
  

Is this a useful, informative post? Probably not, unless you're currently (and temporarily) a VB.Net programmer, though. Then, you should read it!

A more important point is that if you work with .Net, you need to know BOTH of these languages, no excuses.

Apple Rocks the World

Steve Jobs' announcement at yesterday's Macworld conference about the iPhone is big. I have been reading a variety of opinions about how this impacts the world of cell phones, including Nokia, RIM and the like. I think as this news is digested, there is still more upside from this announcement if you're an investor or a potential investor in apple, as I believe people will realize the following:

• So called "smartphones" today are generally awful. Usability is poor, too many compromises (some have touch screens, some don't; some have good keyboards, some are lousy; some are actually decent phones and are mediocre at their other functions, most are not so good; some function as music players, others can but not well, or have incompatible headphone jacks, on and on...), just too much to not like in any example. I have looked at the Blackjack, Cingular 8525, the Motorola Q, various Blackberries and Treos. They all have some compelling features (keyboard, push mail, WiFi on the 8525) and some infuriating omissions (no touch screen on the Blackjack, the Windows OS is problematic, the Palm OS is showing its age, the Blackberry is great for mail but mediocre for everything else). The iPhone has it all, and the non-phone features are finally all there and appear to be done right.
  
• Standard form factor. Look around, these things are anywhere from really thin, too thick, too heavy, unable to fit into a jeans pocket -- there is no standard. Apple is going to become the de facto form factor and design standard. Its simple design looks to make "gadget use tension" evaporate. I am not going to have to concentrate so hard and make five clicks with a crappy scroll wheel/button to record a voice memo to myself, for example.
  
• We are sick of carrying around all these specialized gadgets. A smartphone with tons of unused memory sits in my bag next to my iRiver 40gb mp3 player, my Garmin GPS, and my laptop which is with me even on occasions where I just may use it but only need to read email and surf. I don't have a PDA, but many people throw that into the mix, too. Here is where Apple is really separating itself from the lackluster crowd. This device looks to make the need for separate devices to handle these features largely obsolete right when it is launched in June, and eventually, completely obsolete.
  
• Connectivity. Every smartphone these days should have Bluetooth 2.0, WiFi b and g, as well as its carrier's 3G access built in. They usually have one and a half or two out of three. WiFi is the iPhone's coup de grace. The Blackjack should have this. The Nokia E62 should have this. Most smartphones have gorgeous screens and close to enough real estate to let you surf using whatever connection your home, office or coffee shop infrastructure offers. Most carriers cripple the WiFi so that you are forced to use their expensive 3G plans for internet access. Unless you travel a lot or are otherwise forced, you simply pull out another device to surf and check email. A device with a beautiful screen like the iPhone, and usable in landscape mode makes a great hand-held browser.
  

In short, this is the holy grail. One device that does phone, email, messaging, web browsing, and photo and video viewing.

Open questions:

• Will the on-screen keyboard be usable?
• Is the case going to be durable (see how an old iPod wears, not too well)
• Will 3G access be available soon? (It won't be for the June release)
• Is it as easy to use as all those iPhone videos on the web make it seem?
• Is the call quality great?
• Does it "boot up" or just turn on?
• I'm still lukewarm about iTunes, will that improve? It seems integral to this device.
• Does it come with a charger, a decent case, and hopefully a car charger?
• Does bluetooth work as well as it should?
• Will a competitor emerge that gets the design just as right?
• Is the memory expandable?
  

The Construction Analogy

This is a common way for people with little experience to analyze or (gasp) explain the process of creating software. The problem is, building a house and creating a custom software application have little in common. Not nothing, but very, very little.

Here is a classic situation. Joe the sales guy is explaining his company's software development process to a potential client. The client questions why a large requirements document is necessary. Joe gets animated (apparently, he's really experienced) and says, "Well, it's like you're building a house. You need a blueprint. Your builder needs to know how many rooms, where the plumbing, electrical and HVAC goes, where the bathrooms are... heck, it's not like you can get half way through building a 2500 square foot colonial and then decide that you really need a 4000 square foot ranch."

Actually, the "2500 square foot colonial --> 4000 square foot ranch" is exactly what you frequently do on a software project. In fact, if you can't do that for your clients you're likely locked into a very poor development process. But there is much more to why this analogy has little merit.

How about some more Joe-isms about software development:

• "You can't just rip apart the foundation while you're finishing the attic." Yes, you can.
• "You can't finish a brick house and then decide the windows are too narrow and change them." Yes, you can.
• "It would be like taking a single family house and turning it into an apartment." What's the big deal about that?

Construction workers are not typing code. They can't copy and paste. They have to deal with gravity, building codes, materials suppliers, the weather. We don't have these issues in Windows, .Net, or the web.

When you build a house, you have to follow the waterfall methodology. That is, you need a plan that is complete, then you begin construction, starting with excavating a hole in the ground for the foundation, then you pour the concrete, then you frame the ground floor, then you frame the walls, then the roof, etc. After that, the building inspector can look things over and approve it. Only then can the electrician come in and run the wiring. Et cetera.

The waterfall process, which is so core to the construction industry, is a very poor approach for most (but not all) software development. Why is it poor? Because it locks you into a fixed course in a process that requires constant discovery, revision and reaction to changing business requirements, stakeholder feedback, and competitive pressures. Your building just needs to get finished so the family can move in, or so the software company can set up its servers and start writing some code! Waterfall may be a good process (I'm not 100% convinced, but it may be) if the software you are creating is similar to many other projects you've done. Of course, if that's the case, you might be better off just finishing it one last time, boxing it up, and selling it at CompUSA for $49.99. You don't need a process for that ever again.

In what I feel is a more sinister result of this construction analogy, we have people known as project managers who have been trained to bless this waterfall approach to software development. I recently had a conversation on a flight to visit a client with a woman who works for EDS. She was a project manager and was complaining about how her clients are constantly changing their minds about software that was "under construction." I tried to think of a project I have worked on where that did not happen. I can't recall a single project.

The PMI (and I am not an expert at their certification but have worked with people who are PMI certified) seems to endorse these staid methodologies. I may be very wrong about their focus, but when I read an overview of the PMP credential, I see that it includes the following: "initiating the project, planning the project, executing the project, monitoring and controlling the project, closing the project..." This smacks of a construction project in my book, not software development. The few people I have experience working with who are PMP certified seem to endorse this. Again, in some projects this may be a valid approach (and again, I'm not convinced it is, but it could be sometimes).

So does all this mean I feel that planning and project management and some structure is bad for software development? No. You need to plan, manage, and rely on some structure. But it is different for a construction project than it is for a software project. And thankfully, the software industry is responding very well. The problems of estimating, collaborating, managing and creating software have been studied by a lot of very smart people. Martin Fowler, Scott Ambler, Alistair Cockburn, Grady Booch, Kent Beck, Ken Schwaber, and heck, a lot of mere mortals, even me.

The construction analogy is way off for most software projects. Sometimes it is good for explaining to a client the challenges in estimating costs, for example, or to illustrate the complexity (at a very high level) of developing software. I think any other use of this analogy stretches its validity, and I think people have to stop raising it as justification for almost everything.

The construction analogy is not valid. In fact, software development is mostly a unique activity.

Meetings and Goals

Warren Buffet on CNBC tonight tells Liz Clayman that he doesn't have meetings with the managers of the businesses he owns, he just tells them what he expects. The woman who runs Borsheim's jewelry, which Warren Buffet owns, says at the start of each year, he sends her a single sheet of paper with the business goals for the year.

From my own experience, the amount of meetings tends to run inversely to the focus on goals. Meetings are often where poor managers assert their control, or stoke their egos. Very few things get resolved at planned meetings, fewer still when they are lengthy.

The less formal a meeting, the more effective it is. Short, frequent chats with team members can replace a lengthy weekly meeting with much better effect.

Meetings are good for brainstorming, mediocre for motivating, and poor for communicating in a level, focused, ego-free manner.

If you have to have a meeting, it needs to have a goal. Send out an agenda, keep it short and focused, and end it with a summary of the action items agreed upon to meet the goal. Follow up, too.