I've linked to a couple cheat sheets in the past (Powershell and CSS), but I've run across a post that lists a bunch for different languages and frameworks. Most of them are available as PDFs. See webtecker.com.

The image is from a VisiBone advertisement. That company sells some great cheat sheets and cheat books.

Here's a very interesting interview of Jason Fried (of 37signals) by Walt Mossberg. It's from a conference on innovation in business. Jason explains how 37signals' business model helps them avoid the pressures of feature creep and how that makes his product a success. He emphasizes the use of the word "No" in developing software and trying to please everyone is the road to mediocrity. He comes up with a fitting analogy using Italian restaurants, but you'll have to watch the interview to hear it. The interview goes on to examine how feature creep affects the success of open source.

Here's an interesting write-up that summarizes several sources of information about Amazon and high scalability systems. I thought some of the bullet points were pretty insightful...

• Between 100-150 services are accessed to build a page.
• Take it for granted stuff fails, that's reality, embrace it. For example, go more with a fast reboot and fast recover approach.
• Work from the customer backward. Focus on value you want to deliver
  for the customer. Start with a press release of what features the user will see and work backwards to check that you are building something valuable.
• Use measurement and objective debate to separate the good from the bad. Referred to as getting rid of the influence of the HiPPO's, the highest paid people in the room. This is done with techniques like A/B testing and Web Analytics. If you have a question about what you should do, code it up, let people use it, and see which alternative gives you the results you want.

If you haven't seen all the video clips for Microsoft Surface yet you'll have to check them out. Surface should be really cool and should enable some giant steps forward with user interfaces. Your typical windowed application will be a thing of the past and that should also carry over into desktop computers. I'd expect some multi-touch flat panels for your PC too.

From what I've read, all the apps shown on Surface were written using WPF on the .Net Framework. Silverlight is another technology from Microsoft that brings WPF and .Net to the web browser (cross-platform even). Silverlight is the re-branded WPF/E code and is the next big thing from MS as far as the visual web goes. We used Silverlight (then WPF/E) for a SalesWorks demo back in February. Think of Silverlight as Microsoft's version of Flash.

To see something really neat, check out this demo of a Surface-style app using Silverlight in your web browser. You'll need to install the Silverlight Alpha to see it (just click thru the steps to install it). Yeah, that's a video file running in there. It's really amazing. You just want to put your fingers to the screen and start dragging the pictures around. 

I don't use MS PowerShell very often, but sometimes it does come in handy for testing .NET components. It seems like every time I want to use it I am Googling for basic commands to use with it. I've run across this handy little cheat sheet that you can print out. PowerShell Cheat Sheet Redux

One of the web services I've been working on has the requirement to send out formatted emails to internal user and external customers. In order for the service to go live we needed to take any day-to-day maintenance duties away from the developers of the project. One aspect of those duties is to keep the email messages that go out up-to-date. We store the addresses, subject and body of the various emails in the database. With the message bodies, we've designed it that the author can insert various macros that will get replaced with contextual values.

For example, when a new account is created a new email is fired off to our customer. That email needs to list all the specific details of the new account. The email message will have macros available like $AccountId$, $ContactFirstName$ or $InitialPassword$. When we generate the email, we call a simple function that uses reflection to pull the properties out of the Account object and replace the macros within the email message. Below is the VB.Net function that does that.

Public Shared Function ReplaceMessageMacros(ByVal Msg As String, ByVal Obj As Object, ByVal ObjType As Type) As String
    Dim objectType As Type = Obj.GetType
    Dim pi As PropertyInfo()
    Dim i As Integer
    
    ' get the property list from the object passed in
    pi =  = objectType.GetProperties(BindingFlags.Public Or BindingFlags.Instance)
    
    ' loop thru all properties of object and see if a macro exists in the Msg
    For i = 0 To (pi.Length - 1)
        Dim val As String
        Try
            val = pi(i).GetValue(Obj, Nothing).ToString()
        Catch ex As Exception
            val = ""
        End Try
        
        ' replace the macro with the property value
        Msg = Replace(Msg, "$" & pi(i).Name & "$", val)
    Next
    Return Msg
End Function

Make sure you import System.Reflection

I occasionally get questions on how I do my thumbnail images for my photo gallery. This site runs on ASP.NET and the photo section automatically creates thumbnails of JPEG images on the fly. In the real world, a web site like flckr.com wouldn't work if thumbnails were always created on the fly, but for my small amount of pictures it works just fine. Below is the code that creates a scaled thumbnail from a JPEG path and writes it back to the browser. This code is used within an HTTP handler that just serves thumbnails.

A couple points of interest. The code encodes the thumbnail at 75% quality. If the original image is smaller than the requested width and height, it won't scale it but will send it to the browser.

   1:  Public Sub ScaledImage(ByVal Path As String, ByVal Width As Integer, ByVal Height As Integer)

   2:      Dim originalWidth As Integer

   3:      Dim originalHeight As Integer

   4:      Dim image As bitmap = bitmap.FromFile(Path)

   5:   

   6:      originalHeight = image.Height

   7:      originalWidth = image.Width

   8:   

   9:      Dim heightRatio As Double = CDbl(originalHeight / originalWidth)

  10:      Dim widthRatio As Double = CDbl(originalWidth / originalHeight)

  11:   

  12:      Dim desiredHeight As Integer = Height

  13:      Dim desiredWidth As Integer = Width

  14:   

  15:      Height = desiredHeight

  16:      Width = Convert.ToInt32(Height * widthRatio)

  17:      If Width > desiredWidth Then

  18:          Width = desiredWidth

  19:          Height = Convert.ToInt32(Width * heightRatio)

  20:      End If

  21:   

  22:      If Height > originalHeight Or Width > originalWidth Then

  23:          Height = originalHeight

  24:          Width = originalWidth

  25:   

  26:          image.Save(Response.OutputStream, ImageFormat.Jpeg)

  27:      Else

  28:          Dim thumb As Graphics

  29:          Dim bitmap As bitmap = New bitmap(Width, Height)

  30:          thumb = Graphics.FromImage(bitmap)

  31:          thumb.InterpolationMode = System.Drawing.Drawing2D.InterpolationMode.HighQualityBicubic

  32:          thumb.DrawImage(image, 0, 0, Width, Height)

  33:   

  34:          Dim codec As ImageCodecInfo = GetEncoderInfo("image/jpeg")

  35:   

  36:          Dim eps As EncoderParameters = New EncoderParameters(1)

  37:          eps = New EncoderParameters

  38:          eps.Param(0) = New EncoderParameter(Encoder.Quality, CLng(75))

  39:   

  40:          bitmap.Save(Response.OutputStream, codec, eps)

  41:   

  42:          thumb.Dispose()

  43:          bitmap.Dispose()

  44:          eps.Dispose()

  45:      End If

  46:      image.Dispose()

  47:   

  48:      Response.ContentType = "image/pjpeg"

  49:      Response.End()

  50:  End Sub

  51:   

  52:  Public Function GetEncoderInfo(ByVal MimeType As String) As ImageCodecInfo

  53:      Dim myEncoders() As ImageCodecInfo = ImageCodecInfo.GetImageEncoders()

  54:      Dim myEncoder As ImageCodecInfo

  55:      For Each myEncoder In myEncoders

  56:          If myEncoder.MimeType = MimeType Then

  57:              Return myEncoder

  58:          End If

  59:      Next

  60:      Return Nothing

  61:  End Function

Hashing is a reproducible process to calculate a hash value from some data. The hash values are unique and specific for the data it was derived from. Wikipedia has a good explanation of hashing. i will be showing some VB.Net code in this article that uses the SHA1 algorithm to do some hashing.

Hashing by itself does nothing to prevent tampering with the data. Message Authentication Codes (MAC) are a way to prevent this. MACs use symmetric encryption methods to protect the sent hash. Symmetric encryption uses one private session key and both the sender and receiver require to have a copy of this key.

Below is the VB.Net code to generate a MAC using HMACSHA1:

   1:  Imports System.Security.Cryptography

   2:   

   3:  Public Shared Function ComputeHash(ByVal Data As String, ByVal Key As String) As String

   4:      ' initialize the keyed hash

   5:      Dim sha1Algo As New HMACSHA1(System.Text.Encoding.ASCII.GetBytes(Key))

   6:   

   7:      ' compute hash 

   8:      Dim hash As Byte() = sha1Algo.ComputeHash(System.Text.Encoding.ASCII.GetBytes(Data))

   9:   

  10:      ' convert to string and return

  11:      Return System.BitConverter.ToString(hash)

  12:  End Function

  13:   

  14:  Public Shared Function VerifyHash(ByVal Received As String, ByVal Data As String, ByVal Key As String) As Boolean

  15:      ' hash our data

  16:      Dim hash as String = ComputeHash(Data, Key)

  17:      

  18:      ' compare strings

  19:      Return (Received = hash)

  20:  End Function

  21:   

This code was derived from a more in-depth article: Hashing, MACs, and Digital Signatures in .NET.

I have been evaluating WPF/E for add-ins to my company's products. One screen we have been thinking about for a while is a lead pipeline that shows lead stages in a graphical way. Our products leverage IE for the presentation layer and it is tough to do a compelling pipeline with just DHTML.

WPF/E brings a lot to the table. First of all it is very easy to incorporate into our screens, I simply insert the control code and link in the aghost.js file. It also enables us to easily separate the markup from the script. The HTML file orchestrates the screen while the script and XAML reside in separate files. I also like the division of labor. As shown in these screenshots I've coded the pipeline screen as a segmented pipe along the top of the screen. As the developer I just created simple XAML objects that represented the different elements of the pipeline, nothing too fancy. I then hook up my script to control click-thrus and mouse-overs (the second screen shows how the mouse-over affects the pipeline). In production I would then had the XAML source over to a designer and they would take my rudimentary design and create something beautiful from it. They'd send me the updated XAML file and I just insert back into the development tree and everything should still work with changes. In this case I was the designer too, but you should start to see how this should make development easier.

Another thing that I experimented with was trying to use the same XAML objects and provide an entirely different look and feel for the screen. The final screen shot shows how that turned out. This pipeline demo is very simple, but it starts to paint a picture of how WPF and WPF/E can be used in software. I can imagine that things are not quite as simple when more complex functionality is needed. When trying to change the pipeline into a vertical funnel, I did have to adjust some of my code to make it work.

I did try to use Microsoft's new Expression Design application to create the XAML I used in this demo. I designed the circular pipeline segments and exported them as WPF/E XAML code. That sort of worked, but It generated everything as complex paths and was hard to modify by hand. By the time I had finished the demo, I ended up starting from scratch with the XAML objects. Still, the tools are great and they look very promising.  

In my previous post I had only been using Expression Blend and wasn't able to figure out how to get it to generate content for WPF/E. It turns out that only Expression Design can export WPF/E compatible content (thanks ADO Guy).

If you download and install Expression Design, you can create vector-based elements to include in your WPF/E-based web pages. Expression Design is very similar to Adobe Illustrator. Once you've completed your design, click on File>Export>XAML. This will prompt you for a filename then it brings up a XAML Export window like the one on the right. If you select the Document Format dropdown you can select the WPF/E format. I've tried a couple simple tests that displayed correctly in WPF/E Pad.

This is a good step and may be all we need, however I was expecting this same type of functionality with all the Expression tools. Is that coming?

I first crossed paths with Windows Presentation Foundation/Everywhere (WPF/E) on Mike Harsh's blog post about the Mix '06 event in March of 2006. I knew about XAML and where Microsoft was going with their presentation layer tools, but our company creates mass-market desktop software that doesn't utilize the .Net Framework yet. This meant any XAML or WPF was off limits for us. That is until MS announced WPF/E.

In Mike Harsh's words "(WPF/E) is a cross-platform, cross-browser web technology that supports a subset of WPF XAML.  WPF/E also has a friction-free install model and the download size we’re targeting is very small.  WPF/E supports programmability through JavaScript for tight browser integration.  The WPF/E package also contains a small, cross platform subset of the CLR and .NET Framework that can run C# or VB.NET code."

So XAML and WPF can now be hosted in Internet Explorer. Since my company's desktop applications host IE for the presentation layer, then our presentation layer can take advantage of XAML and WPF. Unfortunately there was not much to be heard of WPF/E since March, but this month MS released a CTP of WPF/E.

where to get started

Probably the best place to get started is the WPF/E Dev Center on MSDN. Download and install the SDK so you can start trying the examples. The Dev Center has a few that you can look at. Mike harsh has also built a cool little application that let's you test your XAML code, called WPF/E Pad. Once you have the SDK installed you can run the WPF/E Pad and try some of the built in examples. After you get a feel for what can be done try entering some of your own XAML. Try copying and pasting the source from below into the bottom panel of WPF/E Pad and clicking the Load button.

<Canvas xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" x:Name="_037_bugs_logo" Width="1056" Height="816">
  <Ellipse Height="200" Width="200" Canvas.Left="30" Canvas.Top="30"
      Stroke="Black" StrokeThickness="10" Fill="SlateBlue"/>
  <Rectangle Height="100" Width="100" Canvas.Left="5" Canvas.Top="5"
      Stroke="Black" StrokeThickness="10" Fill="SlateBlue"/>
  <Line X1="280" Y1="10" X2="10" Y2="280"
      Stroke="black" StrokeThickness="5"/>
</Canvas>

You should end up with something like the screenshot to the left. The XAML creates an ellipse, a rectange and a line. This is not a very compelling example (it was taken from the MS SDK download) but it gives you something to start with. What's nice about the technology is that it allows you to interact with the XAML code using JavaScript. So you can create a bunch of objects using the XAML markup and embed it in your web page, then use JavaScript to program those objects. For example you can attach events to the XAML objects (similar to DHTML) and handle those events in your JavaScript. WPF/E Pad doesn't support event handling at the moment, so you have to take the next step and create your own web page to test out event handling. Those steps are covered in detail within the WPF/E SDK.

what's next?

What makes all this really interesting is how Microsoft is backing up this technology with their development tools. They've recently released an entire suite of apps to generate, manage and debug XAML. Check out their Expression Suite. I think the development tools will be able to target WPF/E versus WPF at some point. Exciting stuff.

The blog content for this website is managed and rendered by a custom version of the dasBlog Weblog. I've refactored the dasBlog ASP.NET application code into a reusable .NET library that can basically be called by any .NET client app. In this case the client is our home-grown site hosting software. I'll go into a little more detail about how this was accomplished.

Here's a little background about the client. Our hosting software is a simple ASP.NET web application that uses modules to render parts of the page. There are 3 content panels for each page (not including the headers and footers) that contain the user's HTML. The simplest way for content to be rendered for these panels is to use the HTML module that simply pulls content from a .htm file on the server. We have more complex modules for showing forms, photo albums and blog articles. A simple configuration file tells the site engine which module a content panel should call to get HTML to show. In this blog there are two content panels: a center panel and a right panel. The right contains some blogging tools and the main, center panel contains the blog articles. This is where the dasBlog code comes in.

The original dasBlog application is a full blown weblog application that handles everything from displaying and posting articles to site templates to usage statistics. I wanted these tools as well, but I didn't want them in the form of a website. All I needed was to be able to call into a library to get the HTML for a list of blog articles or single blog articles. I also wanted to take advantage of the blog api's used by blog publishing clients so there would be a way to get the content into it.

I started with dasBlog version 1.8.5223.2. The application was designed to mostly handle a single blog and its content. Most of the code assumed global classes for getting the content and settings stored on disk. What I did was create a BlogContext to hold all the global class instances. The single, global class which encapsulated all the original global variables enabled me manage multiple sets of blog content and settings. I wrote another couple classes to manage the multiple instances of the BlogContext class.

To give you an view at how this all works together, I'll show you a code sample. One of the handlers within our site engine module is OnColumnRender(...). It gets called in the module when the site engine needs it to render some HTML for a content panel. It gets passed a Column arg and a Holder arg. The Column arg gives the module a reference back into the APIs in the site engine. The Holder arg is just a typical ASP.NET Control that represents the content for a panel. The following code sample gets a reference to a BlogContext and uses it to fill in the Holder Control class.

   1:  Public Sub OnColumnRender(ByVal Column As PageColumn, ByVal Holder As Control) Implements SiteModule.OnColumnRender

   2:      ' get a reference to a blog context. a single site (SiteInfo.Key) can contain multiple

   3:      ' blogs identified by Column.Key

   4:      Dim blogContext As New BlogContext

   5:      Dim blogEngine As BlogEngine

   6:      blogEngine = BlogEngines.GetBlogEngine(Column.Page.SiteInfo.Key, Column.Page.SiteInfo.ContentFolder)

   7:      blogContext = blogEngine.GetBlogContext(Column.Key)

   8:      

   9:      ' set the root for our engine

  10:      blogContext.SiteConfig.Root = Column.Page.Url.Root

  11:      

  12:      ' tell the blog engine where to get its templates

  13:      blogContext.TemplateFolder = Column.Page.Template.Folder("blog").Path

  14:      blogContext.TemplateURL = Column.Page.Template.Folder("blog").VirtualPath

  15:   

  16:      Try

  17:          ' now tell the blog engine to process the bodyText macro

  18:          ' and fill the Holder with blog controls. it takes the

  19:          ' the ASP.NET page class as an argument. those familiar

  20:          ' with dasBlog recognizes the %bodyText% macro as the

  21:          ' actual portion of the page where article content is put

  22:          blogContext.Process(Holder, "<%bodyText%>", Column.Page)

  23:      Catch (Exception ex)

  24:          Column.Page.HandleModuleException(ex)

  25:      Finally

  26:          ' set the page description based on the blog content

  27:          If blogContext.Description.Length > 0 Then

  28:          Column.Page.Description = blogContext.Description

  29:          End If

  30:          

  31:          ' add our blog stylesheets

  32:          Column.Page.StyleSheets.Add(blogContext.TemplateURL & "/styles.css")

  33:          

  34:          ' add a RSD tag

  35:          Column.Page.HeadTags.Add("<link rel=""EditURI"" type=""application/rsd+xml""" & _

  36:              " title=""RSD"" href=""" & Column.Page.Url.Root & "/" & Column.Key & ",rsd"" />")

  37:      End Try

  38:  End Sub

 
The result is a set of modified dasBlog libraries, some web.config settings and a site engine module library that gets registered with the site engine. There are many details that I've skipped over, like how the blog clients interact, how the generated content is modified by user interaction and how the right content panel shows details about the blog itself. I will likely give more details a sample code if there is interest.

Based on a previous post of mine, I started hunting for a source code repository to use. I found several. The one I liked the best was snipplr.com. There were a few reasons I liked this service. It has a very simple, clean interface. It has a simple, open API for accessing your snippets from other applications. It keeps track of snippet changes. It handles colorizing source code. It provides tagging of my snippets. I've also had no problems reaching it and it seems snappy.

As an experiment, I've added a snippet sidebar to my source code editor, Parachute, which can be downloaded from my website. Just open the options and enter your snipplr API key. Your snippets should show up and can be filtered by the tag bar at the top. Double-click on a snippet to paste it in the editor pane. Please try it out and let me know how you like it.

I've seen some pretty impressive digital rendering before, but I had know idea it was this close to being mainstream. Microsoft will be releasing DirectX 10 on Windows Vista. DX 10 is a total re-write. I think gaming is going to jump to the next level. I also think it's a good idea for Microsoft to only make DX 10 available on Vista. It gives the gaming community and home users good incentive to move to that platform, even if business users have no motivation. Then again maybe it's not a marketing tactic since the article says "The new display driver or graphics model in Windows Vista, WDDM (Windows Display Driver Model), is the main reason for DirectX10’s exclusivity to the operating system".

In continuing to review the good and bad aspect of our last product cycle I ran across a discussion on the Coding Horror website called What is "Modern Software Development". The topic of the discussion is about identifying an essential checklist for good software development. There were existing lists from Joel Spolsky and Steve McConnell as well as new suggestions. It inspired me to compile an essential checklist for our development team. I used items from the original lists and added some of the suggestions from the discussion. Here is the list with how I feel we currently stack up.

1. Do you use source control?
Yes. All our source and documentation is in source control and backed up nightly, offsite. We use Subversion and TortoiseSVN.

2. Can you make a build in one step?
Yes. Each of our projects have build scripts so they can be built and packaged with single commands.

3. Do you conduct code reviews on a regular basis?
No. We have a small team of experienced programmers who all sit around a big desk in our dev room. This makes communication much easier, but it's still no excuse for being more formal about code reviews. This needs to happen.

4. Do you have a common code repository?
No. This is not so crucial for our small team, but as we grow it will be important. We find ourselves constantly asking "Hey Steve, where did you implement that XXX portion of code" so we can copy it in another place.

5. Do you have a bug database?
Yes. We use Bugzilla for recording bugs.

6. Do you fix bugs before writing new code?
No. We do fix bugs and supporting our customers is a top priority, but during a product cycle bugs are usually the last thing that are done and also the most likely to get short-changed.

7. Do you have an up-to-date schedule?
No. Scheduling is kinda done at the watercooler. This needs to be more formalized and done across the entire product team.

8. Do you have detailed activity lists?
No. We should be able to extract detailed activity lists from our specs. Currently this is not possible because our specs are not as detailed as they should be. I think these are important because it is a good litmus test for our spec process.

9. Do you have unit tests?
No.

10. Do you conduct regular usability testing?
No.

Whew. After going thru all that it appears we have a long way to go. It's not totally as bad as it seems. If there was a slight bit of doubt in answering the question, I listed No. Some of the items we do to a certain degree but I felt we need to address it better. Hopefully in the upcoming months we can improve on these items now that they are identified.

Part of finishing up a product cycle involves a postmortem. It's a chance to reflect back and identify the positive and negative things that contributed to the success of a product release. Hopefully identifying the positive and negatives will help us improve the quality of our software and increase our efficiency in building products.

We have just finished up a particularly long and grueling cycle for GiftWorks Volunteers. While I'm sure the actual product will surpass the expectations of our customers, the process of getting there was not a model of efficiency. We had several slipped deadlines. I've spent a lot of time tracing the steps along the way, trying to come up with a short list of points to carry forward to the next project. One point that keeps coming up is time estimation. Our company and our competition work on "Internet time". Release early, release often. It is critical for us to deliver our products as fast (if not faster) than our competition. Our customers demand it. But our customers also demand quality, and that is the challenge.

Time estimation comes up at several places during a product cycle. When a product idea is formed there are always rough estimates made as to how long it would take to release. There are time estimates for coming up with product specifications, time estimates for doing the development and testing, time estimates for beta releases. There are even time estimates for coming up with time estimates. These estimates allow us to plan ahead and are necessary. From the very beginning, "do you think we can get this done for a fall launch?", "can testing begin next month?", "how long will it take to get feedback from customers?". Time estimates also have a major impact on the overall product, and I think that impact can easily be underestimated (no pun intended).

Early, "back-of-the-napkin" time estimates are sometimes used to set deadlines for a product release. I'll call these "artificial" deadlines. They are deadlines that are set based on information other than the project schedule created after a functional specification has been reviewed and all teams have had a chance to provide time estimates. The artificial deadlines may be marketing driven, competition driven or come from somewhere else. They are not wrong, but do add a degree of risk to the product cycle.

There are several variables that can be used to represent a product cycle. Here is how I picture the formula in my mind: Resources + Time is proportional to Functionality x Level Of Quality. Where the Level Of Quality is a constant, or at least I think it should be. Generally, the more resources or time you add to a project, the more functionality you'll end up with. For example, assuming constant resources and level of quality, a four month product cycle will yield more functionality than a two month product cycle. This may sound obvious to some. Typically a balance of resources, time and functionality is reached through an iterative process. With an artificial deadline, a fixed time variable, product managers adjust the number of features in proportion to the resources and the deadline.

In a company like ours, resources are generally fixed for a project. This means the only two variables we have to play with are time and functionality. Given this condition, artificial deadlines impose an artificial limitation on the level of functionality for a project. Not only is functionality fixed, it is also fixed before specifications are drafted. This could put you in the position of not having enough functionality to meet customer expectations when the project is done. And worse, you are likely to only come to this realization late in the product cycle. Not a good situation, especially with artificial deadlines which are there usually because there are external dependencies on a date. Now, not only is the project in bad shape, so are the external dependencies. 

There is another side-effect of artificial deadlines. There is very little margin for error. If there is slippage in one part of the project, everything that depends on it will have less time to get done. This usually has a direct effect on the quality of the product because internal testing and customer testing happens at the end of the project.

So what's my point here? My intent was to examine how time estimates affected our latest project. In particular, time estimates used to guide artificial deadlines. My thoughts are to avoid artificial deadlines altogether. But sometimes they are necessary and this is where time estimates are especially critical. When early, rough estimates are used to guide artificial deadlines, you have to be very careful to assess the accuracy of those estimates and adjust those deadlines accordingly. I think this is one area that contributed to the slips we endured in our latest product cycle. In each case we underestimated the work involved in getting to where we wanted to go. Luckily our external dependencies were not too rigid. Moving forward we need to identify when a deadline is artificial and make sure that it is the right thing to do. If we decide to continue using an artificial deadline (which may be appropriate) then we had better be sure about our confidence in the accuracy of our estimations, or account for that risk in our plans.

Mission Research is a growing, startup company. We do not have an abundance of resources to be throwing at our products and for that reason we are always looking at ways to provide more value to our customers with fewer resources. I'd say we do very well given our constraints, but we can always do better.

Our products are the result of a series of well defined projects. We start out in an Envisioning stage where we define the concept and requirements of the project. Once the concept and requirements are "approved" the project enters the Planning stage. The Planning stage is where the project is defined and a schedule is created. This has historically been the toughest stage of our product cycles.

One of the areas we have been struggling with is figuring out the best way to get a feature or idea from conception to an appropriate level of definition so it can be turned over to our development team. It always seems to take longer than it should and just doesn't feel right. There is always a question about how detailed the functional specifications need to be. We occasionally fall into the trap of going too deep or getting hung up on details that could wait to be figured out. In some cases we actually get so hung up with implementation and technical details that we lose site of what our customers want. In my experience, this tends to happen when developers are brought into the process too early or are even responsible for the designs themselves. I'm not saying that developers can't design software; I just think that they're too close to the code and their thinking is limited by what they perceive as technical limitations.

So I've been thinking lately about setting up some smaller milestones within the Planning stage to keep us on track and guide the definition process. In my mind, the first pass at defining the functionality should be free from technical limitations. Ideally, lock the product manager and designer in the room with a sample of customers and don't let them out until the customers have written a check for the idea based entirely on the high-level specification the designer has created for them. Now that will probably never happen, but the idea is to come up with something that totally meets the needs of the customer without someone standing over their shoulder telling them that what they designed is not possible. I'm not saying the initial design process is void of any logic, it has to make sense and be consistent across the design, but it shouldn't be constrained by what a "technical" person thinks is doable. Allow your designers to think outside the box. Because locking up your customers is not very feasible, what else can be done to create the same environment?

What if we made one of the first milestones in the Planning stage a presentation to the customer? Or if that isn't possible, your customer advocates-- sales, customer support and customer experience. This milestone would ideally occur before there is interaction with the development team. Now this may not be possible depending on your project, but it would be a good litmus test. If your designers are spending time with development before the Presentation Milestone then it should raise a red flag. In our company, a presentation would include some screenshots, a list of capabilities and examples of how the new features will be used. It should be detailed enough to give the audience a good overview. Each group should be evaluating the design from their areas of expertise. Can the support team support it? Can sales sell it? Does the design make sense and does it address the customer need? The Presentation Milestone is crossed when the design addresses all the holes revealed in the presentation.

Whether or not we actually inject that milestone into our product cycle or not, I think it's what the designers should be thinking in the first pass of designing the software. Another purpose of the milestone is to get the designers thinking across the entire functionality set before diving too deeply into the details of a specific function, going wide before going deep. It's very possible that a feature may be passed on once the full scope of the feature set is defined. Hopefully some of that wasted time can be avoided and the design process can be shortened.

Once that milestone is crossed, the designers are free to meet with development to figure out how to implement the design and how long it will take. Obviously some things won't be feasible for technical reasons, but the point is that the design should represent the ideal solution and that's the best place to start in my opinion.

I'm not sure where I found this tool, but it would have made my life so much simpler a few years ago when I was working on the proxy team at Sun Microsystems. In short, Fiddler shows HTTP requests and responses from your computer.

From the Fiddler website:

Fiddler is a HTTP Debugging Proxy which logs all HTTP traffic between your computer and the Internet. Fiddler allows you to inspect all HTTP Traffic, set breakpoints, and "fiddle" with incoming or outgoing data. Fiddler is designed to be much simpler than using NetMon or Achilles, and includes a simple but powerful JScript.NET event-based scripting subsystem.

The tool is fantastic and I would recommend it to anyone that does programming using the HTTP protocol. I am currently using it to debug some XMLRPC web services that we are rolling out.

For anyone who has to write regex expressions, this little tool will be quite helpful. I use regular expressions while programming, but I don't use them often enough to be able to just write them off the top of my head. I often find myself popping open a linux command line and testing the out there until I get what I'm looking for.

It's free for personal use. Download and try it out today.

Thanks to C82.net for his great site and "wildy useful web programs". Maybe you'll want to check out his others.