tag:codegardener.com,2013:/posts Code Gardener 2013-10-08T16:38:12Z tag:codegardener.com,2013:Post/357238 2013-04-08T17:28:45Z 2013-10-08T16:38:12Z Critical Path

A colleague of mine recently asked what I meant by "critical path." I gave her the following example, which she suggested I share:

Critical path is a project management term. It represents the longest running sequence of tasks required to complete a project.

For example, given the following tasks:

    • Task A takes 1 hour.
    • Task B takes 2 hours.
    • Task C takes 30 minutes.
    • Task D takes 45 minutes.

If the tasks must be completed in alphabetical order, then the critical path is A-B-C-D. And, the project will be complete in about 4.25 hours.

But, if you have a helper, and the tasks only need to start in alphabetical order, then the critical path is A-C-D. And, the project will be complete in about 2.25 hours. 

    • Elapsed Time 0:00 - You start task A. Your helper starts task B.
    • Elapsed Time 1:00 - You finish task A. You start task C
    • Elapsed Time 1:30 - You finish task C. You start task D.
    • Elapsed Time 2:00 - Your helper finishes task B.
    • Elapsed Time 2:15 - You finish task D.

But, what does an agile software developer need with an antiquated term like critical path? I was using it in the context of removing engineering work from a broader business process that could be completed faster if the other department involved could execute their tasks in parallel with engineering. So, there!

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352783 2011-11-08T06:20:00Z 2013-10-08T16:37:11Z zozi

It’s 10:15pm. I woke up at 3:30am to catch my 6:15 flight to San Francisco. I should be in bed. But, I want to get something up on the blog about what’s going on.

For those of you who don’t know already, I accepted a software engineer position with zozi.com last month. The job is in San Francisco. So, I’m traveling back and forth this month to help Jill with the move. I fly down Monday morning and home Thursday evening. It’s a bit frenetic. But, it’s worth it.

I’m too tired to write more right now. Suffice to say that I’m enjoying myself immensely and I’m learning an incredible amount of cool new stuff!

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352789 2011-09-28T23:36:00Z 2013-10-08T16:37:11Z A garden's for life...

Portia Tung:

And no matter how much we try to hurry the seed along, Nature will run its course. Assigning ten gardeners won’t make the seed grow faster. In fact, fussing about with the seed could put it in peril.

And:

As my father says, “A garden’s for life. And it needs you.” Given this commitment, it’s natural to want to make repetitive tasks, like weeding, as effective and efficient as possible so you have time to “grow” things.

I couldn’t have put it better myself.

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352795 2011-09-22T18:45:00Z 2013-10-08T16:37:11Z Banishing the Inner Critic...

Denise Jacobs on A List Apart:

Why be concerned with your inner critic? In essence, an overactive inner critic acts as a deterrent between the seedlings of great ideas and the fruits of accomplishment. Don’t think you have an inner critic? Think again. The question is not if the troll is there, but rather how big, loud, and disarmingly influential and persuasive it is.

The article is targeted at web creatives. But, I think it’s equally applicable to my last post about courage. The inner critic is what you need the courage to overcome most of the time.

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352807 2011-09-18T03:24:00Z 2013-10-08T16:37:12Z A lesson in courage...

Kent Beck in Extreme Programming Explained (first edition, page 31):

We will be successful when we have a style that celebrates a consistent set of values that serve both human and commercial needs: communication, simplicity, feedback, and courage.

Of all the agile values, courage is the one that doesn’t translate directly into specific practices. Communication is fostered by sitting together in an open space. Simple design pushes the simplicity meme, as does refactoring out duplication and YAGNI. And, feedback is built into the processes with things like Sprint Reviews and Retrospectives. But, courage? Which one of the practices embodies courage?

This is not a question I was asking myself. It wasn’t even on my mind until my test-obsessed friend and mentor, Elisabeth Hendrickson, offered to let me pair program with her on Entaggle this week. You see, Entaggle is written in Ruby using Rails, rSpec and Cucumber – tools I’ve never used. And, I have (as Elisabeth so delicately put it) “competence issues” – meaning that I have a fear of incompetence.

So, I was fairly aware that it was going to take some courage to overcome my fear of not knowing the tools in order to just sit next to Elisabeth in front of a keyboard. But, it wasn’t until we were sitting there and Elisabeth was muttering on about how she couldn’t believe she was showing me the code in such a sorry state – in need of multiple refactorings – that I realized that pairing with me took as much courage from Elisabeth as pairing with her took from me.

Suffice to say that the next time I sit down to pair program with someone, I’m going to be cognizant of the courage it took to bring both of us together with the code. I might even go so far as to recognize it before we begin pairing, just to get the fears out in the open so we can move past them.

I also think the next time I pair with Elisabeth, I’m going to muster the courage to write at least one test. (I can’t believe we didn’t write one!)

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352810 2011-09-13T12:28:00Z 2013-10-08T16:37:12Z CSS: Taking control of the cascade

CSS: Taking control of the cascade – by Jason Z. at the always excellent Signal to Noise blog by 37signals – contains the single best articulation I’ve seen on how to implement HTML5 in this example:

We began to see a relationship between our mark-up and the underlying data structure in our app’s models. HTML5’s section came to represent the model, article the individual records. For example:

<html>
    <body>
        <section class="todolists">
            <header>Todos</header>
            <article class="todolist">
                <header>Launch list</header>
                <ul>
                    <li>Get final sign-off</li>
                    <li>Deploy to production</li>
                    <li>Publish launch post</li>
                </ul>
            </article>
        </section>
    </body>
</html>

And, when combined with compiled CSS frameworks like LESS or SASS, your CSS can have the same structure, like this:

article.todolist {
    > header { 
        > h1 {color: red; font-weight: bold;} 
        > a {color: blue;} 
    } 
    > ul { 
        margin: 10px 0; 
        padding: 0; 

        > li {font-size: 13px;} 
        } 
}

Note the use of the CSS child selector (>). This selector prevents the cascading of the styles beyond the specific nodes specified. But, I’ve said enough. Go read the article already.

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352814 2011-09-11T16:35:00Z 2013-10-08T16:37:12Z Technical Debt is Something to be Managed

Paul Dyson in Technical Debt and the Lean Startup (via @KentBeck):

In a startup, technical debt is something to be managed, not minimised. We make sure we understand how much debt we have and which bits of the system it affects. We make sure we have the ability to pay down that debt as and when we need to. And, we make sure we work the time and money required to pay down the debt into any timescales or budgets we agree.

The whole piece is great. Worth a read. If I would change anything, I might apply the same thinking more broadly: “Technical debt is something to be managed, not minimised.”

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352830 2011-09-11T00:39:00Z 2013-10-08T16:37:12Z Roles on Agile Teams

Elisabeth Hendrickson, in Testing is a Whole Team Activity:

Testing is an activity. Testers happen to be really good at it. We need testers on Agile teams. But, if we want real agility, we need to see that completing testing as part of the sprint is the responsibility of the whole team, not just the testers.

To which my brain immediately responded:

Programming is an activity. Programmers happen to be really good at it. We need programmers on Agile teams. But, if we want real agility, we need to see that completing programming as part of the sprint is the responsibility of the whole team, not just the programmers.

Thing is, you could put any traditional software development role (e.g. “planner”, “builder”, etc.) into that paragraph and it would work. Try it. It really works.

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352832 2011-08-31T18:24:00Z 2013-10-08T16:37:12Z Kent Beck's Ideal Job Description

From Kent Beck’s Idea Job Description (written as a letter of recommendation 3 years from now):

We brought Kent on board with the premise that he would help our existing and new engineers be more effective as a team. He has enhanced our ability to grow and prosper while hiring at a sane pace.

Sounds like future Kent had fun on that assignment! But, he also tweeted this:

just wrote my ideal job description. now i’m terrified I won’t get it.

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352833 2011-08-30T11:11:00Z 2013-10-08T16:37:12Z Internet Tools for Small Business

I met a small businessman seeking advice regarding his website the other day. After discussing his needs for a few minutes, I discovered several potential pain points with his existing infrastructure. In this post, I’ll describe the problems I saw and dole out some free advice.

What issues did I see?

  • The company was unable to obtain it’s desired .COM domain name; so it purchased the same name under the .NET domain. This would be fine ordinarily. But, it turns out that the .COM domain name actually belongs to another company in the same industry. So, anyone who mistakenly types .COM rather that .NET will end up on the other company’s website.
  • Next, in order to put on a more professional face, the company also purchased a .COM domain for email. Both domains were purchased through the same hosting company. But, the .COM domain is used exclusively for email, while the .NET domain is used for hosting their website. So, now, if someone tries to navigate to the website at the email address on the fellow’s business card, they are presented with a generic “Under Construction” page, rather than their existing web site.
  • Maintaining the existing web site requires technical skills that don’t exist at the company. 
  • Finally, the company’s email system is not meeting their needs. Inboxes are limited to 100 MB, or 80 times less space than GMail. And, large file transfers are particularly problematic.

So, what would I do about these issues?

  1. First things first: Move the web site to the .COM domain and redirect the .NET domain to it. Now, it doesn’t matter which address people use, they’ll end up on the more prestigious .COM domain. That solves both 1 and 2, above. This would likely not cost a dime.
  2. Next, I’d move the site to a content management platform, like WordPress or TypePad, that would allow non-technical staff to make changes to the content of the site without requiring the assistance of a programmer. This might cost a few dollars a month. (I’d also highly recommend redesigning the site in the process, which would cost more than simply porting the existing site, but would pay off in improved retention of customers.)
  3. Third, I’d recommend moving the company’s email over to either Google Apps for Business, or Microsoft Office 365 – both of which can be used with a custom domain name. This would cost $5 (Google) or $6 (Microsoft) a month per user. 4 And, for the extra large file transfers, I’d probably recommend something like Dropbox.com.
  4. I might also recommend transferring the domains to a new DNS host like DNSimple.com, allowing them to turn off their now superfluous web host.
  5. Finally, if the company chose to redesign their web site, I would also recommend a business card redesign, using the same motif as the web site to bring some consistency to the brand. I’ve used Moo.com to do exactly this for Code Gardener.

Yes, these changes will likely raise the cost of the company’s web infrastructure, possibly even by as much as an order of magnitude (from $10 to $100 per month.) But, overall, the administration will be simpler, and they won’t need to hire developers to make simple changes to their website. So, in the long run, the company will likely save money.

Full disclosure: Those links are referrals. If you follow them and sign up for an account, I get Moo Money from Moo, more free space from Dropbox or a month of free service from DNSimple. But, there’s something in it for you, too: Both Dropbox and DNSimple will give you the same thing they give me when you sign up.

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352835 2011-08-25T05:22:00Z 2013-10-08T16:37:12Z So, what do I mean by "Agile?" (Part 3)

Release and Iteration Duration and Structure

Release and Iteration lengths are highly dependent upon local circumstances. But, given the ability, I prefer to do Quarterly Releases and Weekly Iterations.

Quarterly Releases

Quarterly Releases may seem like a long time. But, many businesses are incapable of absorbing change much faster than that. So, unless you’re at a web start-up or in a highly regulated industry, I say try to match your release schedule to an existing organizational heart beat, like quarterly financial reporting. (Though, perhaps you don’t want to try to release new code the same day, week, or month you release financials.)

As for the structure of a release, here’s what I like to see:

  • Twelve development iterations with one day of slack each
  • One review, deployment and planning iteration

Alternatively, I could also support a structure that looked more like this:

  • Three development iterations
  • One slack iteration
  • Three development iterations
  • One slack iteration
  • Three development iterations
  • One slack iteration
  • One review, deployment and planning iteration

A development iteration is a normal iteration. The customer pick stories for the team to build, as described above. A slack day or iteration is just like a development day or iteration except that Team decides what work to take on, from exploratory testing to refactoring items on the Technical Debt Backlog, to spiking new technologies. No new stories are implemented during slack time, though new tests may be added to shore up code coverage. And, the review, deployment and planning iteration is exactly that: review the release, deploy it, and plan the next release.

Weekly Iterations

Short iterations allow for rapid customer feedback. Longer iterations allow for more work to be accomplished. In my experience, Weekly Iterations provide the best balance between getting stuff done and running off into the weeds. Plus, it has the side benefit of guaranteeing you your weekends off!

I like to see the following structure to iterations:

  • Planning happens first thing in the morning on the first day of the week.
  • Review happens on the afternoon of the last day of the week
  • The rest of the time is devoted to implementing user stories, exploratory testing, etc.
  • Except for weekends, which are reserved for personal use
]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352847 2011-08-25T05:18:00Z 2013-10-08T16:37:12Z So, what do I mean by "Agile?" (Part 2)

As I hinted in my previous post, planning is broken down into three levels:

  • Product Planning
  • Release Planning
  • Iteration Planning

As I am not a product planner, I will not try to discuss how that process happens. Rather, I’ll focus on the active development process through Release and Iteration Planning. First off, I like some to see symmetry between releases and iterations. The only difference is the scale at which the two types of planning occur. Specifically, I like both releases and iterations to include:

  • Planning,
  • Review, and
  • Retrospective

Here’s what I mean by each…

Planning

Each release and iteration should begin with a planning session designed to select some number of user stories from the parent backlog for inclusion in the current cycle of the process. For example, during Release Planning, user stories are selected from the Product Backlog for implementation in the next Release.

Review

Each release and review should end with a review meeting wherein the Product Owner (and other stakeholders) is shown the running acceptance tests and asked to approve or reject them. If an item is approved, it becomes part of the next release. If it is rejected, it is placed into the backlog for the next iteration (or release, potentially). These meetings are also often the source of additional user stories for the backlog. For example, the Product Owner may accept a user story as it is, but desire that something about it change in the next iteration before accepting the feature in the release review.

Retrospective

At the end of each iteration and release, after the review meeting, the whole team should get together to discuss process improvement. Some teams do this without the Product Owner. I recommend including them, as their perspectives are valuable and it serves to reinforce the concept of the “Whole Team.”

Next up: Release and Iteration Duration and Structure

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352849 2011-08-25T05:13:00Z 2013-10-08T16:37:12Z So, what do I mean by "Agile?" (Part 1)

Since you’re reading my blog, I’ll assume that you’re either a relative, or you’re already somewhat knowledgable about agile software development. So, let’s jump right in... (Sorry, Aunt Gina.)

Given my drothers, I prefer to mix and match terminology and practices from Scrum and Extreme Programming. Here’s what I like to do:

Roles & Responsibilities

Product Owner is responsible for: 

  • Defining and/or collecting the set of features to be implemented in the product
  • Maintaining a Product Backlog of User Stories ordered by Business Value
  • Presenting user stories to the Team during Release Planning
  • Selecting user stories to place on the Release Backlog
  • Presenting user stories to the team in more detail during Iteration Planning
  • Selecting user stories to place on the Iteration Backlog
  • Accepting or rejecting user story implementations during Iteration Review
  • Presenting implemented user stories to other stakeholders during Release Review
  • Determining whether or not to deploy software during Release Review
  • Answering questions from the Team throughout the process

The cross-functional Development Team (or Team) is responsible for:

  • Estimating stories with T-shirt Sizes during Release Planning
  • Estimating stories with Story Points during Iteration Planning
  • Splitting large (epic) stories into smaller, more manageable stories 
  • Calculating their team velocity using Yesterday’s Weather 
  • Incremental Design and Test-First Programming of user stories
  • Maintaining a backlog of Technical Debt
  • Maintaining code and test quality with Refactoring
  • Presenting implemented user stories to Product Owner during Iteration Review
  • Assisting Product Owner with presentation of implemented user stories at Release Review
  • Asking questions of the Product Owner throughout the process

Coach (or Scrum Master) is responsible for: 

  • Identifying and resolving roadblocks hindering the Team, including, process, technical and managerial issues, and more.

The Whole Team, which includes the Product Owner, Development Team and Coach, is responsible for:

  • Conducting Release and Iteration Planning meetings
  • Conducting Iteration and Release Review meetings
  • Conducting Iteration and Release Retrospective

Next up: Release & Iteration Duration and Structure

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352857 2011-08-21T13:50:00Z 2013-10-08T16:37:12Z More pictures from p&p

While I was with patterns & practices, Microsoft invested a considerable sum of money to build the team a custom space that that lent itself to agile software development. My friend Darrell Snow was largely responsible for securing the project and shepherding it through the 40 some odd cooks who want to put their fingers in the stew. Overall, it turned out amazingly well - though the team spaces could be a bit bigger, IMHO. Even so, I really miss working in that space.

Most of the photographs below were all taken shortly after the team moved into the space. For context, the first picture shows what our team room looked like before the new space and the second picture is a floor plan of the new space.

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352861 2011-08-21T07:26:00Z 2013-10-08T16:37:12Z The Definition of Legacy Code

From Michael Feathers' outstanding Working Effectively with Legacy Code:

The main thing that distinguishes legacy code from non-legacy code is tests, or rather a lack of tests.

In other words, if you’re still writing code without tests, you’re still writing legacy code.

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352869 2011-08-19T07:55:00Z 2013-10-08T16:37:12Z Some people doodle…

I think up silly tag lines for things. Here are a few of my favorite tag lines for Code Gardener:

  • That’s a big ball of mud!
  • Better get your Wellies
  • Have Wellies will travel
  • Get your hands dirty
  • Roll up your sleeves

But, the one I’m currently using is still my favorite: Weed & feed your software.

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352879 2011-08-18T23:00:00Z 2013-10-08T16:37:12Z Nostalgia

While trying to figure out how to SEO this new site, today, I ran across a few pictures from my time at Microsoft. It brought back some fond memories. One thing I've got to say for that company that you don't often hear is that their facilities are amazing - especially the p&p offices and the conference center where these shots were taken.

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352881 2011-08-18T20:55:00Z 2013-10-08T16:37:12Z Business Cards

Code Gardener Business Cards After coming up with the new logo for Code Gardener, I thought it'd be fun to get some business cards made up. So, I downloaded a free trial of Adobe Illustrator (which I now know that I truly need - there goes $600!) and created a card based on the same design. I'm not completely happy with the placement of the text. But, it's a good first draft.

I'm having moo.com print them right now. Click that link and buy something! I'll earn referral points that I can put toward my next order. Go ahead! Give it a try!

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352883 2011-08-18T17:24:00Z 2013-10-08T16:37:12Z The Debt Metaphor

I love listening too Ward Cunningham discuss the way he thinks. In this video, he "reflects on the history, motivation and common misunderstanding of the 'debt metaphor' as motivation for refactoring."

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352893 2011-08-15T05:55:00Z 2013-10-08T16:37:12Z New digs…

So, I got tired of fighting WordPress and spending money to host it. I wanted something a bit simpler that would let me focus on writing. So, I’ve moved CodeGardener.com to Posterous, and refreshed the look considerably.

I’m still not done with the redesign. The links in the navigation pane aren’t all working yet. And, I need to work on the other views (search, tags, etc.) But, the general look and feel is pretty much complete.

Overall, the process has been pretty smooth. It was refreshingly simple compared to WordPress. Though, Posterous has a nastly little habit of applying styles to your content without your knowledge. As I discover ones I don’t like (e.g. the large-quote, medium-quote, small-quote nonsense), I’ll stomp on them with some CSS of my own.

Best of all, I’m sending this post via email, which is exactly what I wanted. Hopefully, I won’t have to spend several minutes fixing it once it hits the web.

UPDATE: Raw email didn’t handle paragraphs the way I wanted. Let’s try using Markdown.

UPDATE 2: Markdown works great! Might even want to go back and implement it more broadly throughout the site, since it’s so much easier to read than HTML.

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352895 2011-08-13T22:08:00Z 2013-10-08T16:37:12Z My approach to agile testing...

I’ve talked about agile testing before, here, here and here. But, a recent thread on the Alt.Net Seattle Google Group got me thinking about it again. Here’s the response I sent to the thread:

Testing is a huge domain. If you’re familiar with Marick’s testing quadrant, you know that there are four basic areas that testing covers:

  • Business Facing tests in Support of Programming (Business Requirements testing – Does the code do what it should?)
  • Business Facing tests to Critique the Product (Business Defect testing – Does the code do something it shouldn’t? Are there missing requirements?)
  • Technology Facing tests in Support of Programming (Technical Requirement testing – Does this method do what the developer intended?)
  • Technology Facing tests to Critique the Product (Technical defect testing – Are there leaks? Can it handle a load? Is it fast enough?)

Typically, testers focus on the business facing tests. And, people with specialized technical skills focus on the technology facing tests. (Developers on the support programming side; Performance testers on the critique product side.)

None of these tests can be run before the software is written. But, the tests in support of technology can be written before the code. And, metrics for perf/load/stress can be defined before the code is written. I recommend doing all of that (unless perf/load/stress isn’t important to you). Obviously, exploratory testing is something that has to wait for the code to be written.

If I were designing an agile team from scratch, I would propose the following approach:

During planning:

  • Track requirements as user stories.
  • Document acceptance criteria with each story, including perf/load/stress criteria (on the back of the 3x5 card, in Rally or TFS, etc.)

During an iteration:

  • One pair works on one story at a time.
  • Acceptance tests are automated first, based on acceptance criteria.
  • Code is written using TDD
  • Story is not functionally complete until all acceptance tests are passing (for the right reasons – no hard coded answers left)

After story is functionally complete:

  • Original pair leverages existing acceptance tests in perf/load/stress tests to determine if those criteria are met.
  • Tweak code as necessary to meet perf/load/stress acceptance criteria.
  • Story is not perf/load/stress complete until all perf/load/stress acceptance tests are passing

Exploratory testing should happen outside the constraints of a single story:

  • Limiting it to a single story would put blinders on that could negatively impact the effort. But, it is important that it happen.
  • Perhaps the team sets aside time during the day or iteration for banging on the software.

Once all acceptance tests are passing:

  • Ship it!

Variations:

  1. Have the entire team bang out the acceptance tests at the beginning of the iteration.  I’ve seen this done. It works. But, quite often, tests get written for stories that end up getting cut from the iteration due to time constraints. That is excess inventory sitting on the production floor until those stories make it into another iteration. In other words, doing this encourages the accumulation of waste.
  2. If you’re concerned about a single pair working a story from beginning to end, mix it up. Give pairs one day to work on something, or 4 hours, or two, whatever works for you. Then switch things up – preferably by keeping one person on the story and bringing in a new pair. Then, the next time you switch, bring the older pair leaves.
  3. Even though exploratory testing should not be constrained by a single story, it really is important to do it before shipping the software. Microsoft calls this a bug bash. They give away prizes for the most bugs, and the hardest to find bugs. But, they don’t do it until very late in their process. It would be most agile to do it continuously.

How do you do agile testing?

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352786 2011-08-04T23:21:00Z 2013-10-08T16:37:11Z HTML5 and CSS3 in Visual Studio 2010

As a web developer looking to stay current, I’ve been trying to do all of my personal projects in HTML5 and CSS3 for some time now. In fact, browser support is generally outstanding. Unfortunately, the lack of tooling support has made it a bit more difficult. But, now that’s all changed.

Assuming you’re running Visual Studio 2010 SP1, you can download and install the Web Standards Update for Microsoft Visual Studio 2010 SP1, which will add IntelliSense support for the latest updates to HTML, CSS, and JavaScript.

In case you’re looking for more information: here’s a link to the announcement, and a link to Scott Hanselman’s demo of the release.

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352788 2011-07-29T20:03:00Z 2013-10-08T16:37:11Z Deadlines cause poor decisions to be made slowly

In an article published in The Washington Post on July 22, Daniel Carpenter discussed why our government always seems to be working down to the wire. He blames deadlines (both real and conjured), stating that the "eleventh-hour effect" tends to delay decision making until the last possible moment:

When deadlines are imposed, decisions and bargains that could happen more quickly — because of momentum or normal work flow — often end up getting put off until the last minute. Social scientists have referred to this as the "eleventh-hour effect," and we see it both in experiments and in real life.

Furthermore, as a Harvard researcher studying the effect of deadlines on the FDA drug approval process, Mr. Carpenter and his colleagues discovered that drugs approved close to the Congressionally imposed deadline tend to be recalled often than others:

A few years ago I joined some Harvard Medical School colleagues in examining the deadlines that, since 1992, Congress has placed upon the Food and Drug Administration's drug reviews. Our research found that medications approved right before these deadlines were considerably more likely to be pulled from the market or have significant warning labels attached later on.

In other words, deadlines cause poor decisions to be made slowly.

I must admit, as a proponent of agile software development practices such as continuous, iterative planning, I find more than a grain of truth in this statement — and not just within the bounds of our government. In fact, it has been my experience that deadlines rarely encourage people to complete their work early, as the task at hand tends to fill the time available. And, besides, experience has also taught me that deadlines often seem arbitrary, feel capricious, and demotivate teams. (Details in footnote.)

Granted, businesses need to be able to plan around software development projects. There are end-users to train, products to market, and systems to integrate. And, no matter how arbitrary it may seem to software developers, a deadline does provide a business with a stake in the ground around which to plan these other activities. In this sense, deadlines perform a valuable service to the business. However, due to the "eleventh-hour effect" and the rush to finish work on time, deadlines can also do quite a bit of harm to an organization's systems.

Therefore, my preference is to manage projects using a stack-ranked, estimated backlog of user-stories and team velocity. The backlog shows me what's complete, how much work remains, and in what order it will be completed. The team velocity tells me when I can expect a specific story to be completed.

So, if I have a specific business need to see story X completed by date Y, then I can make the appropriate adjustments to the stack-ranking of the backlog without putting undue pressure on the development team. Furthermore, because user-stories are discreet, end-to-end slices of functionality, I can deploy them as soon as there’s sufficient business value to offset the costs of deployment.

The only question I have is could this management strategy be effective in Congress?


Footnotes:

  1. Early in my career, I worked for a man who threatened to fire his entire development team if we did not ship all the projects we were working on by the end of the month. This is what I mean by an arbitrary, capricious and demotivating deadline. Oh, we managed to meet the deadline. It took some serious corner cutting. But, we shipped the software. In the end, though, it didn’t matter. We all left the company within three months, anyway.
  2. Hat tip to Ezra Klein, also of The Washington Post, for [the reference to the Carpenter article](http://www.washingtonpost.com/blogs/ezra-klein/post/the-downside-of-deadlines...).
]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352797 2011-03-07T20:52:00Z 2013-10-08T16:37:11Z The Transformation Priority Premise

I just read the most brilliant new idea that I’ve seen since I learned TDD and Refactoring ten years ago. Naturally, it comes from the brain of Uncle Bob Martin. It’s called “The Transformation Priority Premise.” I’ll describe it briefly here. But, if you want to really understand it, you should go read Uncle Bob’s blog yourself:

Ok… So, what is the Transformation Priority Premise?

If you are familiar with Test Driven Development, you know the phrase “red, green, refactor.” That phrase encapsulates the process of writing tests before you write the code:

  • Red = Write a failing test and watch it fail.
  • Green = Write just enough code to make the test pass.
  • Refactor = Remove any duplication in the code without changing it’s behavior (all tests should still pass).

And, if you’re familiar with Martin Fowler’s book “Refactoring,” you know that a refactoring is a simple change to the structure of the code that is guaranteed not to change the behavior of the code. These are things like:

  • Introduce Variable – Replaces a constant with a variable.
  • Extract Method – Extracts one of more lines of code from one method into another (new) method.
  • Rename – Renames a variable, method or class.

These changes are so easy to implement that we can actually build tools that do them for us. Visual Studio comes with a handful of built-in refactorings. ReSharper adds significantly to that list.

What Uncle Bob is proposing is that there are similarly simple “Transformations” that change the behavior of a code base. Furthermore, he states that there is an order or priority in which we should apply these transformations – from simple to complex. He proposes the following (admittedly incomplete and probably mis-ordered) list:

  • [] –> nil
  • nil –> constant
  • constant –> constant+
  • constant –> scalar
  • statement –> statements
  • unconditional –> if
  • scalar –> array
  • array –> container
  • statements –> recursion
  • if –> while
  • expression –> function
  • variable –> assignment

Don’t worry if that doesn’t make any sense. I really just blogged it so I’ll have a quick reference. But, what’s cool about them is that they can actually help us pick which tests we should write in what order. For example, if we decide to write a test that requires us to add an if statement to our code, that test requires the “unconditional –> if” transformation. Knowing that, we can try to think of other tests that rely solely on transformations higher up the list.

The ultimate reward is that by writing our tests using transformation priority order, we should not ever get to a point where one test causes us to rewrite an entire method. Furthermore, because these transformations are all relatively simple in and of themselves, smart tools vendors may be able to build support for them directly into tools like ReSharper.

I’ve probably just confused the heck out of you with all this. Suffice to say that Uncle Bob’s posts are excellent. They include source code that he uses to show you how not using the priority order causes pain, and how using the priority order resolves that pain.

What are you waiting for? Go read those posts!

(Oh, and for those of you unfamiliar with Uncle Bob’s work, he references something called a Kata several times. The term comes from martial arts. It refers to a movement that is practiced over and over and over until it becomes second nature. Think “wax on, wax off”. Uncle Bob is a big fan of solving the same problems over and over and over to gain new insights into the potential solutions. And, he’s published several Katas ranging from calculating a bowling score to identifying prime factors of an integer. They’re worth your time, too.)

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352802 2011-01-04T00:15:00Z 2013-10-08T16:37:11Z iPad @ Home

The week after Thanksgiving, my wife called me at work from our treadmill at home:

“We need an iPad for the treadmill,” she puffed.

“Um, well… Okay!” I replied, trying not to sound too eager. “But, only since you’ve identified a use case.”

“Funny,” she huffed over the sound of her eyes rolling.

“Um… Okay. You’re serious?” I say, skeptically.

“Yes, as long as I can watch Netflix on it.”

“Sure. You can watch Netflix on it.”

“Okay.”

“Okay.”

“You pick it out. We’ll make that our big Christmas present to each other.”

“Really!?! You sure you want me choosing?”

“Yup. Just don’t, you know, go crazy.”

“Oh, well, of course not.”

Long story short, my household is now the proud owner of a shiny new iPad 16GB 3G. And, surprise! We love it. Jill’s been doing Netflix. I’ve been reading the news and surfing. The kids really like the Disney Read-Along™ story book versions of Toy Story and The Princess and the Frog. And, really, who wouldn’t love Angry Birds and Fruit Ninja? There’s just one problem…

We only have the one.

But, there’s no sense buying another one right now, since the iPad 2 should be here this spring.

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352819 2010-12-22T20:59:00Z 2013-10-08T16:37:12Z Apple’s iPad finds a place in the enterprise

This article in MacWorld, today, reminded me of something I learned last week at a Microsoft technology briefing. During a discussion of Microsoft’s strategy related to the iPad, Microsoft’s representative asked how we’re using iPads today. I already knew we were developing sales tools and looking to find ways to make our applications accessible from the device. But, I didn’t know that our board is using iPads extensively. In fact, all of the documents for our last board meeting were distributed and reviewed on iPads. Everyone in the meeting had an iPad and could follow along in the documents as the presenter talked. And, apparently, even our septuagenarian board members loved it!

How else might we use iPads (or other tablet computers)? Clearly, those of us who write software every day won’t be using them for that. But, what about email and note taking in meetings? I’ll bet most managers in the company would gladly give up their laptop for an iPad, as long as it was able to open documents on SharePoint, crunch a few numbers and provide access to their email, and do it all securely.

What are your thoughts? Is there a job function around here that could benefit from a smaller, more portable computer?

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352827 2010-12-18T00:01:00Z 2013-10-08T16:37:12Z Securing WCF Services: Preventing Unauthorized Access

Suppose you are writing a web service to perform a sensitive calculation. Your web service should only be accessible by authorized users and/or applications. Here’s my advice for configuring your service:

Use .NET to Your Advantage

.NET has built in features for ensuring that the code calling yours is authorized to do so. For example, take a look at this snippet of code:

[PrincipalPermission(SecurityAction.Demand, Role = "MyLocalSecurityGroup"]
public SearchResults Find(string contractNumber)
{
    ...
}

Notice the [PrinciplePermission] attribute. This attribute tells .NET that only principals who are members of the "MyLocalSecurityGroup" role are allowed to run this method (where a principal is a user/service account, and a role is a locally defined security group on the server). In other words, in order to run this method, the caller must be running under an account that is a member of the local security group specified.

Local Security Groups

By telling your code to check a security group on the local server, you get around the problem of having to care about the different test regions in your code. The local group on your DEV server will contain only those accounts which are authorized to access the service in DEV. Likewise, the TST and PRD local security groups will only contain accounts authorized to access TST and PRD respectively.

Domain Security Groups (NT Groups)

Of course, you don’t want to manage access at the local server level. Rather, you want to let User Account Services (UAS) manage access centrally. The way to do this is to create domain security groups for each test level. For the middleware, I created these groups.

  • MyDomainSecurityGroup.DEV
  • MyDomainSecurityGroup.TST
  • MyDomainSecurityGroup.PRD

Then update the local security groups on your servers to ONLY contain one of these domain security groups. If the server is a DEV server, put the DEV make the DEV domain group the only member of the local security group. All other user/service accounts should be removed from the local security group and added to the appropriate domain security group.

Conclusion

If you follow this pattern to secure your web services, you’ll be able to prevent unauthorized access to your service by adding a single line of code to every method that needs to check authorization. Furthermore, in a more complex scenario – say one where users may have read, write or admin access to your service – you can create as many local and domain security groups as you need to ensure that users and applications have the lowest level of access required to do their work.

One final thought: If you web service is hosted in across a pool of servers, remember to create the local security groups on all of the servers. You could probably do this with your installer. Or, you could make it a manual step in your implementation plan that only gets executed once.

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352829 2010-11-12T17:10:00Z 2013-10-08T16:37:12Z Friday funnies

Ok. This thing completely nailed me – right down to the “unavoidable stubble-beard!” How about you? My only quibble is that the infographic designer saw $85,430 as a full cup. Maybe there’s a bigger cup somewhere – call that the venté employer.

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352844 2010-10-21T18:41:00Z 2013-10-08T16:37:12Z WCF Service Configuration Explained

If you’re like me and not really all that sure what all that goop is in a WCF web.config file, you may find this article by Microsoft MVP Keith Elder as useful as I did.

]]>
Alan Ridlehoover
tag:codegardener.com,2013:Post/352855 2010-09-28T23:57:00Z 2013-10-08T16:37:12Z ReSharper Tip #123: Creating new classes and moving them to their own file

As I was writing all the source code for my last post, I relied heavily on ReSharper: first to generate classes for me, then to move them to a new file named the same thing as the class. This is a particularly handy technique if you practice Test Driven Development. Here’s how:

When I write a test, I write the whole thing, even though some of the classes may not exist, like this:

image

By placing my cursor on the class name (the red text) and pressing ALT+Enter, I receive the following ReSharper menu:

image

This generates the class in the same file as the test fixture. This is convenient at first. But, it’ll be impossible to find later, so I use ReSharper to move the class to a new file, again by placing the cursor on the class name and pressing ALT+Enter:

image

Which results in this:

image

Me like!

]]>
Alan Ridlehoover