While perusing Slashdot today I noticed a comment sig with a link to SmallBizGeeks.com. I checked it out and it's a pretty nifty forum site dedicated to technology and small business. Just goes to show that maybe all those millions of hours reading Slashdot actually provide useful info now and again.
Building on Scott's excellent post about LinkedIn and what it could do for small businesses, I wanted to add my thoughts on how to harness the power to big business for small business. I've been thinking for awhile now that a significant advantage big business has is casual networking. You find it most prevalent when you need niche expertise and some guy knows a guy who's an industry expert. The company can then offer him a contractor or permanent position on Project X. LinkedIn helps in that area, in that it automates the whole "i know a guy who knows a guy" aspect. I think the big idea is to extend that from hiring someone on to doing other aspects of the business. Costco does good business by leveraging the buying power of a corporation to get small businesses good prices on food, merchandise, and supplies. How could a company leverage the influence of a large corporation for ad buys and market research for small businesses that don't have the connections or budgets to do those things themselves? Would that work? Would small business even want to buy-in to that kind of environment? I'm not sure, but I'd be interested to hear people's opinions.
No posts lately due to a combination of QuickBooks 2006 endgame development and weapons of mass birthday-related activities, but I'm back.
As QB 2006 gets closer and closer to shipping, some specially-tasked groups are starting to look towards next year's release. Our organization is now starting to overlap feature and product development over multiple releases, which is great from my point of view. It takes engineers off the product shipping this year, but with the benefit of getting extra design and feedback time in for QuickBooks 2007 or even 2008. More design and feedback results in more usable, higher-quality products. I really commend the support from management on balancing the short and long term. Plus I'm excited that we get extra time to incorporate as much user feedback as possible into QuickBooks Payroll features. I (sadly) found out too late that some engineers recently went back to my hometown in Wisconsin to do some follow-me-home activity. Sad face.
This year was my first shipping project that was heavily .Net, and I loved every minute of it. Most of my previous experience (going all the way back to college) was with C++. The joys of managed code are with me now, most notably in the supporting development tools. The one I've been using the most this release is Resharper. It does a lot of great tool-tipping syntax-coloring, plus it has great refactoring support and it does background compiles to give you immediate syntax error checking. Our development team has also gotten great mileage out of CruiseControl.NET for continuous integration and NUnit for unit tests. From what I hear, Visual Studio 2005 is going to have many more development tools built-in, but until it's in steady use by the org (not sure about any roll-out plans yet) I'm going to prefer to use the solid open source tools like Nant and NUnit.
Last week QuickBooks had a beta celebration over at the ol' Palo Alto Bowl on El Camino, and a good time was had by all. I never realized that the Cosmic Bowling Kraze actually makes it a thousand times harder to bowl. Disco lights, landing strip lights on the lanes, blinkering doo-dads, ~SMOKE coming out of the wall-- I couldn't see the pins. Sadly, our team was crushed when a developer rolled a 236 while being backed up by his team not messing up. I will get my revenge at beta celebration 2006.
(psst, Brewers finished with a non-losing record this year. out comes the champagne!)
Doing software development in such a customer-focused company is very interesting. Sometimes I feel like I've been down in the software mines for a while clinking away at some code ore, and I hit pay dirt! I run as fast as my legs can carry me back to the surface and triumphantly display this neat thing I've figured out:
"Whoa, guys. Look at this user interface trick. If I were a user I would love this!" I exclaim. And thus the Design-By-Engineer bug strikes. What I, as a developer, thought was a cool innovation is really a chore for the user to figure out how to use, or it violates 23 established UI guidelines. The key then is to take what's useful and refine it through user studies until it actually becomes useful.
I tend to think there are 3 levels of UI Acceptance. As you take a step to each successive level you gain wider acceptance by the software-using public.
Level One (and the least desirable) is when the developers who wrote the code understand how to use the product and no one else. As much as I love Open Source & Free (beer and speech) Software, it pains me to admit that a lot of the interfaces leave much to be desired. I've used many video encoding apps, server apps, and others that I look at and say, "I'm pretty sure someone knows how to use this, but it ain't me."
Level Two is when other developers or savvy computer-users can figure out how to use your applications, but they do so with a click of the tongue. Many, many times I've used an application and said, "I know what the developer was getting at here, but if I knew less about how you program with <insert programming language/environment here> I wouldn't have known how to access widget Y." After you've used hundreds of applications, it becomes second nature to check the usual suspects for where to access the app's options dialog. Edit...Preferences? No. Tools... Options? No. File...Options? Found it. Using an application should not involve rounding up the usual suspects.
Level Three is when the average user can find a high percentage of the functionality themselves, and with a minimum of swears and tech support calls involved. Even better, UI elements are standardized across products from the same group or company. Providing a low barrier to entry is fantastic for users who aren't computer geniuses, and using common elements over and over , and allowing access from familiar places is a great way to make even a new piece of software feel familiar to the user. Google does this well, and many of Microsoft's products use the same look'n'feel guidelines. I think that within our different divisions Intuit does this extremely well. Many of our offerings from QuickBooks, be they Enterprise Solutions, QuickBooks Pro, or Simple Start, are based around the same user interface models. Even better is that Quicken and QuickBooks interfaces are starting to align as well, which is a great plus for anyone moving from one to the other.
After thinking for awhile about the perfect segue into the next topic, I've decided it's too hard. Instead, I'll just come out and say that I've thought of the perfect costume for the Halloween Costume Contest in QuickBooks this year. I won First Prize last year with my tremendous Your Mom costume. This year will be even better. mwa ha ha.
Regretably, I don't get my own entrance music to the new QuickBooks Team blog. Even worse, the only song that's going through my head as I type this is the theme song to The O.C., which is clearly inadequate. On the upside, though, Intuit Is Blogging these days, which gets me really excited about getting feedback on the job we're doing as a group.
My name is Zachery Moneypenny and I'm a software developer in the QuickBooks Payroll group. I work mainly on the desktop software code, and my contributions to the QuickBooks Team Blog will primarily have a developer slant. That isn't to say I'm going to be posting code snippets and asking the audience "why don't this work?" but I want my contributions to be focused on (a) what interesting things are happening, tehnology-wise, in my day-to-day work and (b) my thoughts on how developers can deliver better software to end users. Also, I may make mention of the Wisconsin Badgers beating Michigan, but that's because I'm a softy for Wisconsin. Go Brewers.
Lately I've been terribly interested in introducing unit tests to legacy code bases. It's challenging, but I think we're starting to make headway and I'll probably start discussing it more once we get our current release out the door. I'm not sure about the mix of other bloggers, but I can assure you it will be from many different perspectives in the group. I don't want to wear out the welcome mat so soon (plus I've got some bug fixing to do), so I'll holler back later.
Recent Comments