Most IT departments manage multiple projects and applications. As you go from project to project, you inevitably will find better ways to do things. Then at some point, someone might decide to get the smartest people together and come up with the one corporate framework to rule them all. All future projects will use the new framework, which makes sense because we’ve taken all of our good ideas and combined them so that other developers don’t have to go down the wrong path. I’ve had this idea before, it’s a great idea, right? We’ll have less risk of failure and we won’t constantly reinvent the wheel.

Companies think that by doing this, they will reduce the risk of failed projects. But they are buying into two things that are fundamentally incorrect — that they won’t be able to ever come up with a better way of doing things and that all projects are the same.

Ultimately what is lost when corporate standards are mandated is innovation. Developers are smart people, and many of them are trying to find new and better ways of doing things. If you don’t encourage them to find a better way, either they’ll quit trying, feel defeated because they can’t change things for the better, or get upset that the process is hindering them from getting things done better or faster.

Also, all projects are different. I’ve been on many “agile” projects, and every one did things differently. This is good because working on a two-person team at a startup is much different than working in an enterprise IT shop. I heard of one company who was trying to do an “agile transformation” so that they could find a methodology that they could standardize across the enterprise. It’s great to see people adopt agile practices (which are generally good), but trying to “standardize” so that everyone has to do things to same is directly opposed to the agile idea of continuous improvement. (Often times, the standardization of methodologies is mainly done so that common metrics can be established by which to judge teams, which encourages teams to game the system to make their metrics look better instead of solely trying to provide business value in the best way possible.)

The Alternative

What if instead of mandating that everyone used the same corporate framework, we encouraged teams to come up with the best way of doing things and then share them with other teams so that they can adopt each others’ best ideas if they so desire?

What if instead of mandating a framework, we created a repository of random pieces of code that people could pick from to do common tasks (e.g. an authentication library that authenticate to some corporate server)?

What if we stopped being obsessed with metrics and measuring teams and just went out and got the best developers that we could find, and then gave them everything they needed to do an awesome job?

I’m always looking for anything that can make me more productive and help me develop software the way that I want to. I’m going to make it easy for you and give you some low-hanging fruit that can make software development easier — use Git for source control.

But you say, “It’s just source control, what’s the big deal?”

I said this once too. Most of us at some point used TFS or SVN or some other source control system that works like that. These allow you to check out, check in, branch, and merge, and I always held my breath when branching and merging. I never thought that there could be anything more than that.

Git enables you do to a lot more than that, and it doesn’t get in your way. It does what I want, and it does it fast.

Here are some ridiculous things that I or people I have worked with have been able to do with Git that I couldn’t have done with TFS or SVN:

• Merged a release branch that we had been working on for a few weeks back into the trunk… in just a few seconds
• Reverted a few selected files from a previous commit
• Screwed up a big merge… and then reverted it so that I was back where I was before the merge… in about 1 second (git reflog)
• Switched my code back to a release that we made 3 weeks ago… again, with virtually no waiting
• Accidentally deleted a local branch that I had committed to the trunk… and then undid the delete and got the whole branch back (with all of the commits still intact) (git reflog, again)
• Changed the commit message of something I had already committed (git commit –amend)
• Pulled a single commit from the middle of another branch into the current branch (git cherry-pick)
• Squished two commits that I had in a local branch into one commit (with a new commit message) before I merged it into the trunk (git rebase -i)
• View the commit tree (with all branches and merges displayed graphically) (gitk, gitg, gitx, etc.)
• Pull a commit from another repository into my repository, showing me as the committer but the original developer as the author (github pull requests)
• Renamed files and directories… and git figured out on its own that I had done the rename and recorded it as such

I know some people are scared of Git because they don’t want to have to learn something new and confusing. The reason that I say that Git is low-hanging fruit is that it’s not that hard to learn (after all, it’s just a source control system, right?). If you want do the things that you do daily with TFS or SVN, all you’re really doing it checking in, checking out, looking at commit history, reverting commits, and maybe branching and merging. Those things are easy to learn, and then you can learn the advanced tricks that let you do the really awesome stuff.

Git will also change the way you work because now you can do things that you couldn’t easily do before. The biggest benefit of Git for me is that branching and merging is very easy and switching between or merging branches is almost instantaneous. As a result, I create a branch for every new feature that I work on, or every time that I want to try something that I’m not sure is going to work. I could never do this before because branching and merging was too slow and I didn’t completely trust that it wouldn’t become a merge nightmare. Also, if you’re using TFS, creating a branch means it has to copy the entire source tree into a new folder (as you could imagine, this takes awhile). Now that I can create a branch instantaneously or switch between branches very quickly, there’s no reason not to create one. So when someone comes over and wants me to try something on my machine, I can switch from the feature branch I was working on back to the trunk, do what I need to do, and then switch back to what I was working on.

Also, because I can have a local branch, I check in all the time. Then when I’m ready to go merge it into the trunk, I can squish and alter all of the commits to have nicer commit messages, combine ones that don’t need to be separate commits, and make it nice and clean. I kept it nice and clean in TFS and SVN too, but if I wanted to do that I couldn’t check in as often. I don’t like when my source control system prevents me from doing what I want to do.

If you still had an excuse, you have even less of an excuse because EdgeCase has an awesome Git tutorial up at http://gitimmersion.com. It’s broken up into a bunch of short, easy to read pages so that it’s not overwhelming, and you can look in the table of contents to go directly to something that you’re interested in.

Oh, by the way, Git is free. Setting it up is as easy as getting an account on a site like Github or Unfuddle (OK, those aren’t free if you want to have private repositories with multiple committers) or setting up a folder share on Windows. Can’t say the same for TFS.

Again, if you’re skeptical, I encourage you to invest an hour going through the Git Immersion tutorial and see what you think. I can’t think of anything else that will give you so much benefit for so little investment.

If you’re at a place when you don’t have a say in which source control system to you use, check out git-svn or git-tfs.

Done anything else awesome with Git that I didn’t touch on? Please leave a comment!

Most people I know put their unit tests in files that mirror the folder structure and filename of the actual class that is being tested. So if I have app/models/order.rb, I’ll have spec/models/order_spec.rb. The tests in the order_spec.rb file will test the code in the order.rb file. Every project I have been on, whether Ruby or .NET, has done it this way.

But have you ever thought about why we do it this way?

We do it this way on our project and I keep running into two problems. The first problem is when I am about to modify some existing code and I want to know what tests will test that portion of the code. The first place I look is the corresponding test file (based on the folder structure or filename), but that doesn’t always give me all of the tests for that functionality.

The second problem is when I refactor some existing code and the refactoring spans multiple classes. Now I have broken tests all over the place and it’s hard to reconstruct the tests so that they test the same business concepts that they were testing before. Often times the tests were testing a portion of the system of classes that I am refactoring, but were not as encompassing as they should’ve been.

Here’s the thing — when I write tests, I’m typically using the Given/When/Then style of writing tests, even in unit tests using frameworks like RSpec. I’ll have test code that looks like this:

describe "When completing an order" do
  it "should set the status to In Process" do
     # test code here
  end
end

That code tests functionality having to do with orders and is going to help me ensure that my code performs some business function correctly. But if you look at that code snippet, you don’t know what classes I’m testing. Yeah I know, it’s just an example and I left out those details. But the point is that it doesn’t matter what classes I’m testing. What matters is that my tests are testing that my code performs a certain business function.

That being said, why are we grouping our tests by file? Wouldn’t it make much more sense to group our tests by business function instead?

I already have ways to find tests for a given class. I can search my code for the class name, or if I’m in .NET I can do Find Usages and have a little window pop up that tells me everywhere a class (or method) is used.

If my classes were grouped in folders by business function instead, I get the following benefits:

• I can see what tests exist for a given business function
• It encourages me to write tests that test business functionality, not test data structures (classes, methods, etc.)
• I can put all kinds of tests in there (unit tests, Cucumber tests, even manual test plans) — all in one place, all checked into source control
• My tests document business functionality instead of documenting a class

Remember, code constructs like classes and methods are just a means to an end, our goal is to write software that provides business value and performs specific functions. So I might as well organize my tests accordingly.

(Disclaimer: I have never actually tried organizing tests this way. It makes sense to me and I think it would work great, but I might try it and find out that it doesn’t work. But if anything, maybe I’ll start a good discussion.)

DISCLAIMER: Nothing said in this post should be taken as a reflection of my relationship with any of my employers or clients, current or in the past. Thankfully the ones I’ve had have been pretty good.

How do you view your relationship with your employer? More specifically, what is your response to your employer’s requests and demands?

I feel that many people view the relationship with their employer like a sort of indentured servitude where you also collect a paycheck. When I say that, I don’t mean that in a negative way, because most people don’t think of their manager or employer in a bad light. But I feel that most employees feel like they should do whatever their employer asks them do without raising a fuss (unless something they are asked to do is unethical). Again, I’ve thought this way in the past, and I never really thought of my employers negatively (in fact, I really liked them).

The Business Of You

Today I would argue that this is not the correct way for you as an employee to view this relationship in most cases. (Yes, I am an independent consultant, so I don’t really have an employer, but I still work for and report to clients.)

Business have all kinds of relationships without outside vendors. For example, a business may have preferred hardware vendors, vendors that provide hosting services, vendors that provide janitorial services, and so on. These relationships are all mutually beneficial partnerships, where each side of the partnership has something to gain from the relationship. Businesses also have partnerships with software developers like you.

Whether you think of it this way or not, you are running a business. Your business sells your software development services. You have a business plan, goals, a balance sheet, and things that you value (you might not have these things written out, but you still have them). Your values for your business might be to make a certain amount of money, to work using a technology you enjoy, to feel like you’re making an impact on the company you work for, have time for whatever hobbies you like to do, and have ample time to spend with your family. Your family is also a part of your business because they are something that you value, and what happens at your place of work affects them too (either directly because you’re gone at work or indirectly because you’re stressed out when you get home).

I think you might view your relationship with your employer differently when you view it as a partnership between businesses. Businesses and vendors negotiate all the time on any number of issues (and not always related to money). If you think of it this way, instead of your employer unilaterally deciding the path for your business, it should be something that you both agree upon that is mutually beneficial for both sides.

Protect Your Business Interests

Like I said, I’ve had the good fortune of working for good people throughout my career, but unfortunately there are employers and managers out there who will try to coerce you into do things that are not in your best interest. For example, maybe you’re heard things like these from your manager:

• “We have a lot to get done this release and we can’t afford to hire anyone else right now, so you all are going to have to work a little extra to get this done.”
• “I know that I told you to build the feature that way, but actually it needs to work this way… but I still need it done by the same date.”
• (a few days before a release) “This feature just came up and we really need to get this in, I’m going to need you all to stay late to get this done.”

Overtime, while not ideal, is a part of what we do. There are going to be deadlines, server outages, and things like that. But there’s a difference between normal overtime (server outages happen and someone needs to fix them) and someone taking advantage of you either for their own benefit or because they don’t have the guts to say no to their superiors.

Every situation is different, and maybe you’re OK with these sorts of requests. Maybe you get paid overtime and you like the extra money. Maybe you are willing to go the extra mile to get ahead or get a promotion, or maybe you don’t have many other job opportunities out there so you have to stay and deal with it. Maybe you’re in a job where overtime is expected and you knew that going in.

The important thing is to think of your career like a business. If you’re employer is trying to get you do something that isn’t good for you, don’t just sit there and let their decisions drive your business. This also applies if you want to work with a certain technology or skill set and your company doesn’t have that kind of work for you. Be willing to say no, or even be willing to go find another job. Your career should be something that benefits you and benefits the people that you work for, and as soon as one side isn’t getting any benefit, then something needs to be done.

I spent my lunch hour at the Path to Agility conference talking with a friend of mine who is in the middle of trying to get his team to embrace some agile practices, particularly around automated testing. Some of the changes that he’s trying to implement are causing some friction with the team who are not embracing the change.

People not wanting to change is nothing new. But what is the reason behind that unwillingness? It’s real easy to blame the team members and just say that they don’t care, they’re lazy, they like technology X instead of the new thing, etc.

Instead of just blaming others, maybe we should look at how we (as the change facilitators) are helping to create a desire to change and an awareness that there is even a need for change. If you’ve been doing your job a certain way for the last 10 years at the same company and you’ve been getting praised for your work or getting good performance reviews and raises, why should you change? After all, your company has been telling you that you have been doing an exceptional job. And now you’re being told that the way that you’ve been doing it is wrong?

This is what makes situations like this particularly challenging. Before we can even expect people to change, we need to show them that although they have been doing a good job in the past, we have an idea of how they can do their job even better. For some teams, having 50 bugs in production each month might seem good to them if last year they had 80 bugs in production each month, when for some teams having 5 bugs a month in production is a lot.

Unfortunately there is no easy answer to this problem. In fact, I can’t even say that I really know how to effectively handle these things. What I am learning is that the people side of software development is probably the most difficult part, and it’s probably where we all need the most work.

Here are the slides, code, and links from my Testable, Object Oriented JavaScript talk at Stir Trek.

Slides
Code
JSView
Jasmine

Have fun with it, I’m always open for suggestions with this stuff, so let me know if find ways to improve it.

TDD Immersion is a half-day session where we’ll cover what you need to know to do TDD on real .NET projects. We’ll go over stuff like:

• How to write tests first
• How to refactor your code to make it easier to test
• Mocking frameworks like Rhino Mocks
• Dependency injection – what it is, how it works, and how to set it up in your project
• TDD tips and tricks

We’ll also walk through a sample ASP.NET MVC web app and show you how you might set up an actual project, work with ORMs and data access layers, set up your test projects, and make things easy to test.

This will take place on April 21 from 8:30-12 at the Microsoft office on Polaris Parkway in Columbus. We’ll have food and drinks for breakfast, so show up a little early to get something to eat. We’ll start promptly at 8:30.

If you plan on coming I need you to register so that we make sure that we have enough room and food for everyone.

We won’t be doing any hands-on coding this time, so you don’t need to bring your laptops. There is no wireless access at the Microsoft office.

Since some of you asked, here are the slides from my TDD in Action talk at CONDG last week.

I’ll be speaking on test-driven development at CONDG on Thursday, Jan. 27 at 6pm. I’ll show you some live TDD coding and explain how TDD can help you write awesome code and eliminate defects. Hope to see you there!

One thing that you’ll find on pretty much every Agile project is some kind of card wall where features are tracked.

When I started working on Agile projects several years ago, I didn’t quite understand the purpose of the card wall. I thought, wouldn’t you rather just track everything in some online tool?

While tracking things in an online tool is still a good idea, the Agile card wall gives you a level of transparency that it’s difficult to get from an online tool. With a good card wall, you can easily see what everyone is working on, what still needs to be worked on, how long the remaining work might take, and what’s blocking your progress. There is so much to keep track of on a software project, and it really helps when you have a visual aid that can help keep everything in front of you so that you don’t have to juggle everything in your mind (or some online tool).

The trick is to tweak your card wall to give you the most transparency as possible. Here are some things that I’ve found help me get the most of my card wall.

Everything is a task

Everyone puts development tasks on their card wall. However, not everything that your team does could be categorized as a deliverable feature. In fact, there are lots of other things that you might have to do:

• Write up documentation on a wiki
• Onboard a new team member
• Set up a CI build
• Get ready for a demo

These are all tasks that are completed by development team members that take a measurable amount of time. So why not create a card and put them on the board? Maybe you use a different color card to indicate that it’s an internal task. This gives you two benefits — you know what people are working on and you can use the estimate to gauge how much work is left to be done.

Make card walls for your entire team

If our development card wall can help us track what developers are working on and how much work is left, why not create card walls for the entire team? You could have a card wall for BA requirements gathering, QA creating test plans, project management tasks, or some mini-project that you want to track separately. You get the same benefits that you get with a development card wall — you know what people are working on, you can easily see the status of the effort, you can prioritize the backlog, and it can help you get an idea of how much work is remaining.

Make problems obvious

Your card wall should alert you to any problems and blockers as soon as possible. As a team lead, your job is to try and remove any blockers and constraints that could keep your team from being able to do their job. Some ways that you can do this:

• Create a separate section of your card wall for blocked items
• If something is blocking a feature, put a post-it note on the card and write what the blocker is
• Structure your card wall so that you can see problems immediately just by glancing at it

Let’s look at some examples of some simple card walls and we’ll interpret what we see.

Example #1

In this example, we can easily see that we are either developing things faster than we can test them, or things are getting stuck in testing due to bugs. We may need to assign more people to testing or work on reducing bugs.

Example #2

There are a lot of features that are blocked. We should try and address the blocking issues and look and see if there is some greater problem that is causing things to get blocked. Maybe we need to write better features, or maybe we need to get more time from people in the business who can answer questions.

Example #3

We don’t have much in our backlog, so the developers are going to be out of stuff to do really soon. We may need to get more people working on requirements gathering.

Example #4

Things are flowing pretty smoothly. We have a good sized backlog, no blockers, the work is evenly distributed, and we’re getting a lot done.

The key is that we want to see problems as soon as possible so that we can take the necessary steps to correct the problem and keep things moving.

Address technical debt as part of the process

As much as we hate to say it, sometimes we are forced to shove in lower quality, untested code in order to meet a deadline. I don’t like having to do this at all because of the risks, but when this happens, keep track of all technical debt that will need to be fixed and create separate cards for fixing it. Make these cards a different color so that they stick out. Then use your board to explain to your manager or project sponsor that you’re going to need some time to go back and fix the technical debt. Many managers want to pretend that the work is done once you release and will convince themselves that they can just move on without addressing the technical debt. You know better, and it’s your job to state that case and show why it’s important.

Refactor your card wall

Your card wall is yours. You create it, you manage it, and it belongs to you. Don’t be afraid to rearrange and refactor your card wall so that it can better meet your needs. Don’t make excuses like “we’ve always done it this way” or “we read a book that said to do it this way” or things like that. Your process and tools need to serve you not the other way around.