The question as to what the differences between Use Cases and User Stories is something that comes up quite often and some people will argue that they both help to achieve the same thing. Further discussion on that I will defer to debate elsewhere.
Over the last few years I have been using what I feel is a combination of the two elements rolled into one. One of the common held notions about User Stories is that they consist of written text that describes a functional unit of the system. Use Cases also describe functional units of work, semantically expressed through the use of the UML. My personal experience has been that the functional requirements can be well captured, represented, worked from and estimated using both approaches combined into one single method. Let me explain by way of example, where a single use case is catalogued using the following templated documents.
Figure 1.0 – User Story
What figure 1.0 shows is that we have combined the concept of several different approaches to suit. The UML for me has always been a great visual way of describing a system to both business stakeholders and developers, the BDD story title mirrors the Use Case name (UML) and the BDD story maps nicely to the Agile concept of the paragraph of text that describes a User Story. Added to that I can include scenarios to test if I am using BDD and further to that we include the document shown here as figure 2.0, the stories ‘Detail Table’.
Figure 2.0 – User Story Detail Table
The detail table I found some time ago somewhere on the web and I cant remember exactly where so my deepest apologies to the author (if you recognize it please let me know and I will update this post). Again some more context here but mainly for the developer however it’s certainly within the grasp of a business analyst. As far as estimation goes, I am an advocate of first up estimation using Case Points Estimation techniques and then factoring in subsequent estimation off velocity and burn down rates.
If you happened here by accident or design it matters not, this is a plea to all who find it. The plea is simply this:
“stop writing methods or functions that are overly deep and long”.
Do we really need to be telling each other this anymore? Isn’t this on page 3 of Object Oriented Software Development Part 1? Furthermore this is not a problem that only exists amongst developers who never had a formal training and cut their teeth on VBA. No indeed, I see this all too often and from University taught full time developers. The amount of productive time lost in trying to understand code that follows this pattern drives me crazy and I don’t know about you but I suspect most people are like me and have great trouble in retaining this kind of mess in their heads:
while (some_condition)
{
switch(some_arg)
{
case “arg1″
if(another_bool)
{
//…….etc
}
else
{
while(yet_another_condition)
{
if(nest_some_more)
{
//…ect
}
}
}
break;
case “arg2″
if(!another_bool)
{
//…….etc
}
else
{
while(!yet_another_condition)
{
if(!nest_some_more)
{
//…ect
}
}
}
break;
case “arg4″
//more of the same;
break;
case “arg5″
////more of the same;
break;
}
if (some_bool)
{
while(another_condition)
{
if(another_bool)
{
//…….etc
}
else
{
while(yet_another_condition)
{
for(int i=0;i>10;i++)
{
if(oh_my_god_another_bool)
{
//….etc
}
else if(can_things_go_on_like_this)
{
//….etc
}
else
{
//….etc
}
}
}
}
}
}
else
while(here_we_go_again_condition)
{
if(and_here_we_go_again_another_bool)
{
//…….etc
}
else
{
while(im_in_agony_now)
{
for(int i=0;i>10;i++)
{
if(my_brain_explodes)
{
//….etc
}
else if(the_project_fails)
{
//….etc
}
else
{
//….etc
}
}
switch(some_arg)
{
case “arg1″
//etc;
break;
case “arg2″
//etc;
break;
case “arg4″
//etc;
break;
case “arg5″
//etc;
break;
}
}
}
}
}
}
Now if you think this is too long then double it or triple it and then see how you feel? If your laughing by this stage then either you have never had to work with this kind of code or your laughter is a spontaneous reaction that is masking what might be better represented by tears, given that you have indeed fallen victim to this too many times. If on the other hand you recognise this as your handy work then pay attention to the message and STOP IT!
Lets face it, we have all been guilty of this at some stage and on likely more than one occasion but when recognised for the misdemeanour that it is, one should immediately do penance and mend one’s ways. So rather than merely announcing the message to cease this practice haste with, it would be remiss to let the moment pass without making some recommendations as to what to do as an alternative. There is bad design at work here: if we think of our methods in terms of behaviour then each method should implement one concise behaviour and if you want keep your concerns separated and observe the
SOLID principles, then your classes or modules should be following the
single responsibility principle. Long methods / functions usually try to express several concerns in one very crowded space, making the code hard to understand and progressively difficult to maintain - time to refactor!
