Category Archives: Productivity

Check In Code Frequently for Roll-back’s Sake

Leave a reply

One of the best practices around source-control is the idea of checking in code frequently. “Frequently” is, of course, a relative term. Some take this to mean checking in code within a matter of hours; others, days. Some suggest check-ins should occur every time a new feature is added. Then the question becomes: What constitutes a feature? Is a method of a class a “feature”? Is a class a “feature”? Is a feature based on a user story? A Use Case? A bulleted item in a requirements document?

For me, I’m prescribe to the practice of checking in per feature. And, by feature, I mean a Use Case (or a single flow of a Use Case), or a backlog requirement. Of course, some features take more time to implement than others. But this is ok. Sometimes, I’ll check in within a couple hours. Other times, I might check in after a couple days. Rarely, however, do I leave files checked out for more than 2-3 days (if that gives you an idea how “large” I spec these features).

key-undo

One of the many benefits of checking in frequently is that you allow the ability to rollback in-progress code changes that are not panning out. For some of you, this may be a completely foreign idea.  “Delete my code?! Are you loco??  This code was spawned from the magnificence that is my brain.  It is precious.”

If that was your reaction,… well, if that was really your reaction, then you should probably stop reading.  Wait, don’t stop reading.  I need the subscribers…  For those of you that had a bit more subtle reaction, consider this anecdote:

This morning, I was coding up a new feature for an active development project. All previous code had been checked in before starting this new feature, so I was starting from a stable build. Starting out, I was trying to figure out the best way to implement this new feature. In some cases, some up-front design and modeling would have been useful – but, in this case, where I was working with a few unfamiliar .NET classes, it made more sense to just try out a few different approaches programmatically and get a feel for which worked best.

In the span of about 90 minutes, I had implemented – and subsequently rolled back – five code changes before finding an approach that finally worked.

Some of the reasons for rolling back the first several changes included:

  • The implementation was not going to work
  • The implementation would have created more maintenance overhead than I wanted
  • The scope of the implementation became much better than what I wanted to bite off

Also while making these development changes, I noticed Visual Studio modifying a number of auto-generated files that I don’t normally touch (including project, .settings and .resx files). It would have been very difficult, if not impossible, to go through these files manually and find all the changes that were made.  But because I was rolling back all of the files via TFS, there was significantly less risk of introducing unstable code (or accidentally leaving leftover code) in a later build.  It was also considerably faster than manually traversing the code for delinquent code.

If you’re not accustomed to rolling back code in your development cycle, it’s feels kind of like this:

  • The first time you intentionally rollback (read: DELETE) your code changes, it’s kind of scary!
  • The second time, it’s a little scary, a little exciting, maybe even a little deviant-like.
  • Subsequent times, it’s empowering. And you wonder why you weren’t doing it sooner.

Control key So if you are (or know someone who is) in the camp where code check-ins are almost an afterthought, consider this example and think about the value that frequent check-ins can add to the development cycle.

The Secret: Wants vs. Needs

Leave a reply

Let’s consider the following statement:

Don’t always deliver what the customer wants;
Always deliver what the customer needs.

There’s a subtle distinction between the two parts of the above sentence, but it’s an important one.

Most of us have heard the argument "Do you really need that?" at some point in our lives, usually when it has to do with something we really want, and are willing to argue passionately about its inclusion in the realm of all things necessary. Usually, this "voice of reason" manifests itself as a parent, spouse or some incorporeal, 3-inch tall, white-robed, haloed dude – or chica – hanging out on your shoulder.

But I digress. The point is that it’s a good question to ask ourselves. Do we really need something, or is it just something we desire to have?

Wants vs. Needs in Software Development

All too often, we – the technical folks – will get a long list of requirements from our business stakeholders, some of which are necessary for them to do business, and some of which are fluff features, or “nice-to-have’s”. Unfortunately, it’s also common for these different category of features to be lumped together into the same set of requirements, and it’s difficult for us to tell which is which. It’s our own fault; we’ve conditioned our business partners to think this way.

So how do we tackle the list? Generally, I’ve seen it done one of a couple ways:

  1. We treat all requirements as gospel and just start running through the list until we burn out, project time and/or money runs out, or (rarely) we deliver everything.
  2. We start cherry-picking through the list, based on what we think the business needs.

Both scenarios have major implications. In the first, we risk burning out our teams, the business partners, or both. Burned-out folks tend to leave, or produce lower-quality results. In the second scenario, we are putting the decision of what is important to the business in the hands of the technical folks (as opposed to the hands of those who are actually doing the business work). I’ve got another post planned for this second scenario, so I’ll just leave it at that for now.

So What’s the Alternative?

Half of the Agile Manifesto talks about promoting Customer Collaboration and drawing focus to Individuals and Interactions. So, the first step is to get the business partner involved in the planning of what gets worked on first. After all, they were the source of the requirements, so they should have a good idea of what’s most important to them.

Using iterations (the backbone of iterative and agile methodologies) can also help to promote adaptive and risk-based planning by forcing the team (which includes the business partners) to decide on a subset of requirements to implement during each iteration. Responsible teams will choose features that are the highest priority. (Note the word responsible in that last sentence. Agile practices alone do not a successful team make). Iterations also help the team to "course correct" between iterations of a project if they start going in the wrong direction, or if changing business needs dictate a change in what features are most important.

And while I’ve said this before, I must stress it again. Get the customer / business partner involved. Let them tell the team what they need, and what they want. And, like that voice of reason, the team should sometimes question their needs to make sure they really are needs, and not just a want hidden behind charismatic arguments.

MSDN Article: Using XML Comments

Leave a reply

The May 2009 MSDN Magazine has a good article reviewing XML comments and their usefulness for code development and documentation.  The article is primarily written for VB developers, but the concepts do apply to C# developers as well.

I’ve been using XML comments since Visual Studio 2005 came out.  For your VB developers still developing legacy .NET 1.1 / VS 2003 apps, you can install the VBCommenter add-in, which will give you some of the basic functionality (C# developers have this out-of-the-box).

If you’re not familiar with XML comments – or if you’ve heard of them, but haven’t tried them out yet – give the article a look.

Pay Down your Technical Debt

1 Reply

I work in a financial company, so this analogy is especially poignant to those I work with.

We all know – or hopefully should know – the risks associated with being in financial debt.  At times, it makes sense to go into a little debt to buy something we can’t yet afford out of pocket (like a house or a car).  If we get into too much debt though, we end up paying all of our money in interest and don’t have enough to pay down the principal. Eventually, we may default or go bankrupt.

The same idea can be applied within IT.  Ward Cunningham coined the term Technical Debt to refer to instances where a developer chooses a poor design over a more well-crafted, sometimes “more expensive” design (in terms of time and/or effort).  At times this make sense – such as if we want to get something out to production sooner to take advantage of new features.

However, just like financial debt, we will continue to incur interest in those poor design choices even after that project goes to production.  This type of interest can come in the form of:
  • Larger maintenance effort
  • More difficulty in building upon the initial design
  • Having to perform manual operations that could have been automated.

It’s important to identify these risks and be sure to pay down the “principal” (through refactoring and re-designs) over time so that we don’t bury ourselves in too much of our own technical debt.  And, just like when paying down financial debt, it’s ok to pay down a little at a time (through small design changes/refactorings) instead of trying to make one big “payment”.

Think about any projects or systems you have on your team.  Are you incurring any technical debt from those systems?  Is that “interest” hindering your daily activities?  In what ways could you try to pay down that debt today, if you had the time?

Some food for thought…

A Coder’s Challenge

Leave a reply

I was recently “challenged” by a fellow agile member who claimed that Java developers have a higher maturity level then their fellow .NET developers.  His claim was that .NET developers rely too much on the mouse when programming, which makes them slower because their hands have to leave the keyboard more frequently.  Java developers, on the other hand, are more familiar with their tool (e.g. IDE) and all the keyboard shortcuts that are programmed into it.

So, I considered his claims and his challenge.  I scoured the interwebs, searching for the knowledge I sought that would help me master the .NET coder’s tool of choice (the great Visual Studio), until I found what I was looking for.

And so, for my fellow .NET “adolescents”, I share with you this, straight from our god herself:

You threw down the gauntlet, B.C. and I accept your challenge.

The Fallacy of Written Communication

Leave a reply

I recently stumbled upon a good post that Mike Cohn wrote a a while back on his blog about the problems that often arise from textual communication.

It is especially meaningful how he relates this, from a software development perspective, to requirements documentation and the impact it can have in that respect, as well as the day-to-day e-mail traffic that goes into and out of… mostly into… my Inbox.

I often find myself among the minority of developers who, instead of firing off an e-mail, opts to pick up the phone, or stop over for some face time with my fellow business users, business analysts or project managers. Perhaps that is the weakness of IT: brilliant (usually) at analytical and technical skills, but lackluster in social interaction skills…

Think back on the past week. How often have you opted to write an e-mail to a co-worker instead of pick up the phone or walked 10, 20, (or, god forbid, 50) feet to the person’s desk? Worse yet, how often have you been part of a conversation that took place entirely via e-mail. You know, the kind where a dozen (or more) people are included in the e-mail chain — 18 of which could care less about the discussion?

(I know I’ve brought that issue up once before…)

It is at times like these where I stand up, blow the virtual whistle (loudly) and suggest (strongly) that we schedule some face-time to hash out this discussion in person (or at least via conference call).

Now, think about what agile methodologies and practices propose to combat this issue…

Daily scrum meetings?

On-site / Nearby customers?

Manifestos?