Loosely Coupled Human Code Factory - A.K.A. Mercenary Engineer

WebTrends, News, and Techie Stuff

WebTrends

It seems there are flurries of activity at WebTrends again, at least in the local Portland news.  A new CEO, Alex Yoder, a 7 year veteran at WebTrends has stepped up.  Personally, and maybe I shouldn't yap this, I kind of dig the idea.  Alex is a solid guy, knows the business, and is really fit for the job.  Overall, I'm digging the decision of the board.

In other news, WebTrends has torn through another quarter of awesome profits.  This of course means the employees get a little kicker from the company, and I love to hear that - nothing beats company productivity and quality like happy employees.

Bailey's Taproom Round

I'll be hittin' up Bailey's again with my normal round of .NETters, Goths, metal heads, entrepreneurs, and start up peepz.  One of the things I'm contemplating, if I can handle and if it would be worth it, is starting an open source project.  Problem is, what really needs built, what do developers or some particular user base actually need in an application?  The other real question is, who would want to throw in on a project like that?

The Startup

Right now I haven't had time to write up any real tech related topics about what I've been working on.  There have been some significant blockages and rough spots, that we as a team are ironing out.  On the technical front though I think I'll probably have some interesting UI & MVC related topics coming down the pipe.  Otherwise I've been taking it easy and trying to keep focused on productively moving forward without the speed bumps getting in the way.

...and Personally

I've also been trying, still, to get BlogEngine.NET up and running.  The blog engine itself is running already, but the ETL for getting stuff out of Community Server is no easy task.  Rather confusing and frustrating in all honesty.  Once I get a little more time I hopefully can get it knocked out once and for all.  It would sure simplify my blogging efforts.

Software, Success and Ranting

I've been extra active reading blog entries lately and have come upon a few that have really got me kind of wired.

Software Development Dogmata - Good Practices Gone Bad

The first one is this article by Daniel Pietraru (who I do not know) over on little tutorials "Software development dogmata - good practices gone bad".  There are few major issues I have with this slight skewing of facts.  Overall, excellent article, but there are some issues.

First is the "Agile != Flexible".  Read the manifesto, there is no such thing as Agile that isn't flexible.  The birth of agile that is mentioned is rather skewed too.  If you truly want to learn about Agile, and you have a motivation to have good, happy, satisfied employees that are highly productive, look up the motivations behind Agile.  Otherwise, don't.

Daniel then goes on to negate the benefits of a short development cycle.  Iteration based development has proven so effective almost every major process out there these days takes some form of this.  As for the statement he makes "you cannot demo a car engine until it is fully built" is patently wrong.  You CAN demo a car engine and that is the entire point behind computer models used solely to design engines, and cars in general, in a very LEAN or AGILE manner.  So you can deny it, but I believe these methodologies, the focus on individuals, individual motivation, individual enablement, and other such characteristics of lean, agile, and others is exactly why Toyota has stomped the competition is is basically the world leader in automotive manufacturing and quality.

One really can't deny Toyota's success, and it is the prime cut of what agile is.

Pair programming, he has a slightly decent point on this topic.  I too find myself torn about the usefulness of pair programming.  It does, however have positive effects, but I don't buy into the eXtreme Agile approach to the whole pairing with one keyboard and one mouse.  Working together, communicating, and effectively integrating code into the main continuous integration serves just fine.  But, I can't really knock it either as I haven't truly tried hard core pair programming.

He goes on to slander design patterns, TDD, UML, and a few other things that most developers are fully aware is very helpful in software development.  Not sure why he hates so much of successful software.  I ponder, what does he like about successful software?

In Daniel's defense, he does have some valid topics, just the article is angry and seems to be centered incorrectly and lash out in ways that don't do the points he makes justice.  He does point to a very effective proven use of Agile methodologies, on a massive scale, for a company that turns a little it of profit now.  Google - so read the WHOLE ARTICLE of Stevey's (this guy works for Google and I've read his material several times) and don't be so frustrated with Agile, there ARE good and bad versions.  But I digress, on to the next.

Naming Conventions:  Are They Really That Important?

I stumbled on this entry, I don't know when, but somehow it reflected several conversations I've had recently.  I like naming conventions, when enforced by ReSharper, Intellisense, or something of that sort.  But to remember all, and then have new developers go about learning them all in today's development environment is...

...well...

...an utter waste of time.  Naming conventions are in no way important like they used to be.

Source Control is not a feature you can postpone to vNext

I just thought as I have many times, Microsoft doesn't seem to get source control.  Ayende @ Rahien (the awesome software simian) goes on a slight rant about the absurdity of their solutions so far.

Why are the Microsoft Office file formats so complicated? (And some workarounds)

It also seems that with my new effort to build awesome Office interfaces, tools, and solid back end architecture for these systems I've found the insanity of Microsoft's Office file formats.  I never realized, but Joel Spolsky, who I've read a lot of lately, worked on the Excel team at one point.  He points out that there a more than a few pages (349 in one PDF) of documentation solely about the file formats of Office.

A Field Guide to Developers

Joel also did a great write up in the year 2006 about how to get a keep top developers happy and productive.  Things like private offices, cool toys, a good physical work space, and one of the most important topics being the social existence of programmers.  It points out the importance of having great colleagues, independence and autonomy, how they're treated, and that there are no politics of the feeling type.  As he states in the entry, "And this is the kind of environment you have to create to attract programmers. When a programmer complains about “politics,” they mean—very precisely—any situation in which personal considerations outweigh technical considerations. Nothing is more infuriating than when a developer is told to use a certain programming language, not the best one for the task at hand, because the boss likes it. Nothing is more maddening than when people are promoted because of their ability to network rather than being promoted strictly on merit. Nothing is more aggravating to a developer than being forced to do something that is technically inferior because someone higher than them in the organization, or someone better-connected, insists on it.".  This, no politics philosophy, is absolutely 100% true!

Of only it was more common!

Top Five (Wrong) Reasons you Don't Have Testers

...and an article on why a company, that intends to build good and reliable software should always have software testers.  Again, by Joel Spolsky.

I also dug up another very interesting experiment that the company 37signals undertook.  4 day work weeks.

Workplace Experiments

Amazingly, they got the same out of a 4 day work week as a 5 day work week.  Oddly enough people work much more diligently and effectively when they're able to get a solid weekend of separation from work.  This obviously wouldn't work with every occupation, like for instance McDonalds would probably get minimal amount of use out of 4 day work weeks, but software developers are not McDonalds employees.

Another great article in a similar vein is Increasing sustainable pace.  One of the comments is a classic combination of my railroading interests and software development, "Working more hours may not be the best solution. In the long run, working smarter always wins over working for longer periods. John Henry was the best rail spike driver in his day, and he died proving it. Power tools today let anyone work faster than John ever did.".  I firmly believe that smart workers will produce far more than a bunch of overworked code monkeys.  In my experience this has also been proven time and time again.  This blog entry led me to a few searches, which then led me to some other articles.

That has been my reading for the day.  It's been a ton but I just got on a blog reading kick and figured I'd write up what I've read as of late.

The Switching, BlogEngine.NET

Community Server is costly, elaborate, kind of cool, has a few skins, and blagh blagh blagh.  Out of all these things costly is a big problem.  Of course there is the free version etc., etc, but changing and modularity, ease of code readability, and other related items have caused me to limit what I do or do not build for my web site.  One of the biggest limitations has been the frustrating skins available for Community Server, at least the version I have.

All that said, Community Server is a 6 or 7 out of 10.  I looked at DasBlog and it is pretty decent too, probably a 7, maybe 8 out of 10.  But the one that is uber easy to setup, by far easier than those other two is BlogEngine.NET started by the cool man madskristensen.  This software, even though it doesn't follow all of the particular standards and such that I might have used, is still a top notch and ridiculously easy package to setup.  Especially if one actually uses or develops with VS.NET.  It took me about 5  minutes total, including download time, to get the whole thing setup.

So over the next few weeks things might take a bit of a back burner while I build the ETL solution for getting the comments, posts, and other such infoz from the current site to the future soon to be site.

...so stay tuned.

Joel Spolsky, A Hero of Sorts

Ok, I don't really know the guy, except that we both are rather hard core proponents of treating programmers, at least the really good ones the way they deserve - LIKE ROCK STARS!!

But Joel writes up some articles here and there and I find I agree with him on these points too, especially his article on inc.com (and on his blog here).  I'm all for a company being as productive and profitable as possible, as long as they don't lose focus on why they exist (besides to make money and stay in business).  Starbucks is one of those companies.  I love the company, but over the last 2-3 years, with the help of Portland's choices, I've all but cut out Starbucks from my expenditures. 

On that topic Joel diverges from software topics and hits up some Starbucks topics over on inc.com.  So check out the article her wrote, and hopefully Starbucks will be checking it out too.  They really NEED to.

Sure sure, sometimes I still get a Starbucks, but most of my coffee money goes to companies that still get it about product.  The product is king (right after profits to stay in business, if you aren't in business you don't make the product anymore - it is NOT a chicken or the egg scenario) - companies can NOT forget this.

For real service and good coffee, from a place that doesn't need to make up new names for what they do, check out Stumptown.  Truly pwning Starbucks in the coffee arena.

...and btw Joel, they're (Stumptown) coming to New York, and I promise if you like coffee they are worth the trip (via Subway, probably the easiest way to get there).

ReSharper Loves VAR too Much :: Tip o' The Day

So fix it.  Of course, one can have it set however they want, but I know many developers that hate being warned/told/suggested that all their explicit/implicit type declarations should be with var or vice versa.

So here is what you do, hit up the ReSharper menu and click on Options.  Then go find this set of options.  (Click for original image)

1 Find this option...

2 Set these settings...

3 They're about this far down...

Setting Sail with the Smuggling Pattern :: Part 1

Maybe because I'm often entertained by the geekiest of things, I've started usage of the Smuggling Pattern named after a fellow software architect Matt Davis's terminology of smuggling data into and out of Excel.  It is something that I've lately needed to do on a regular basis, get data into and out of Excel without Excel, or at least the evil COM Interop Model, really knowing what is going on.  In other words, I want total programmatic control over data so I can trust it versus Excel mangling my poor data up.  This is what the Smuggling Pattern is going to do for me, and it is doing it well.

Now you might think, "WTF!"  But just to clarify, the Smuggling Pattern is really the Builder Pattern that we architects know and love with a cooler more fun more pirate like name!  So with that, here's some of that code, and the TDD process I undertook to get this sucker built to set sail.

First I created a C# Class Project and created the following file folder structure and files.

Once I completed that I jumped right into testing.  Of course with ReSharper it makes life so much friggin simpler, in addition to TDD making life simpler.  I do still admit, that if you're not practiced at TDD, then doing tests in whatever order you are comfortable with still keeps you at peak performance.  But eventually you should work toward TDD and toss in a great tool like ReSharper.  The difference in speed and quality is almost like getting 2 of the 3 engineering axioms instead of just 1 (i.e. speed, quality, & cost).

The first tests I started on where the individual builder tests, or in my case the Smuggler Object.  I always create a check for null just to make sure that I named the file correctly, kind of a double check, and it gives me the attribute, category, and other parts that I can copy to the other tests easily.

using Production.Smugglers.Builders;
using NUnit.Framework;

namespace Production.Tests
{
    [TestFixture]
    public class SmugglerTests
    {
        [Test, Category("Builder Tests")]
        public void TestsSmugglerIsNotNull()
        {
            var smuggler = new Smuggler();
            Assert.IsNotNull(smuggler);
        }
    }
}

This test I ran and it proved that the smuggler does instantiate appropriately, albeit not doing a single useful thing yet.  Next test...

[Test, Category("Builder Tests")]
public void TestsSmugglerOrderCompletionResult()
{
    var smuggler = new Smuggler();
    smuggler.CompleteOrder();
    SmuggledClassForTest smuggled = smuggler.GetSmuggledSwag();
    Assert.AreEqual(smuggled.StuffTestValue, Resources.ValueForTestingSmugglerSmuggled);
}

Now this test, if you view the picture, didn't color code so well.  ReSharper points out that the instantiated class smuggler doesn't have a CompleteOrder or GetSmuggledSwag method.

image 2

Move the curser (and new character marker over the red method) and hit Alt+Enter (IntelliJ Keymapping) and select the Create method 'Smuggler.CompleteOrder'.

Now we have no more red, and the class Smuggler now has the method CompleteOrder.  The same code that is displayed in the image is directly below it so it can be copied and pasted easily.  Also note, I went ahead and added the IBuilder interface to the class since it will need to meet the contractual obligations of the builder interface.

namespace Production.Smugglers.Builders
{
    public class Smuggler : IBuilder
    {
        public void CompleteOrder()
        {
            throw new NotImplementedException();
        }
    }
}

I then wrote the following additional test, below is the additional test and the ones I already completed in total.

[TestFixture]
public class SmugglerTests
{
    [Test, Category("Builder Tests")]
    public void TestsSmugglerIsNotNull()
    {
        var smuggler = new Smuggler();
        Assert.IsNotNull(smuggler);
    }

    [Test, Category("Builder Tests")]
    public void TestsSmugglerSmuggledIsNotNull()
    {
        Smuggler smuggler = new Smuggler();
        smuggler.CompleteOrder();
        SmuggledClassForTest smuggled = smuggler.GetSmuggledSwag();
        Assert.IsNotNull(smuggled);
    }

    [Test, Category("Builder Tests")]
    public void TestsSmugglerOrderCompletionResult()
    {
        Smuggler smuggler = new Smuggler();
        smuggler.CompleteOrder();
        SmuggledClassForTest smuggled = smuggler.GetSmuggledSwag();
        Assert.AreEqual(smuggled.StuffTestValue, Properties.Resources.ValueForTestingSmugglerSmuggled);
    }
}

After that I went ahead and fleshed out the following classes to get the smuggler tests to green light.  First I stuck a resource variable in for my "test variable value".  One could do this another million ways but I figured this quick n' easy.

This resource file is located in the Properties of the project.

Find the resources by clicking the tab...

Then finished the interface (for now of course).

namespace Production.Smugglers.Builders
{
    public interface IBuilder
    {
        void CompleteOrder();
        SmuggledClassForTest GetSmuggledSwag();
    }
}

Then finished the Smuggler Class (i.e. Builder).

namespace Production.Smugglers.Builders
{
    public class Smuggler : IBuilder
    {
        private readonly SmuggledClassForTest smuggledClassForTest = new SmuggledClassForTest();

        public void CompleteOrder()
        {
            smuggledClassForTest.StuffTestValue = Resources.ValueForTestingSmugglerSmuggled;
        }

        public SmuggledClassForTest GetSmuggledSwag()
        {
            return smuggledClassForTest;
        }
    }
}

Then the little SmuggledClassForTests class, which is basically the product of the builder.

namespace Production.Smugglers.Smuggled
{
    public class SmuggledClassForTest
    {
        public string StuffTestValue { get; set; }
    }
}

Note the namespaces, I make a point to follow the standard of maintaining folder and namespace integrity.  I promise keeping the integrity makes getting to and finding code way faster than getting those things out of sync.

I then ran the tests again...

...green lights!

Some Cool Infoz for Keeping Up

John Lam is working on IronRuby at Microsoft.  This video over on InfoQ was rather interesting.  If you are curious which direction Ruby is going in the Microsoft world, this discussion gives some good insight and idea.

Look, a railroad system for Dutch Railways, being presented via a case study.  The case study being specific to how SCRUM accomplished a project that previously had failed.  The final audit of the software concluded:

• The maintainability of the system is very good.
• The quality of the source code is very high.

How can one NOT want that for the accomplishment of a project?  Come on, Lean, SCRUM, whatever you want to call it, Agile methods work, USE THEM!  The amount of failure that comes form not utilizing strong team based agile style processes is too massive to even contemplate further use in this day and age...  but enough of me ranting about non-agile methods.

Windows Live Tools have been released via a July CTP specific to VS.NET 2008.  These are something that I might actually use in the near future for some projects.  I ponder how I could utilize them in a transportation or transit related realm.

That's all I got for right now, gotta jump back into my MVC and finish mocking up some examples.

Put Those Assemblies There :: Tip O' The Day

A little post build event can help a lot when one has multiple assemblies that need to be utilized by an application.  Such as the entlib or composite library.  Just put the following script in the post build event and make sure to create a directory were the assemblies will go.  Boom - you got everything in one place were you want it!

copy /y "$(TargetDir)$(TargetName).*"  "$(SolutionDir)..\build\references\"

Social Networks OMG

Oh...

My...

God...

WTF?

I'm sitting here on the floor of the new apartment, Joleen working on a large scale multi-page poster type thing that will adorn the wall and I'm digging through various social medium online.  The nature of this social medium is rather overwhelming these days and really makes me ponder what we can achieve through increased social interaction via the computer.

As is obvious, with myspace, Facebook, and the others (I remember when Friendster was the only real site out there) people are socializing online as never before.  If I remember correctly at first, it was the fast wit, smart, or maybe just crazy people all over IRC (that's Internet Relay Chat for you noobs).  Tons of people chatting at any hour in any of thousands of chat rooms.  Then there were other chat rooms, forums, and chat with icons and emoticons moved in.  Before one realized there was just a whole mess of people blathering back and forth across the Internet.

Then came along the new trendy label of social networks.  Social networks are kind of like Web 2.0, very superficial in difference but slightly more user friendly and sophisticated.  Functionally, it isn't any different than that bunch of elite folk bantering away in IRC.  The difference now is the sophisticated part of metadata, conversation and person tagging, and the ensuing relational correlations that can be drawn.  People can find stats of stats of more stats all over the Internet now in relation to their social standing.  Mind you, there are still about 5.8 Billion people not involved with this social network of the Internet on this level, but there are about 200 Million that are.  Between Japan, China, India, Europe (and England), and the United States the surge of interaction is massive.

There are so many things out there that intend, contend, and are pushing to be THE social network medium of the future.  But it isn't the Internet as a whole they're going for but instead the Enterprise, the small businesses, the local community neighborhood, or some other niche community.  One of the sites, that I watch once in a while is Jive Software.  Jive is right here in Portland and has become one of those it places to work and talk about.  The other social medium network site that I've followed closely, especially the more I've used it is linkedin.

But I can't help but continue to wonder.  OMG, WTF!  Does this have return on investment?  Does it bring us truly more connected to each other?  Does it allow us to push ourselves even further away from those that are different and align ourselves more closely with those like us?  Does it allow for us to cut off the world we don't want and not have to deal with reality?  Were does the line stand, is there a line, what is the line in relation to all this?

Is social networking doomed to keep giving us more and more of these TLAs?  Emoticons of absurdity? 

Many questions, which only time can clarify.

Until then I'm going back to my MVC playground.

I Can't Believe This Is a Bug

I experienced this bug while trying to create a setup project today.

https://connect.microsoft.com/VisualStudio/feedback/Workaround.aspx?FeedbackID=317870

You'll choke laughing at the absurdity of this.  Microsoft - FIX NOW PLZ K THX BYE!

One word, "wow".

Just Some Excel Helpers and Respective Unit Tests

Just some semi-elegant stuff I've conjured up recently to get column names in Excel and do some other functional things.  I wrote this code in a true TDD fashion.  It still, for some reason, seems odd to me to write tests in VB, since it was always a language that encouraged dirtiness.  But alas, this is fairly solid stuff.

Imports NUnit.Framework

<TestFixture()> _
Public Class HelperTests
    <Test()> <Category("Presenter Helper Tests")> _
    Public Sub TestHelperGetExcelColumnLetterSingleLetter()
        Dim theLetter As String = Helper.GetExcelColumnLetter(3)
        Assert.AreEqual(theLetter, "C")
    End Sub

    <Test()> <Category("Presenter Helper Tests")> _
    Public Sub TestHelperGetExcelColumnLetterDoubleLetter()
        Dim theLetter As String = Helper.GetExcelColumnLetter(29)
        Assert.AreEqual(theLetter, "AC")
    End Sub

    <Test()> <Category("Presenter Helper Tests")> _
    Public Sub TestHelperGetExcelColumnDoubleLetterThirdAlphabet()
        Dim theLetter As String = Helper.GetExcelColumnLetter(56)
        Assert.AreEqual(theLetter, "BD")
    End Sub

    <Test()> <Category("Presenter Helper Tests")> _
   Public Sub TestHelperGetExcelColumnTripleLetter()
        Dim theLetter As String = Helper.GetExcelColumnLetter(2356)
        Assert.AreEqual(theLetter, "CLP")
    End Sub

    <Test()> <Category("Presenter Helper Tests")> _
    Public Sub TestHelperGetExcelColumnTripleLetterSomething()
        Dim theLetter As String = Helper.GetExcelColumnLetter(14999)
        Assert.AreEqual(theLetter, "VDW")
    End Sub

    <Test()> <Category("Presenter Helper Tests")> _
        Public Sub TestHelperGetExcelColumnTripleLetterTheEndOfZzz()
        Dim theLetter As String = Helper.GetExcelColumnLetter(18278)
        Assert.AreEqual(theLetter, "ZZZ")
    End Sub

    <Test()> <Category("Presenter Helper Tests")> _
    Public Sub TestHelperGetExcelColumnF1C1()
        Dim theColumnF1C1 As String = Helper.GetExcelColumnF1C1(3, 6)
        Assert.AreEqual("C:F", theColumnF1C1)
    End Sub

End Class

I churned out each of these tests, the first few I did at one time, counting out where the column "letters" would be derived at various column numbers.  It almost got confusing a few times.  All tests of course went red and I began coding the innards of the method.

What I came up with, after a few gotchas here and there is this.

Public Class Helper
    ''' <summary>
    ''' This method gets the appropriate "A" thru "ZZZ" column header for Excel based
    ''' on a passed in long data type.
    ''' </summary>
    ''' <param name="colNum">Pass in a long type to derive the appropriate column header letter.</param>
    ''' <returns>A string of the appropriate "A" thru "ZZZ" header letter.</returns>
    Public Shared Function GetExcelColumnLetter(ByVal colNum As Long) As String
        Do
            GetExcelColumnLetter = Chr(65 + (colNum - 1) Mod 26) & GetExcelColumnLetter
            colNum = (colNum - 1) \ 26
        Loop While colNum > 0
    End Function

    ''' <summary>
    ''' This method returns the ("A:ZZZ") part of the Range("A:ZZZ") column interface.
    ''' </summary>
    ''' <param name="firstColumn">Enter the first column to start the range with.</param>
    ''' <param name="secondColumn">Enter the second column to end the range with.</param>
    ''' <returns>A string formatted as A:ZZZ is returned from this method.</returns>
    Public Shared Function GetExcelColumnF1C1(ByVal firstColumn As String, ByVal secondColumn As String) As String
        Return GetExcelColumnLetter(firstColumn) + ":" + GetExcelColumnLetter(secondColumn)
    End Function
End Class

If you work with Excel frequently you know all about F1C1, which I decided to stick on the end of the GetExcelColumnF1C1.  Not sure if it really makes sense, but since so much of Excel is kind of just mess, I figured it might conjure the right thought in a coder's mind.

User Stories

The mumbo jumbo of use case, requirements gathering, and all that are a necessary evil of software design.  We developers cannot unfortunately just haphazardly build our UIs and other such things.  It is necessary that in some way the user interface is dictated by the users.

In the past, especially with waterfall, this has been a massive failure point for companies having software built.  The UI not reflecting actual use or features of what was actually needed (vs. what is asked for, because we all know that what is asked for usually isn't really what someone wants).  To get to what someone actually wants and needs takes multiple sessions of sitting and going through the UI.  This of course entails all the underpinning architecture and functionality too.

The crux of all this is it eats up valuable developer time, which is why the solution in the past was always to put people in between the developers and the users.  However, that just means there is another communication failure point between the user and the developers.  Major problem...

Enter, User Stories.

User stories in the agile, sometimes eXtreme Agile sense, provide an alternative way to get specifications and requirements without the customer shooting themselves in the foot.  It has been documented so many times the customer either goes beyond or doesn't provide even close to what they should in the requirements and causes development to slow to a minimum speed.  Sometimes development functionally stops while developers "thrash" and struggle to find day to day tasks.  This effectively kills a project.  I myself have seen entire projects, with burn rates in excess of a quarter million dollars (yeah, that's $250,000) a month effectively not achieve a single tangible task because of faulty and ill planned requirements.

User stories are simple, so simple that they almost cause a customer to make the application request what it should be, simple!  A simple application is by far the most useful application for a user.  The second things get complicated it is usually because of ill planned requirements that state too much or too little in the way of what is actually needed.

A user story goes something like this, "A user can create a document to provide a customer bill."  The story doesn't tell a developer what type of document it needs to be.  The story doesn't tell a developer that it needs put in a particular place or put into a bit stream or anything in an implementation sense.  The story simply states what the user needs to do to perform a business need.

The user story is something that should be able to be placed on a brochure or pamphlet as a selling point of the application.  If it is something you wouldn't put in a document like that, it is highly likely that you've either given too much or too little information in the user story.

Some specifics about user stories, and identifying a good story versus a bad or unusable story is that they must be;  independent, negotiable, valuable to the customer, small, and very important to the developer, it must be testable.

I run into a little problem with project managers, scrum leads, or whoever taking these and estimating schedule times based off of these things, but some very well respected agile proponents suggest that a user story must also be estimatable (which is not a word really, so maybe it is just a joke).  I assume that they intend to schedule and estimate a project plan of some sort with user stories.  This can be done, but a team should not be dictated a strict schedule based entirely off of user stories.  In a very Six Sigma, Lean, Agile way estimates at this level are still NOT measurable with a high level of accuracy, there is still a double digit percentile of risk involved that must be mitigated if planning is done at this level.

But I digress, back to the user stories...

Beyond the Written User Story

Beyond the basic user story there are other elements of what has to be done.  The most important part, more so than even writing down the user stories, is to communicate the user story.

During the iteration the team must get these stories and organize them in a way to have current work, backlog, and done.  Each of these unto itself is worth an article each, but I'll continue on with user stories.  Keep in mind though that each of these points is very specific in the use of user stories.

The Gurus

For more information check out InfoQ for some decent articles.  For the master of user stories check out Mike Cohn over at Mountain Goat Software.  Mike has an article titled "Advantages of User Stories for Requirements" which is a must read!

So get your user stories together, or fail. 

Brutal Week

Some weeks just suck.  From the first minutes ticking away on a Monday one can see these types of weeks coming.  When just absurd off the wall stuff starts to break.  Next the complex things break that have easy solutions, just that no one has ever seen the breakages to know the solutions.

My last week was like that.  Having just returned from the Oregon Brewer's Festival I sure hope that this week is an improvement in smooth flow.  I have big plans for this week.  First off there are major functional pieces I need to get done ASAP.  I'm on a good course, even after losing 3 plus days last week to interruptions (build issues, breakages, code problems, visual studio problems - you name it, it happened).  On Thursday I have a brown bag on the PIAB, which at this point I'm not prepared to the level I'd like.  I still need a few more demo examples and such.  Then on Friday I want to fully begin implementation of the PIAB into our architecture.  Overall, a rather big week of things to do.  In addition I'm going to be packing and preparing to move from one end of town to the other.

...I tell ya, never nothing to do.

Slashdot Quote

Someone was saying something about not seeing IT jobs in the help wanted section of the newspaper.  In response someone wrote, and I quote,

"Employers don't really expect IT people to be looking at dead tree medium for jobs."

Seriously, if you're in IT and you're digging through the newspaper, you're doing the industry and especially yourself a disservice.

I had to post this, as I love the "dead tree medium" reference.

Why Refactor?

This is why one writes unit tests and refactors.  Re: line # 13:47

[13:39] Jabley: I reverted the last change I made and it is still broke. Grrr!

[13:45] Adron: ok

[13:45] Jabley: I am just trying to figure out how the f*** to salvage this.

[13:45] Adron: kewl.

[13:45] Adron: not sure what kind of advice for that situation.

[13:45] Jabley: I desperately need to refactor my code

[13:45] Adron: I just punish myself and write it over if I fail on such a grand scale...

[13:45] Jabley: There isn't any

[13:45] Adron: and refactor a ton...

[13:45] Adron: prevents the situation from happening.

[13:45] Jabley: Thats what I am considering

[13:45] Adron: ...at least mostly prevents it.

[13:46] Jabley: I know what I did wrong but I can't figure out how to make it write in the current app without a full rewrite. That full rewrite would be a ton better because I can refactor the code, which it needs, and start it correctly with UTs

[13:46] Jabley: write = right

[13:47] Jabley: Jeez I want to kick myself in the balls right now

[13:52] Adron: ouch.

So live and learn, WRITE UNIT TESTS AND REFACTOR, the alternatives are painful.