DaedTech

Stories about Software

By

How to Turn Requirements into User Stories

Editorial Note: I originally wrote this post for the SmartBear blog.  

Let me ask you something.  When you read the title of this post, did you envision it laying out some onerous process for converting gigantic Word documents full of requirements into “user stories” in JIRA?  If so, I’ll set your mind at ease right now.  It’s not that.

Indeed, I am not talking about the mechanics of taking the square peg of “traditional, waterfall-style requirements document” and jamming it into the round hole of some ALM suite’s agile workflow.  Instead, I’m talking about the more labor intensive practice of taking a document like that and using it to generate actual, agile-style user stories.  There is absolutely a difference, and not even a subtle one.  Putting, “1.4.2.3 System shall cause cursor to blink twice after user types A key” into Jira and calling it a “user story” does not make it one.

Anatomy of a User Story

It bears asking, then, “since you say that’s not a user story, what is a user story?”  The most common way one sees it defined is via a mad lib.  “As a ______ I want to ________ so that _________.”  The definer then creates an example, such as, “As a personal banking customer, I want to know my account balance so that I don’t overdraft with my next withdrawal.”

To get a bit more philosophical, the user story has three components: persona, action, and value proposition.  The person is the “who” and it typically involves a description of a user or “actor” in the broader context of the system.  Some groups will actually define personas, give them names and characteristics, and then use the names, instead.  “Dave is a 35 year old stock broker with a checking and savings account, who…”  The user story is then, “As Dave, I want to know my account balance so that I don’t overdraft at my next withdrawal.”

The action is the way in which the user interacts with the system.  It is not framed in terms of minutiae and sequential, detailed actions.  Rather, it is framed in terms of goals that can be accomplished in a sitting.  There is a certain amount of art and subjectivity to what is an appropriate goal, but you’ll get the hang of it with practice.

And finally, there is the value proposition of the user story.  In my experience, this is the part that is both most frequently omitted and most important.  (It is also the part that is hardest to grok for people used to waterfall/contract-style requirements).  The value proposition explains why the person in question wants to do the thing in question.  And including it is particularly urgent for two reasons.

  1. If the value proposition is weak or nonexistent, you may deprioritize or eliminate this story altogether.
  2. If you hit a roadblock during a implementation of the action, you can immediately start thinking of other, more technically feasible ways to achieve the value proposition.

Read More

By

Using NDepend to Avoid Technical Debt

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.

The term “technical debt” has become ubiquitous in the programming world.  In the most general sense, it reflects the idea that you’re doing something easy in the moment, but that you’re going to pay for, with interest, in the long run.  Conceived this way, to avoid technical debt would mean to avoid taking out these “time loans” in general.

There’s a subtle bit of friction, however, when using the (admittedly very helpful) concept of technical debt to communicate with business stakeholders.  For them, carrying debt is generally a standard operating procedure and often a tool, and it doesn’t have quite the same connotation.  When developers talk about incurring technical debt, it’s overwhelmingly in the context of “we’re doing something ugly and dirty to get this thing shipped, and man are we going to pay for it later.”  That’s a far cry from, “I’m going to finance a fleet of trucks so that we can expand our delivery operation regionally,” that an accountant or executive might understand.  Taking on technical debt is colloquially more akin to borrowing money from a guy that breaks thumbs.

The reason there’s this slight dissonance between the usages is that technical debt in codebases is a lot more likely to be incurred unwittingly (or improvidently).  The reason, in turn, for this could make up the subject of an entire post, but suffice it to say that the developers are often shielded from business decisions and consequences.  It is thus harder for them to be party to all factors of such a tradeoff — a role often played by people with titles like “business analyst” or “project manager.”

In light of this, let’s talk about avoiding the “we break thumbs” variety of tech debt, and how NDepend can help.  This sort of tech debt takes the form of “things you realize probably aren’t great, but you might not realize how long-term damaging they are.”

Read More

By

What Is Reasonable to Expect from Your IDE?

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.

If you’re a software developer, there’s a decent chance you’ve been embroiled in the debate over integrated development environments (IDEs) versus text editors.  Users of IDEs will tell you that they facilitate productivity to a degree that makes them indispensable, whereas users of text editors will tell you that the IDEs are too big and bloated, and hide too much of the truth of what’s happening from you.  In some cases, depending on the tech stack and personalities involved, this can become a pretty serious debate.

I have no intention whatsoever of wading into the middle of that debate here today.  Rather, I’d like to tackle this subject from a slightly different angle.  Let’s take at face value that text editors are comparably feature-poor but nimble, and that IDEs are comparably feature-rich but laden with abstraction.  Framed as a tradeoff, then, it becomes clear that realizing the benefits of one choice is critical for justifying it.  To put it more concretely, if you’re going to incur the overhead of an IDE, then it had better be doing you some good.

With this in mind, what should you expect from an IDE?  What should it do in order to justify its existence, and what should be a deal breaker if missing?   Let’s take a look at what’s reasonable to expect from IDEs.

Read More

By

If You Build It, They Won’t Come

About a month ago, I made a post here announcing a kickstarter.  I created a character that has some popularity in the software development community and hypothesized that people might enjoy related merchandise.  My wife had some time and an interest in exploring entrepreneurial ventures, so she created the kickstarter.

We didn’t necessarily think we had a great shot at raising such an ambitious funding goal, but you never know until you try.  So, we tried.  And, unfortunately, we fell considerably short.

Before going further, I’d like to offer sincere thanks to those who backed the campaign and to those who participated in the giveaways.  We had some fun, learned a bit about crowdsourcing, and some readers got Expert Beginner swag.  While we won’t be stocked with a year of inventory and operating a shopify store, we did learn a good bit.

Product Launches by Those Who Don’t Launch Products

In the last year or so, I’ve learned a lot about business in various forms.  I listen to podcasts about freelancing, consulting, and entrepreneurship.  As I mentioned recently, I’m also participating in a mastermind group, wherein we discuss business ventures and operations.  I’m also exploring different business models and branching more into productized services.  Add that to the ongoing learning of running my business, and you wind up with a lot of inbound information.

Among all of this information comes a good bit about product launches.  If you view the world the way I’ve spent most of my life viewing it, you probably think that this means tying a bow on it, shipping it, kicking back, and waiting to profit.  For instance, you might spend a few months building a killer app for Android and/or iPhone.  When finished, you ship it to the app store, slap a price on it, and wait for users to discover it and put money in your pocket.

Sure, you’d do a bit more than that.  You’d tell you friends and family, resulting in your mom buying one to show other members of your family how proud she was of her little entrepreneur.  You’d tweet about it once or twice, probably resulting in no sales.  And then you’d surrender yourself to the mercy of the app store.

Product Launches Done Right

Most of my life, that was how I imagined product launches would go.  I even daydreamed this narrative from time to time.  Someday, I’d write a book or build a piece of software that would magically go viral, and I’d find myself on easy street.  (After all, what fun are daydreams involving the messy business of self promotion?)

Read More

By

Plugging Leaky Abstractions

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, download NDepend and play around with it.

In 2002, Joel Spolsky coined something he called “The Law of Leaky Abstractions.”  In software, an “abstraction” hides complexity of an underlying system from those using the abstraction.  Examples abound, but for a quick understanding, think of an ORM hiding from you the details of database interaction.

The Law of Leaky Abstractions states that, “all non-trivial abstractions, to some degree, are leaky.”  “Leaky” indicates that the abstraction fails to adequately hide its internal details.  Imagine, for instance, that while modifying the objects generated by your ORM, you suddenly needed to manage the particulars of some SQL query.  The abstraction leaked, forcing you to understand the details that it was supposed to hide.


Spolsky’s point may inspire a fatalistic feeling.  After all, if the things are doomed to leak, why bother with them in the first place?  But I like to consider it a caution against chasing perfection rather than a lament.

Abstractions in software help us the same way figurative language helps our prose.  Metaphors and analogies offer ease of understanding, but at the accepted price of lost precision.  If you press a metaphor enough, it will inevitably break down.  But that doesn’t render metaphors useless — far from it.

Thus, if you have a leaky abstraction, you can take steps to “plug” it, so to speak.  Spolsky says it himself, right in the law he coined: “all non-trivial abstractions are, to some degree, leaky.”  We have the ability to lessen that degree.

Read More