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 + HowManyEnd 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.
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.
I'm sure this is abundantly apparent to anyone leafing through the articles on this site that I'm a big fan of RSS. Microsoft is finally starting to make some noise in this area, and it's the start of something big. Take a good look at what's happening right now in RSS, because in five years, this is going to make SOAP look like a fad.Ok, some really brief history for those new to RSS:
RSS began as a news syndication protocol. News-oriented sites could encode summary info about articles with links to their sites. This allowed "subscribers" to have a "Slashdot news" block on their site. Great viral marketing for both parties. Notice that this is strictly a B2B-type interaction.
With the advent of blogs, RSS started getting personal. More sites began using it, and more readers wanted it. Enter the RSS reader (RSS Bandit, NewsGator, etc.). It's now common for people to track dozens of feeds, and RSS feeds begin to displace email newsletter subscriptions. The practice of using RSS just to link back to the "real" article begins to fade (put your content in your feed, or don't bother me).
Podcasts. Did you know what a podcast was a year ago? 'Nuff said?
So here we are, early in 2006. What more can happen with RSS?
Lots, really. We're really still in the "early adopter" phase of RSS growth. Microsoft's push will help that along nicely. FireFox has already started to ramp people up on the concept of RSS, and IE7 will accelerate that growth. But there's a lot more to Microsoft's capabilities than are apparent at first.
Check out a couple links from Microsoft:
Using the Microsoft Feeds API This shows the API for the RSS feed that IE7 uses. Not too sexy, but you can see that the API is reasonably comprehensive, and it's getting built into IE7, which will eventually ensure that it's ubiquitous.
Simple Sharing Extensions for RSS and OPML This one's quite a bit fuzzier, but if you squint at it sideways, you can make out the shape of a killer platform. Let me explain:
The point of SSE is bi-directional synchronization. The thing about RSS to-date is that it's been strictly unidirectional. Publish-subscribe. Or don't subscribe. That's it for options. Now, you start opening up the possibility of synching back and forth, and things start to get interesting.
RSS is about to exit the "news" business.
The thing that makes RSS work is the ability to share "articles" in a universal format. As we've moved from news to blogs to podcasts, we're stating to see RSS used to publish "items" instead of "articles". The ubiquitous availability of RSS and the existence of a synching protocol for RSS mean that we've got a kick-ass collaboration engine just over the horizon.
There's a new calendaring app that's hit some Microsoft blogs recently: 30 boxes. Right now, it's best-known for its great use of AJAX, but it's also built to be able to share calendars, and this can give us a great glimpse into what's coming in a big way as RSS matures. Imagine subscribing to someone's calendar using an RSS mechanism, and then being able to update items. Obviously, there's a little matter of security to deal with, but the concept is pretty powerful.
When you consider the online-offline multi-client capabilities that RSS shows right now, this is going to really open up collaborative apps on a new scale. You can imagine how this works for a calendar. Open up the idea of "items" to include contacts, to-do's, etc., -- I hope we'll see stuff like this in the next Outlook. Hopefully, you can see this extending to enterprise stuff, too -- CRM info, stuff that's landing on portals right now, and so on. Clearly, none of these are things that can't be done now, but most of them are things that aren't being done because it's too difficult for users. The next generation of collaboration will marry the ease-of-use of today's best apps to the resilient, flexible infrastructure that RSS brings.
Now, the potholes. I already mentioned security. Versioning will need to be addressed. And finally, the scalability and reliability of Microsoft's RSS store will be mightily tested when this starts to take off. I expect the RSS store to turn into the new registry -- a brilliant idea that ends up being used for stuff far beyond its initial intended use. It'll probably need a little time to be able to handle everything that's going to be thrown at it.
I'm wading though the shambles of tattered source code left behind by an employee who used to work for another department in my company. It seems I"ve inherited the system that this guy and some of his also-departed co-workers put together for a customer of ours. There's documentation for the system, but nothing that documents anything I'd really want to know, so I'm surfing through the source code trying to soak up some intent, and I find one of the few classes that has any comments. In the comments, there's a version number. It's "0.1".Version 0.1??
What's that supposed to mean? As far as I can tell, this is a lame attempt to divert blame if a bug ever turns up. "A bug? Well, what're you getting so bent out of shape about?? It's only version 0.1!" As if this were really an indemnification against defects, freeing the developer from any real responsibility to get anything right.
What's the big hangup about taking enough responsibity for delivered code that you'll put a 1.0 on it? This wasn't a demo, it wasn't a prototype, and it wasn't still in testing. This code was delivered to the customer, and it's being used in production.
There's a principle at work here about not delivering something half-done to a customer. If you're about to deliver something that's worthy of a 0.1 version number -- stop! Your customer deserves better than this. If you're delivering something that's done, then guess what? You can slap a 1.0 on it with no qualms whatsoever. Let your version number be another clue that can tell you if you're delivering what you're supposed to be delivering.
There are two schools of thought when it comes to RSS feeds: show everything, or publish only "teasers" because you want to drive traffic to the web site by forcing click-throughs from the RSS feed. I've seen arguments both ways, but being an avid RSS consumer myself, I'm a big fan of feeds that push out all content, so I modified my feed to include the full text of all my articles.
Sad to say, but I'm surrounded on a daily basis by so much software that doesn't work very well that I'm really surprised when it does work.
My wife just called me with a UPS tracking number -- could I arrange for will-call and go pick it up? The resulting interaction I had with UPS's systems was pretty unique for me, in the sense that it worked, despite the complex systems I know are involved on the other end of the interaction.My wife gave me a tracking number and an 800-number to call - both printed on the slip that UPS left on the door. She could tell from the slip that UPS was trying to deliver a mail-order prescription, and that since the prescription was going to require a signature, tomorrow's delivery would fail too, so she asked me to pick it up at the UPS location.
The first thing I did was to log onto UPS.com and check the tracking number. Why? Just dumb curiosity, I guess. Sure enough, it showed the status as "first attempt made."
So I picked up the phone and dialed the number. An autmated attendant asked me for the number that was printed on the slip. "Oh, great," I thought -- I've been on the losing end of way too many of these engagements not to be skeptical. I didn't have any other options, though, so I read the number, fully expecting to be put on hold for ten minutes, only to be asked for the tracking number again when somebody finally got to my call.
But that didn't happen. Not five seconds after I'd read the number, the attendant came back with information about the shipment (tried to deliver today, going to deliver tomorrow -- is that ok?). I answered, "no" and was asked if I wanted to pick up the package. I was told it was still early enough to pick the package up today, and asked to provide a phone number. So far, so good. Finally, I was asked for a second number in case the first didn't work. I gave my work number, including an extension.
Throughout this exchange, there was a stunning lack of interference. No "please wait while we get the next question ready." No "please repeat your last answer - we didn't understand it." None of that. Not even with my work phone - I figured the extension would mess up the system for sure.
Very, very nice.
Now, I know that somewhere back in the bowels of some UPS data center, cams were turning and gears were whirring. I know that a complex matrix of SOA-compliant software components were exchanging protocols at a blistering pace. I didn't have to, though. I didn't have to give a hoot about routers and message busses, because the system just worked. The technology became invisible.
Just for grins, I updated the tracking page no more than ten seconds after I hung up the phone. Guess what? It showed that the package was being processed for will-call.
Outstanding.
Please, let this be a lesson for all of the customer dis-service centers out there that make me say my phone number, account number, name, whatever, then put me on hold and make me say them all over again when somebody finally gets on the like to abuse me in person.
Please let this also be a lesson to all the stupid automated systems that just aren't ready for prime time.
I know this is a problem for lots of people out there, because there's a major credit card company running a big ad campaign based on a "feature" in their customer service IVR system that lets you press "0" to speak with a real person. That's right, the general state of customer service is so lousy, that just the promise of being able to talk to a person is a major selling point!
Oh, yeah - one more thing. The UPS system promised that someone would call me back to confirm arrangements within an hour. They called in twenty-two minutes.
The December 15, 2005 issue of SDTimes has an interesting article on hiring tips and practices. On a couple of points, they hit bullseyes, but on some others, I think a hiring manager can do better. One thing is certain, though - if you are a hiring manager, this may be the most important thing you can do to influence the long-term success of your team, so be sure to give hiring the time and attention it deserves.
Read on for more, including specific improvements to the practices in the SDTimes article and some key traits you can look for in candidates.One of the parts of the SDTimes article I agree with in principle is trying to understand whether a candidate can think outside the box. I do not, however, advocate doing this by asking how many cars can fit on Manhattan. In my experience, I've seen some people who would handle that sort of question well, and I've seen some really good people who would completely self-destruct given that sort of non-sensical question.
A lot of this depends on the person and the role you're hiring for. If you're hiring a business analyst or designer, for example, it may be important for that person to be able to grasp the context around specific questions or statements, so for them, the "Manhattan" question might be interesting. For a technical role, however, you want out-of-the box thinking with respect to technical problems. Try putting them in a moon-launch scenario, for instance, and throw some failures at them. I once interviewed someone who came into the interview extremely nervous - to the extent he couldn't answer a question without stuttering and breaking up - and as the questions got technically harder, he got calmer and his answers got better and better. If you want a technical hero, this is your guy.
The SDTimes article also talks about team interviewing. Again, I agree with the article -- almost. I think it's important to point out a precursor to the interview that was left out of the article: the phone screen. Before you bring people in to meet the team, it's important that you've had a conversation with the candidate one-on-one.
Done properly, the phone screen accomplishes two things. First, you minimize waste. You clearly do not want someone coming into an interview unless they're going to be in the running for the job. It sucks a lot of time out of your team to do an interview right, and you don't want to waste that time. You will not get a proper sense for this just by reading a resume, though you should be able to rule some people out this way. Remember: when you complete a phone screen and are ready to schedule an on-site interview, you should legitimately feel that the candidate would be a good fit for the job. If you don't really feel this way, don't waste everyone's time with an interview.
The second thing you can accomplish with a phone screen is to give a candidate a sense of who you are and what you're looking for in a hire. You owe this to a candidate, and it will help them orient themselves for the interview. Given a little background, you can tell which candidates are going to take the time to think about how they can fit in your organization. You also get a chance here to let the candidate get to know you. Remember, you're (hopefully) going to ask this person to work for you, so they're going to be interviewing you, too. For these reasons, the phone screen is important enough that you should do them yourself. I've tried pawning this off on team members, and I'm convinced you don't get the right results from this.
The other problem I've got with the Team Interviewing part of the SDTimes article is the little bit about what you do when you don't have a unanimous decision. Bottom line here: you have to have everyone on board. Every team member has full veto power. That's why they're in the process. Note: this isn't the same as saying that any objection raised by any team member will shoot down a candidate - that's why you get everyone together after the interview and talk through their feedback. You can, and should, have people bringing objections into this meeting. If they don't, you need to work on their interview skills. Once you've talked through pros and cons, however, everyone gets a chance to say "no hire". If anyone -- anyone -- says "no", the candidate is history. You've hired all these guys (and hired well, I hope) and you have to trust that they have the best interests of the team at heart.
The last aspect of hiring to consider is skill set and character traits. It's common in our technical environment to get wrapped up in technical skill sets. While it is immensely helpful to know something about the programming languages and environments your team uses, don't lose sight of the fact that our technical environment changes quickly and inexorably day after day, year after year. It may be cliche, but it's true that the only thing that stays the same is change.
Given that change happens, you need to evaluate a candidate's ability to roll with that change and to pick up new tools and technologies. Attitude is an important predictor here. Some people can see technical change as an assault on their self-worth and identity. Trust me, you can't help these people. Some people are quite certain that their way of doing things is the best there can possibly be, bar none. You're not worthy of these people.
Instead, look for the people who are able to focus on an objective and drive toward it using whatever tools are at their disposal, including some they may never have used before. A few years ago, I used to quiz people on resources they used to stay up to date with technical change and to solve tough problems when they encountered them. Today, there's no excuse for instant satisfaction. There are very few problem that don't have answers in Google, for instance. I hired a guy that I completely believe would be capable of working his way through open-heart surgery armed with Google (and maybe a spare patient or two).
In addition to Google-guy, you can look for the silent-but-deadly developer. This is they guy who doesn't make a lot of fuss, but cranks out volumes of code that all works. Note that when I say "silent", I'm not talking about intensely introverted, I'm talking about the guy who knows what the job is and how to get it done, and would just as soon you leave him alone to get it done. This person, in order to be successful, will be able to understand a problem at high and low-levels simultaneously, so he won't be easy to spot, but he's a great asset if you can find him.
Watch out for crisis-boy. This is the guy who creates or magnifies catastrophes so he can swoop in to fix them. This person is characterized by a lot of self-congratulation, technical elitism, and last-minute heroics. His ego is fueled by the adolation he gets when he rescues a release at the last minute. In order to really understand why this is bad, consider how you'd feel about an airline that had pilots that were so good that they could recover from near-disaster after near-disaster. Hats off to the pilots, right, but how about figuring out how they keep getting into near-disaster situations?
When all is said and done, you hopefully will have a group of people who are predisposed to doing the right thing and skilled enough to go do it. The fun part is helping them do their work.
