Month: November 2005

I've always been a proponent of right-sized process; that is, enough process to do the job, but no more than necessary. Though most development efforts fail on the side of too little process, it's reasonable to be nervous about too much process just for the sake of process. Fortunately, there's an effective minimum that's easy to implement. Read on and make sure you're doing at least the minimum to keep yourself on track.
Over the years, I've seen a surprising number of development efforts that put themselves at unreasonable risk of failure simply by skipping on some simple pieces of infrastructure. Often, this is done in the name of speeding development; as in, "if we skip this bit of process here, we can get this done faster." That makes sense in the same way that skipping an outline will help you get a research paper done more quickly.

In fact, the right amount of process or infrastructure is right because it helps you get the job done as quickly as possible. Some things, like source code control, save time by eliminating those catastrophes that inevitably crop up during the course of a development project. Others, like bug tracking, simply reduce overhead needed to keep track of what's going on. The items I've listed here have made a real difference in my teams' ability to deliver software over the years -- they should be considered minimum requirements if you're building software for internal or external clients.

Source Code Control. This should be pretty obvious, but it's staggering how much software development happens without source code control of any kind. If you're a one-man wrecking crew, you may be able to get away with burning a CD every day, but there are plenty of commercial-quality SCC systems out there that are free for single developers or non-profit development -- check them out. If you're part of a team, this is simply not optional. Pick a system and start using it.

Build Machine. Some may be surprised to see this show up on a list of "must-haves", but it's been a key for me over the years. Simply put, this innoculates you against "it works on my machine". By setting up a build machine that is connected to the team via your SCC system only, you guarantee that you have one and only one system configuration that produces your "official" builds.

Note that there's nothing here that says developers can't do builds on their local machines; on the contrary, that can help boost individual productivity. If your build system is able to handle this, that's fantastic. Under no circumstances, however, can you ever consider a build done anywhere other than your build machine to be considered "real".

A related but separate issue is build frequency. I'm a fan of daily builds, but I've used build machines for weekly or ad-hoc build schedules, and the concept is just as valid in these other settings, too.

Bug Tracking. This can be an excel spreadsheet if you're really compelled to go minimalist, but again, there are so many great options out there that don't cost a thing, that I think you'd be foolish not to set up a "real" system. Use it to track bugs, and be religious about it -- it it's not in the system, it never happened. Don't let this be an excuse to be abusive to customers who don't have access or knowledge to use the system; you may end up entering some bugs for them. Just be sure they're in the system.

You may find that you want to track feature requests, support incidents, or other to-do items in your bug tracking system. Once everyone's in there on a regular basis, this can make a lot of sense, and can take the place of "big process" for things like requirements management and help desk support. Go ahead and exceed the minimum if that makes sense.

Automated Testing. If there's an optional item on the list, this is it. There's often a fair bit of work involved in setting up effective automated testing, but once it's in place, it's a powerful tool. Find some small amount of unit testing to start with and give this a try. You should be able to see results quickly and convince yourself that futher work is worthwhile.

Good luck with these -- I'm sure you'll need to exceed these minimum guidelines for many projects, but if you ever stumble into one where you're not meeting these minimums, get them in place as quickly and as carefully as possible.

Ok - I've got a new theory to explain some of Microsoft's more inexplicable behavior. After all the anti-trust muckety-muck they've been through, they're a little gun-shy about taking over the world all at once, so they're hitting a few short flies to the infield to keep everyone off guard. That's my theory, anyway. It's the only thing I can come up with that would explain why they're not swooping in and simply scooping up market share with a big bucket.
There are three big areas where Microsoft is just whiffing right now, and I can't believe that this isn't abundantly obvious to them.

1. App server integration
2. Low-end development tools
3. Workflow / business rules

Ok, one at a time now. App server integration. I've remarked in the past that someone could make a big dent in the market by integrating .Net support into a recognized J2EE app server. Gotta be one that's already acknowledged in the market. We've got enough app servers out there already, after all. Build .Net support (via Mono) into an App server such that JNDI and app management work similarly no matter what the app was written in.

Speaking of Mono, for Pete's sake, get behind these guys, already. They've just released Mono 1.1.10, and they're starting on .Net 2.0 support. They're funded largely by Novell right now, and they're doing the best they can to keep up, but there obviously are some things falling by the wayside due to lack of funds / bandwidth (Novell had apparently told them they're not going to fund development of VB.Net support in Mono, for example).

So there's this group of developers sitting in the open-source camp growing a list of followers - throw 'em a bone. Make a public announcement endorsing the guys, and toss them a few bills. You kill two birds with one stone: Mono is going to attract developers who would otherwise be using Java or LAMP on a non-Microsoft platform, so you're eroding someone else's market share, plus you get to point to this great open-source showcase the next time someone starts griping that Microsoft is big and mean and closed and anti-competitive.

My final observation on this point is that I've personally experienced the horror of not being able to sell .Net as a development platform simply because it implies platform lock-in. I ended up having to architect in Java for a shrinkwrapped software product simply because I couldn't get over that point. At that time, Mono was very young, and even alternatives like Mainsoft were just beginning to surface. I don't know how many other people out there are falling victim to exactly the same circumstances that got me, but Microsoft could end all that by just coming out and endorsing / supporting something that offers the promise of open platform support. Compete on the basis that Windows is the best place to run your app -- not the only place it can run.

Next point: low-end development tools. First, when I say low-end, what I mean is low learning curve, not inferior. Microsoft once had a pretty broad spectrum of development tools in Visual C++ and Visual Basic. These tools essentially merged with the introduction of VS.Net. Granted, there are different languages to ease adoption from the various camps, but the biggest learning curve in .Net is the framework itself, and that's the same no matter what language you're writing in. The .Net framework in general, and C# in specific are widely acknowledged to be Microsoft's response to Java, and in general, I think that's a good thing. Hit the mark pretty well, if you ask me.

What's missing, though, is the tool support for everybody else. The original concept behind Visual Basic was to enable Windows development for the masses. Though "the masses" turned out to be a subset of developers, this was still an huge score for Microsoft. You've no doubt seen references to the VB developers who feel scorned an abandoned by Microsoft now that they're ending support for VB6. If you ask me, I think an awful lot of the real hurt those people are feeling is not over the death of VB6, but over the death of the original idea behind Visual Basic.

When a group of customers asks for something that appears not to make sense, you've got to look past the points on the surface to understand what's really irking them. In the case of the abandoned VB developers, the thing they really miss is the simplicity and elegance of early VB. There's a hole in Microsoft's product line, and it's not going to be filled merely by giving away VS.Net "Express" editions.

There's growing support for simplified platforms like Ruby-on-Rails -- largely among Java developers, but the appeal for any developer is obvious (here's an excellent example from the point of view of a J2EE developer). Development platform like ROR have the simplicity and productivity of early VB while offering the ability to run on open platforms -- important for an app you may want to host on someone else's server for $9 / month.

I covered the open platform point already, so I'll stick to the simplicity point here. Lots of people have tried to hit the sweet spot where business analyst meets developer. From the analyst side, we've (nominally) seen UML, which missed badly. We've also seen Microsoft try to extend office with Access and Frontpage and VBA with limited success. The original VB tried to his this spot from the development side, and the "express" products are targeted there right now.

Nice tries, all of them, but not quite enough. Current direction calls for Office to keep pounding away with tools like Infopath and Sharepoint, but we need more. There needs to be a real "less is more" product that knows what its limitations are and is ok with that. Maybe it can't be a whole other product, for fear of fragmenting the product lines too badly. Maybe it's something you insert into word doc or an excel sheet like you'd insert a table or a chart (insert new Application...).

All of this transitions nicely into my last point - workflow and business rules. I've already written about my initial reaction to Microsoft Workflow. By targeting Workflow squarely at developers, Microsoft is missing again that confluence of business users and IT groups. Yes, I know that this is just the beginning of a strategy that's supposed to play out as Vista and Office 12 are released. In the mean time, the business user is left wanting.

This will remain the case even after Office 12 if programming languages are the only way to express business rules. Business Rules Engine (BRE) products are poised for growth soon in the same way that Business Process Management (BPM) apps have grown over the last couple years. Among these BREs are products that can express business rules graphically - no coding required. Most of the BRE's out there lack the scope needed to effectively integrate into the enterprise out-of-the-box, making integrators essential to deployment.

If Microsoft could learn from some of these vendors (or possibly snap up one or three), I'd bet they could produce a fully Office-integrated application that a business person could use to produce solutions that were really enabled from front-office to back-office.

The good news for everyone who isn't Microsoft is that as long as they leave these holes unfilled, there's room for other vendors. The part I don't get is why nobody's seen the holes yet.

On occasion, I've had to do some real simple image editing to support technical documentation, design docs, powerpoints, and so on. Here's a technique I used to take a desktop-wide screen shot and highlight one window by fading the rest of the desktop to near-grayscale. You could use this same technique to highlight part of an application screen to draw the viewer's eyes to the part of the picture you want them to pay attention to.
(1) Take a screenshot. Alt-prntscrn works as well as anything else, IMO.

(2) Paste into an image editor. I use PhotoImpact, but virtualy anything should do. You could try Gimp or Paint.net (http://www.eecs.wsu.edu/paint.net/index.html) if you want something free.

(3) Make a copy of the image ("highlight").

(4) You should be able to find a "Hue / Saturation" control in whatever you're using. Use that to dial down the saturation to achieve the effect you want. This can be more subtle than going all the way to greyscale if you want.

(5) Take your "highlight" copy and select the window you want to highlight -- you may be able to use an "edge find" tool, though I seldom have good luck w/ this.

(6) Copy the highlight window and paste into the base that you dimmed earlier.

This should get you pretty close. I don't, btw, know of any tools that make this any more automatic than this, but this shouldn't take more than 1-2 mins per screen shot.