Author: dlambert

When a company goes through the kind of turmoil I've seen recently, there are frequently opportunities to pick up some consulting hours to help with the transition. I got a shot over the bow last week: "Hypothetically, what would your rate be to do 'XYZ'?" I hadn't given it an awful lot of thought, but suddenly found it was time to do some "back of the envelope" calculations. I found a link that was helpful for me, and I dropped some of my calculations into an Excel spreadsheet that's available for you to download.
First, it may be helpful to consider whether you have any preconceived ideas about what you think your rate might be. They might turn out to be way off, but it'll be useful later to see whether the rate you compute is anywhere near the rate you thought you'd end up with.

Next, grab a copy of the spreadsheet and open it. This spreadsheet is based on a thread about the same subject on the Joel on Software site.

There are just a few numbers in here for you to adjust. I'll comment on them briefly here.

• Salary. This is your W2-equivalent salary, or what you'd expect to make if you worked for someone else.
• Hardware-software budget. After all, nobody's going to buy you that new laptop but you.
• Insurance. Health, liability, and other insurance normally provided by your employer
• Billable hours per week. This is the first of three factors designed to account for the fact that as a contractor, not all of your hours will be billable This is an area you'll want to give some careful thought to, as I'll discuss below.
• Working weeks. You want vacation? Sick time? Holidays?
• Utilization rate. Another billable hours factor. See below

The most important part of the spreadsheet to fiddle with will be the factors in the Revenue area. Generally, you're trying to account for risk here. There's nobody paying you if you find yourself without a client, so you need to plan for downtime to line up that next deal, as well as all the incidental time-wasters that come up during the week.

You can play with both the hours / week factor and the utilization rate factor to see what effect they have on your rate, but remember to leave a few hours per week for administrative tasks like accounting and IT support. You may also want to adjust the utilization rate to account for the length of your contract. If you've got a year-long contract, for instance, you can get a whole lot higher utilization than if you have a series of one-week contracts.

Even with a long-term contract, though, don't go to 100% utilization, since there will still be time spent at some point lining up the next gig, not to mention education, training, and decompression time. In general, the more confident you are that you'll always have another gig spun up and ready to go when another one finishes, the closer you can approach 100% utilization, but remember that 80% is considered a very healthy utilization for consultants that have a supporting crew selling deals for them.

There's clearly a lot more sophistication that could be built into this model, but this should serve to help structure your "back of the envelope" scribblings a bit. Good luck!

A couple months ago, CIO had a great article on open source models: Free Code for Sale: The New Business of Open Source. The really nice part about this article is not that the content is especially deep (it isn't), but that it's a great executive summary of what's going on out there. Having the article show up in CIO also lends real legitimacy to the topic of open source. The article does a good job of descriibing the real business models at work here -- this is more than just hobbyists hacking away on code in their spare hours. I've referenced this article a couple of times already to people who understand the software industry in general, and want to learn more about this aspect of the business.

It's been an eventful week.

Last Friday, I found out that the company where I've been working for the last seven years was shutting its doors forever. I'd joined Resolution EBS as a CRM consultant, and ended up building a commercial Business Rules Engine product. Now, I had the weekend to think about what I was going to do next.
It was pretty emotional at work on Friday, and Monday, too, when everyone came into the office to clean up their desks. I've been working with most of these guys -- heck, I hired most of them -- for several years, and it was a lot of change to absorb in a short period of time. As you can imagine, there was a lot of shock, a lot of disillusionment, and a little anger, too. The normal stuff.

It'll pass, but not for a while.

I've been through changes like this before, but you never really get used to them. My first job out of college was at a little insurance company that ended up getting acquired by a larger insurance company. There, too, there came a day when the moving vans showed up in the parking lot, and everyone knew it was over. Unlike this time, though, we had some warning. This time was pretty abrupt.

So, I spent this week getting my job search cranked up. I've got some tips to post here on that subject, so if you happen to find yourself in similar straits, please check back from time to time or point your favorite RSS reader at my feed.

Finally, if you've been reading AppDev for a while, you'll notice that I've personalized the site a little bit. After all, I'm marketing me now, you know?

Oh, and "so long, and thanks for all the fish."

This is the obligatory "who is this guy and what makes him tick" page.  I'm lucky enough to have had a really broad background in software development, but all the really good bits are about connecting business and technology.  I'm comfortable with work in both areas, which makes me somewhat unique in this field, I believe.

Technically, I've run the gamut of Microsoft technologies, with most of my recent experience in the .Net stack.  I was introduced to Agile practices before they were fashionable, though I've seen variations done well and less-well a number of times since.  I got a chance to build commercial software and to grow a software team early in my career, and these remain the most exciting parts of being in software for me.

I'm still slogging through the aforementioned legacy code, and I keep stumbling upon places where the original coder just worked waaaayyy too hard. Case in point: I step into a page load subroutine in this ASP.Net code, and there's a page and a half worth of this:

strVar1 = Request("Var1")
If IsDBNull(strVar1) Then strVar1 = vbNullString
strVar2 = Request("Var2")
If IsDBNull(strVar2) Then strVar2 = vbNullString

There's an easier way.I'd already written some functions to handle DBNull values when pulling records out of the database:

Public Function intFromDB(ByVal dbField As Object) As Integer
    Try
        If Not (dbField Is System.DBNull.Value) Then
            Return Convert.ToInt32(dbField)
        End If
    Catch ex As Exception
    End Try
        Return 0   'DBNull or exception
End Function
Public Function strFromDB(ByVal dbField As Object) As String
    Try
        If Not (dbField Is System.DBNull.Value) Then
            Return Convert.ToString(dbField)
        End If
    Catch ex As Exception
    End Try
    Return ""   'DBNull or exception
End Function

(There are also functions for Dates and Doubles, but you get the idea). When I use this on the lines above, I get something a little more compact:

strVar1 = strFromDB(Request("Var1"))
strVar2 = strFromDB(Request("Var2"))

Update: as I work through this conversion, I've found a couple places where I could stand to have an optional param for default value.

I'm stuck doing some re-work on an inherited system. It's a long story. As I'm threading my way through this mess, however, I stumble on a function. It's a remarkable function. This function is a tiny monument to twisted intent, and it's certainly worth two minutes of your contemplation.
Ok, so before you behold the actual code, take a minute to think about all the other screwed up routines you've seen in your day. The routines that stretch on for pages and pages, with nested loops six-deep and variables whose scope has been violated back and forth and forth and back.

This isn't like that.

This one is subtle. Elegant. Take a look at this baby and see if you can appreciate the totality of its ruin.

Private Function Add(ByRef Which As Integer, ByVal HowMany As Integer)
    Which = Which + HowMany
End Function

Ok, so what's wrong with this code? How many of these did you get:

• It was found in an asp.net web page as vb.net code. Vb.net, of course, features the "+=" operator, which replaces this whole function rather neatly.
• The whole "which" and "howmany" naming convention reeks of "apples" and "oranges", not to mention its disdain for mundane pursuits like variable naming conventions.
• The "byval" and "byref" are actually correct here, but I've got $20 that says it was wrong the first time through. -g-
• It's a function, right? (what's it return?)

Whew ... boy, that was fun. I hope you enjoyed it, too.

When I communicate, I try hard to do so with some precision. I try to choose my words carefully, and I do my best to ensure that the message I speak is received and understood as I intend it to be. A common vocabulary really helps here. I'm a big fan of everyone meaning the same thing when they use a word.

I recently found myself struggling with some peers over what seemed to be a misunderstanding in terms - specifically, what is an ISV? I did some digging and found a general consensus - read on for results and commentary.The terms ISV, VAR, and SI are thrown around in a lot of discussions about our industry, particularly in discussions of markets and marketing. These terms are usually assumed to be universally-understood, and are usually meant to be exclusive; that is, every company falls into one and only one of these categories. As is often the case, a deeper understanding of the question reveals a little more complexity.

At a minimum, I question whether these terms are universally-understood. I'd expect nearly universal recognition of what the acronyms stand for (ISV=Independent Software Vendor, VAR=Value-Added Reseller, and SI=Systems Integrator). I don't believe, though, that everyone agrees on what these terms mean. When you add modifiers on top of the base terms (ie, micro-ISV), you can get to the point where you're talking about apples and oranges.

So faced with this lack of clarity, I did some googling. As you can imagine, I found a lot of links; these are the ones that stood out.

http://www.osisoft.com/5_1062.aspx This seemed to be the best overall breakdown. There are some very specific cues in here, which I found helpful in breaking through the fuzziness in terms.

http://software.ericsink.com/Small_ISV_Defined.html This definition distinguishes ISV's from VAR's (like SI's). Eric owns his own small ISV, so his site has lots of great information for that audience.

http://www.tsleads.com/how_we_help/channel_marketing.htm Here, all 'partners' grouped together. Not nearly as clean as the first definition, I think.

The themes and ideas that stood out in this search:

• The lines are blurry. As hard as we work to classify companies, we have to expect that each company is mainly in one category or another, but may have activities that fit in one or more of the other categories.
• ISV's make products. "Shrinkwrapped software" comes from ISV's. Even if all customers don't get exactly the same software (shrinkwrapped), if the company positions their software as a product, they're an ISV.
• SI's vs VAR's In general, SI's tend to be more software-oriented and more likely to contribute more custom work, while VAR's are more hardware-oriented and more likely to add small amounts of integration work - customization, for example.

Hopefully, these findings will be of some help. If you find any other helpful links, please let me know!

Remember this article? Remember when I suggested that BEA was in a unique position to lead Microsoft into the enterprise by supporting .Net in its servers? They're not all the way there yet, but here's the opening shot. Great move on BEA's part, and this can only help Microsoft.

I saw an article today that struck a nerve. I ran across it first on Slashdot, and then again on a Joel on Software forum post. The subject of the original article was the use of .Net in Vista. Richard Grimes has done what appears to be a pretty extensive analysis that shows MS isn't really using .Net for much. I posted a response on Slashdot and on JOS, and I've copied it here becuase it's my post. -g-My Response to Grimes' article:

There are some very legitimate reasons for us to look to Microsoft to use .Net extensively in their own products, including parts of the OS.

Readers here have seen the "dogfooding" idea, and have seen lots of arguments for why this makes sense in terms of getting requirements and design right. For a framework as sweeping and critical as .Net, that means real use in real apps by Microsoft. Now.

I don't think there are too many people who would expect low-level code to be written in .Net (kernel, drivers, etc.). But lots of stuff in a modern OS distribution is really bundled applications. As "JSD" pointed out, components like Outlook Express are bundled applications, not core OS components. Survey 1000 people and ask if they'd rather have sucure, bug-free browsing and email or have Outlook Express run 2% faster. Anyone have any doubt at all about the results?

Besides, the argument that unmanaged code is faster than managed code falls pretty flat on me. I completely agree that a good coder should be able to beat .Net with C++, but one of the reasons for a framework like .Net is that you want to make most apps perform very well, rather than just a few apps perform exceptionally well, and the rest run like crap or never get finished at all. A reasonably competent developer should be able to pick up a framework like .Net and use objects and data structures that are already developed, tested, and optimized. The reult may not be as fast as recoding the exact right algorithm in a native language, but for most developers and most development, they're going to end up with a better app than if they'd written it from scratch. That's why we use high-level languages, folks.

I think what this really points to is a combination of two factors, both of which are a little unsettling.

First, Microsoft is subject to the same product planning dynamics as the rest of us. For existing code and existing apps, virtually any incremental change will be more economical and less risky when built on an existing code base. Even the iffy cases will *appear* less risky when built on an existing code base. In order to undertake an architectural change, you have to have a pretty compelling reason to do so, and a good bit of courage to shelve the old stuff and move forward. This hasn't happened in a meaningful way in Vista.

Why is this disturbing? Simple. This points to the depth of reengineering that's going into making the OS and apps more stable and more secure. Very often, the right thing to do when fixing a bug is to find the specific pinprick in the code and patch it. Sometimes, however, when you start to accumulate enough bugs in one place, you have to consider whether there's a systemic problem in that area. In those cases, the only way to stop the bugs for good is to fix them systemically -- ie, to re-engineer that part of the app. If this is happening anywhere in the Vista code base, why wouldn't it be happening on .Net?

Which brings me to disturbing point #2. The release date for .Net 1.0 was what - 2002? And it's not like it snuck up on anyone. Let's give MS the benefit of the doubt and say that they all knew about it in 2000 / 2001, so it's been five years, easy. That's plenty of time to work out the bugs in a framework that they expect the rest of the world to build apps with. We've had the .1 releases, and we've had the hotfixes and service packs. It's got to be production-ready now, right? So why isn't it showing up in more of MS's own distributions?

It's either because any MS OS release is really a bunch of pretty small changes scattered across a staggering number of individual files and components such that MS can't justify rewriting any of the components, or because MS has, as Grimes concludes, lost confidence in .Net.

I'm a fan of .Net. I'd like to see it succeed. One of the critical factors for its success is for it to reach a critical mass. It's time for MS to step up and help .Net hit that critical mass.

I've always believed that a good illustration or diagram can be invaluable in explaining an idea. Just as people form first impressions of other people when they meet them, people form impressions about your ideas when they see them presented. A sketch on a napkin carries a sense of new-ness and excitement, but certainly not the expectation that a lot of details have been sorted out. Likewise, neat, professional illustrations convey confidence that the idea is valuable, important, and worth considering. You don't have to have a team of graphic artists working for you to make a good impression. Visio is already a powerful tool for creating diagrams and illustrations, and you can get even more mileage out of it by creating your own stencils. It's easy, and it'll help you create great drawings.

Why do you need a new stencil?

Visio's already got lots of stencils, or shapes - why would you need more? If you've ever tried to convey ideas specific to your industry or product, you know that the general-purpose shapes that come with Visio don't cover a lot of specialized needs. They also have a distinct style, which makes it hard to "brand" your drawings. But why not just drop pictures on your drawing? One reason is reusability - something that software professionals should be enthusiastic about. If you have a one-time picture, it's easy to drop it on your drawing and be done, but if you have an icon, symbol, or picture that you're going to use repeatedly, it makes sense to add it to a stencil. A good Visio shape will be sized correctly for use in Visio, and it will have connection handles so that you can hook it up to other shapes and lines. Typically, when you just drop a picture onto a Visio document, you don't take the time to set these things up, but if you do these things for your custom shapes, you'll be able to take advantage of them every time you use your shape.

Steps for a new Stencil

Ok, let's get started. I'm going to show you how to make a database shape that looks really nice. Of course, you can use the one that' built into Visio, but this one adds some real class to your doc. I'm using Visio 2003 here, but other versions are similar.

1. Pick your source image.

We're going to start with an image rendered by the Persistece of Vision (POV) raytracing program. I'm not going to attempt to do a POV tutorial here, but I've included the source for this image in the download if you want to play with it. The POV IDE lets you edit your file and render your changes. You'll find a Bitmap (bmp) right next to your source once you've rendered, and you can pick this up and start using it.

You can also grab an image from Google, a clipart CD, or a stock images web site.

2. Prepare the image.

Next, we'll resize the image and make sure its background is transparent. You'll need an image editor of some sort for this.  I'm using PhotoImpact, but Photoshop, GIMP, or any other image editor should work fine. First, select the part of your image you want to use, and make the rest of the image transparent. You want your shape to float over any other image content -- not clip it:

In PhotoImpact, the easiest way for me to do this is to select the part of the image I want using an "edge find" selector, then copy and paste into a new image. Next, create a new image with transparent background (a better tool would probably let you skip this step, but this allows me to create an image that's exactly the size of my selection), and paste the selection into it. Finally, change the properties of the selection to specify a transparent color (change the sensitivity or similarity to make white and gray, for instance, transparent).

Resize your image to a size appropriate for a Visio drawing. This will vary, of course, depending on the level of detail in your image and the size you expect to typically use in a drawing, but here's a point of reference: the small image in the download is 55 pixels wide by 70 pixels tall, and when used as-is in a Visio drawing, you end up with a shape that's 3/4" wide by an inch tall - a pretty good size.  You will be able to resize your image to be larger or smaller, of course, but if you leave your source image too large, you will cause every drawuing that uses that shape to consume more storage than it needs to.  On the other hand, if you make your image too small, you risk losing detail when your image is resized larger. Shoot for a size that's maybe just a bit larger than you think you need -- it'll survive resizing while consuming a reasonable amount of disk space.

When you're done editing, save the image as a PNG, which has the color depth of a JPG, but allows you to keep the transparent channel, like GIF.

3. New Stencil and Master.

Open Visio. The first time through, you want to create a new stencil to hold your new shape, so choose File ... Shapes ... New Stencil. You'll see a new panel in the Shapes area titled "Stencil1" or similar. Right-click on the title bar of this new stencil and Save As to change its name. By default, Visio will save your stencils into My Documents / My Shapes, which is pretty convenient compared to earlier releases of Visio.

Next, you want to create a new Shape, or Master. Right-click in area beneath the title bar and choose New Master. You should see a pop-up window similar to this:

Name your shape, and leave the other properties alone for now. Choose Ok, double-click your new Master's icon, and behold the big, empty grid. Don't worry - you're almost home.  Add your image onto the master by choosing Insert ... Picture ... From File... from the menu. Why not drag & drop? I've seen transparent-background images lose their transparency when dragged into Visio - if you Insert from the menu, this doesn't happen.

4. Add Connectors.

You'll want to adjust the zoom in Visio to make your shape easier to work with - try 200% or so. Next, we're going to add some connection points, because shapes in Visio are much more usable when they "stick" to one another properly. Choose the Connection Point Tool on the toolbar.  Now, hold the CTRL key and drop on some points. For a square or rectangular image, you'll want points top and bottom, left and right.  Larger shapes can use more connectors, and specialized shapes may call for points in specific locations - remember, these are the spots where lines and other shapes will attach, or snap to.

That's it - you're done! Click the document close "X" or choose File ... Close, and answer Yes to the prompt to save changes to your master. Your new shape is ready to use.

5. Repeat!

Once you've got a stencil, it's easy to add new masters. After a while, you'll have a collection of distinctive shapes that add a unique style to your drawings. Using them is easy and effective - they're going to work just like the shapes you already have.