DaedTech

Stories about Software

By

Top Heavy Department Growth

I’ve been somewhat remiss in answering reader questions lately.  Largely, I’ve lapsed because I’m choosing to focus on my upcoming book.  Nevertheless, I apologize for the lapse.  I do appreciate all the questions you folks send my way.  I’ll try to compensate today with this post about organizations engaging in top heavy department growth.

I’ll paraphrase this reader question because the specificity of the titles and information involved could make it sensitive if I didn’t take a couple of liberties.

I read your article about architect title over-specialization.  I’m a software developer with senior level experience.

Recently, my company has created “levels” above me.  I used to have only a dev manager above me.  But recently, the organization has brought in both new team leads under the dev manager and architects under a different manager.  Both take precedence over the existing developers.  These people now have authority to tell us what to do and they get to choose what they want to work on, leaving us with the leftovers.

I feel as if i’m being promoted down hill. Can you please advise?

How Companies Expand

If you’re up for it, I’ll offer a good bit of background reading to flesh out the terms.  If not, I’ll furnish minimal definitions here for reference.  A while back, I wrote a post describing the company hierarchy.  That post contains excerpts from my upcoming book, which you can pre-order and read on leanpub.

Here you have an apt illustration of the average company.  At the top, in executive roles, you have opportunistic individuals who define (and violate) the rules and culture of the company.  Then, in the middle, sit the idealists, who guzzle that same kool-aid and ask for more.  Finally, at the bottom toil the pragmatists, who roll their eyes at the company but put up with it for lack of better options.

Significantly, pyramids retain their stability by maintaining their shape.  Thus the most stabilizing growth pattern involves rewarding (over-promoting) loyal pragmatists, and hiring a bunch of grunts beneath them.  If you think of an existing pyramid that needs to get larger, you wouldn’t heap stuff on top.  Instead, you’d build from the bottom.  You’d pull some senior developers, make them architects or team leads to reward them hanging around, and hire a bunch of new grunts to report to them.

Read More

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