Requirements Definition : The Danger of Failing Before You Have Really Started

  Requirements, Stories, Use Cases, or whatever a team wants to call them form a key part of the execution plan for a development team.  It should tell them what a customer wants.  The artifacts in whatever form they are tend to have varying degrees of detail.  Getting the right amount of detail at the right time is critical to the process of producing successful software.  My thoughts on Requirements definition form around a process with three key elements.

1. Development
2. Prioritization
3. Definition

  Development is first because you have to develop or brainstorm something to start with.  This generally is initially tied to a vision of what the software is supposed to do.  Over time as a product matures this phase often happens through user trials, surveys, feedback, and telemetry from the app that describes its usage and provides insight into where the app needs to evolve. This also happens as analysts evaluate the market the product fits in and based on the market’s evolution or the assumptions about where it will evolve.  In evaluating they determine what features needs to be added in order to allow the software to continue to be competitive in the marketplace.  With internal software this phase is often underappreciated and underutilized.  This is unfortunate because mistakes here whether in internal or commercial products can cause teams to miss the target market tremendously.  A mistake of one degree in a flight plan early in a flight plan causes a much greater deviation than a mistake relatively close to the target.  The Agilist in me openly admits that it is impossible to know everything upfront.  The development effort isn’t about deep detail, but broad strokes of strategy that guide the more detailed planning that occurs later.

  Prioritization comes second as the ideas developed get prioritized.  This act pares down the list of items that need to be defined in detail.  I like Scrum’s backlog analogy but I think the Product and Sprint backlogs might not be enough.  To use a baseball analogy I think you have an At-Bat Backlog, an On-Deck Backlog, and an In the Hole Backlog.  At bat would be your Sprint Backlog representing what is in play now.  On Deck represents perhaps a release backlog or something of that sorts.  These are items that are going to be in play and will need to be defined fairly soon.  In fact during a Sprint it wouldn’t be uncommon for the PM, Business Analyst, etc… to be very active in defining those items near the top of the On-Deck list.  The On-Deck list becomes a focal point in the prioritization process.  The Sprint is work committed to and while some teams might want to have a relative priority there I don’t have a firm opinion on it.  The On-Deck list is key – what will the team work on next is the question that needs to be answered by the prioritization process.  Once we have a prioritization there we can move forward with the third step in the process – Definition

  Definition in this context is providing the detail necessary to move the concept forward in the planning process and ultimately moving it successfully into the implementation phase.  Steps 2 and 3 in the process end up being a rinse and repeat type of deal.  Items will be prioritized onto a list and will need to be defined to some degree.  For example when an item is prioritized onto the On-Deck list it is likely that definition needs to happen in order for some estimates to be provided as to how long the items on the On-Deck list will take to complete (thinking of the On-Deck list as representing the functionality in a release).  As On-Deck items in the list move up – more definition is added so that the customer needs can be clearly identified and the developer can have in hand as much detail as possible when that item pops onto the At Bat Backlog.  It is here that we get to the crux of the matter that caused this post to be written.  I have seen two common behaviors that cause teams to fail relative to requirements definition.  The first is that requirements are defined too early in too much detail and not revisited effectively and as time goes on customer needs shift or change and the requirement as it was written months ago no longer accurately reflects their needs.  The second behavior is too little detail.  A story is defined with a title (which I think the whole story card/post-it thing encourages) and little else and exists like that all the way to the developer.  He has in his mind what the title means, the customer has another thing in mind, and program management has yet another.  Agile methodologies advocate the definition happen through consistent customer interaction and if that happens that can work.  All to often in practice it doesn’t work that way.

The takeaway is don’t under value the requirements process it is perhaps the most difficult thing to get right in the whole software process.  Too much detail, too soon or too little detail, too late – what is too soon and what is too late and how much is too much or little – not easy questions – the process above has worked well for me in addressing the challenges with getting requirements right.

Technorati Tags: Program Management,Requirements Definition,Software Engineering,Software Development,Agile

Blu-ray is in trouble

This news article reflects my same sentiments.  Blu-ray may have won the format war, but it has already lost the overall battle.  Streaming videos into your home is already a reality.  You can do it with Netflix (their partnership with Starzz makes their list of movies to watch now much more interesting), Movelink (partnered with Blockbuster), Amazon, and Apple.  Netflix launched their set-top box this year and Apple has had the AppleTV out for quite a while now.  You also have Media Center extenders that take XP Media Center and Vista Media Center and allow you to watch movies from Amazon, Netflix, and Movielink including the renting and downloading all from right at your TV. 

People are ripping their movies from DVD onto HDDs at an increasing rate as well (I can’t count how many Disney DVDs we have had to replace because of scratching).  These HDD based movies are available through some of the mediums discussed above (notably Media Center) to be viewed without ever having to put a disc in anything.  I see this mode increasing especially when you add to it the home movies, photos, and music collections that people are accumulating.  As an aside the increasing amount of digital storage that the average user has puts increased emphasis on having a solid backup strategy.  Even with the likes of Time Machine, Windows Home Server, Mozy and other online services, and even the improved backup capabilities in Vista there is a lot of room for improvement here in the consumer market.  In the end Blu-ray will undoubtedly stay around for a few more years until the streaming options include HD quality, but its demise is already fixed.  Let the streaming wars begin!

Technorati Tags: Blu-ray,streaming,Netflix,videos,Vista Media Center

How many choices are too many choices?

Americans are constantly faced by a myriad of choices.  When we go out to eat we have to pick between Italian, American, Chinese, Greek, Thai, Mexican, Indian, etc….  Once you have picked a type then you have to choose between Applebees, Chili’s, Outback, etc…  The same thing happens on trips to the grocery store, picking a dentist, or what movie to go to.  Many times we sit and spin on making a choice about something that likely doesn’t truly matter that much.

In the technology world this problem continually manifests itself.  Most techies have probably seen projects where the project deadline was hit before all the architectural choices were made because too much time was spent weighing the pros and cons of the variety of choices available.  That isn’t to say that decisions shouldn’t be weighed and measured, but that this activity should be time-boxed and at the end of the time the decision be made based on the data available.  One common example I use as evidence for this is citing the variety of technologies used by the big sites out on the Web.  Facebook uses PHP, MySpace and Microsoft use ASP.NET, Google uses Java (I believe) as do many, many others.  The same argument could be made about what server OS to use, what database to use, and so on.  The fact of the matter is with good people most technologies can be made to meet the need.  The argument that many people will try to cite is the productive improvements that technology X will bring.  The problem with that argument is that productivity is very difficult to measure (many smart people have tried and I have yet seen anyone to trumpet a truly successful way to measure) and so that argument is easy to make, but very, very difficult to prove correct (and often not worth the cost of doing so).

The danger comes when the new technology of the day or moment causes continual churn in an organization.  The seduction of always looking for best of breed (assuming for a moment that there was someway to truly determine best of breed) is that you are then set up to become a technology merry-go-round.  Invest in your technology selections, build expertise, and go deliver value.  Choose to get off the merry-go-round and make a commit.  Change of course will come over time, but when it does it should be obvious and done for obvious reasons.  In most cases change should be made because it will be a game changer either in dollars saved or dollars earned or provide obvious (emphasis on obvious) productivity gains.

Programmatically setting the version of the Enterprise Library Configuration Tool for Visual Studio

I previously wrote about the issue we ran into using Enterprise Library and Unity that caused us to have to roll our own version of the binaries.  The procedure to get the config tool to reference our custom binaries involves changing the EnterpriseLibraryConfigurationSet solution property.  Since we are developing a Starter Kit to be used for new projects starting up here at the Church I wanted to add to our Starter Kit automation the setting of the property to the appropriate value.  Tried as hard as I wanted I couldn't get it to work until I accessed the Solution Property using EntepriseLibraryConfigurationSetPropertyExtender.EnterpriseLibraryConfigurationSet which is how it was listed when I enumerated the property collection. 

So the one line piece of code to do the job is

Dte.Solution.Properties.Item("EntepriseLibraryConfigurationSetPropertyExtender.EnterpriseLibraryConfigurationSet").Value = "StackV1EntLib";

Of course that needs to be accompanied with an entry in the Registry that the StackV1EntLib string can point to which is listed below

[HKEY_CURRENT_USER\Software\Microsoft\Practices\EnterpriseLibraryV4\ConfigurationEditor\StackV1EntLib]

"ConfigurationUIAdapterClass"="Microsoft.Practices.EnterpriseLibrary.Configuration.Design.UI.SingleHierarchyConfigurationUIHostAdapter"


"ConfigurationUIAssemblyPath"="C:\\Program Files\\MSStack\\V1\\StackEntLib\\Microsoft.Practices.EnterpriseLibrary.Configuration.Design.UI.dll"


"ConfigurationUIPluginDirectory"="C:\\Program Files\\MSStack\\V1\\StackEntLib\\"

 

Technorati Tags: Enterprise Library,Unity,VSX

Programmatically setting multiple startup projects on a Visual Studio solution

  A month or so ago I was waist deep in Visual Studio automation code trying to figure out how to create a solution programmatically with multiple startup projects.  I searched and searched on the Internet, but could never find the answer.  I knew that the code I was writing was very, very close, but it wasn't working.  At the time I had to step away and work on other things that were more important, but today I was in and around that code and tried again.  I found the answer on good old Google in less than 10 minutes - http://www.dotnetmonster.com/Uwe/Forum.aspx/vs-ext/1609/Editing-DTE2-Solution-SolutionBuild-StartupProjects .  It is as simple as setting the StartupProjects property of the SolutionBuild object to an array of objects populated with the unique name of projects in the solution.  I had been trying to set it to a string array of the same thing!  Talk about close.  Either way job accomplished.  Our VS automation is now just a little more polished as a result.

Technorati Tags: Visual Studio,VSX

That darn backlog there is so much stuff in it!

  I used to be a believer that when a good idea came around you should throw it on the backlog.  Those ideas (or bugs) live on the backlog indefinitely waiting for their chance to "dance".  As I re-evaluate my thinking from a Lean perspective I am reconsidering that approach.  In Lean maintaining large amounts of inventory (queued inventory) is frowned up.  Without going into all the gory detail of Lean (if you are an Agilist, want to be an Agilist, or develop software go read about Lean and think about it in terms of your software development process - it will be good for you) large amounts of inventory lead to "inventory rot".  In the software world this amounts to requirements that were scoped two years ago by a Business Analyst that is no longer around or a bug reported by a tester two releases ago.  The information relevance in those backlog items has dropped considerably during the time that they were idle.  As time goes on and it becomes obvious that prioritizing them won't happen - close them.  Dump them.  If they are important they will show up again.

  In addition to trimming the backlog appropriately it may make sense to have tiered backlogs.  There will be a Sprint backlog (or Iteration Plan) that represents the work in flight.  It is useful to have an "on deck" backlog that represents the work coming up in the next 6 months or so.  The "long range" backlog represents those ideas and concepts that are more "out there" and likely are fairly vague, large, and inestimable.  Each backlog requires different types of care and feeding and involves different sets of people in the care and feeding process.  The Sprint backlog is the focus of the team, talked about in Standup as people report progress, and the tactical focus.  The On-Deck Backlog should be actively worked by the Business Analyst, Customers, Technical Lead/Architect, and Project Manager.  Perhaps this is a weekly, bi-weekly, or monthly meeting.  The Long Range backlog is likely discussed perhaps monthly or quarterly as needed to identify items ready to move on-deck and be fleshed out, identify new directions that need to be captured, and obsolete ideas that are no longer applicable (don't forget this one!).

  With bugs I subscribe to the Broken Window theory.  The more you have the less likely you are to care.  You have to be careful with that of course - take it too far and you end up with a product with no bugs, but no features either because you have spent all your time fixing bugs that weren't important.  Once a bug has been identified as costing more to fix than it is worth you start to have a case for closing it and dropping it off the bug backlog.

  The goal is to make sure your focus is where it needs to be.  Your Sprint Backlog efforts should be  focused on execution.  Moving those items through the development process as effectively as you can.  On-Deck Backlog efforts should be focused around locking down the requirements for the items so that they are ready to be executed on (a blog on how critical it is to do requirements definition is in the works).  The Long Range backlog efforts should be focused around making sure that you have outlined the key strategic elements for the future and analyzing them in the context of the market you are serving to see what value propositions make the most sense to pursue.

Technorati Tags: Agile,Backlog,Lean,Software Engineering

Using Resources with WPF and Winforms

I had a developer ask me how to use Resources the other day.  Honestly I had never used them for any production system and so I didn't know.  So I decided to find out.  Below is the code on how to do it in WPF and then after that how you would do it in Winforms.

WPF

I borrowed a lot of  this example from http://mostlytech.blogspot.com/2007/09/enumerating-xaml-baml-files-in-assembly.html.  The article I link to showed how to iterate through Resources files that are in your solution with the Build Action set to Resource.  I then use that to put an image on a button that alternates every time it is clicked.  At http://forums.msdn.microsoft.com/en-US/wpf/thread/1bb025e8-a20a-43c4-a760-8666c63ff624/ it explains how to work with Resources that you define in the Resource tab in the Project Properties.  You can also set an image directly in XAML as shown below

using System;

using System.Collections;

using System.Collections.Generic;

using System.IO;

using System.Reflection;

using System.Resources;

using System.Windows;

using System.Windows.Media.Imaging;

namespace WpfApplication1

{

    /// <summary>

    /// Interaction logic for Window1.xaml

    /// </summary>

    public partial class Window1 : Window

    {

        private int ButtonClicks = 0;

        List<object> EmbeddedResources = new List<object>();

        public Window1()

        {

            InitializeComponent();

            Assembly asm = Assembly.GetExecutingAssembly();

            Stream stream = asm.GetManifestResourceStream(asm.GetName().Name + ".g.resources");

            using (ResourceReader reader = new ResourceReader(stream))

            {

                foreach (DictionaryEntry entry in reader)

                {

                    if (entry.Key.ToString().Contains(".jpg"))

                    EmbeddedResources.Add(entry.Key);

                }

            }

        }

        private void Button_Click(object sender, RoutedEventArgs e)

        {

            ButtonClicks++;

            ButtonImage.Source = new BitmapImage(new Uri(EmbeddedResources[ButtonClicks % 2].ToString(), UriKind.Relative));

        }

    }

}

<Window x:Class="WpfApplication1.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
    <Grid>
        <Button Click="Button_Click">
        <Image Name="ButtonImage" Source="Images/IMG_7680.jpg" />
        </Button>
    </Grid>
</Window>

Winforms

I didn't spend as much time looking at the Winforms side of things, but here is a snippet of code that can be used.  Note that I set the Build Action for the Image file to EmbeddedResource because that is what all the examples said to do.  Bitmap has an overload that allows it to resolve Resource References.  The name of the resource becomes <Namespace>.<Path>.<Filename>.

pictureBox1.Image = new Bitmap(typeof(Form1), "Images.IMG_7680.jpg");

Technorati Tags: WPF,Winforms,Resources,.NET