In most companies, there is a definite divide between the development team and the QA team. They don’t sit together in the same area, they don’t have the same boss, and they often aren’t even working on the same project at the same time. Sometimes the QA team doesn’t get involved until it’s time for the “testing phase.”

To me, this all makes no sense. I’ve been on teams like this, and the same thing usually happens — developers develop something, and when the QA team starts to look at it, they don’t know the first thing about the feature that was built. They try to come up with a test plan, but they don’t come up with all of the edge cases because they don’t know enough about the feature. Other times they come up with something that the developers hadn’t thought of, or they find bugs because the developers didn’t do anything to test their own code (even manually).

Before we go any farther we have to dispel two common misconceptions about the role of a QA team.

Some people think that your QA team is like a college professor giving you an exam. You learn about a feature from the BAs or the users, and then the QA team is there to verify that you understand everything after you’ve written the code. The QA team shouldn’t give you their test plans because then you might just write the code to make their test plans pass (heaven forbid!). That’s like your professor giving you the answers to the test, and that’s cheating. (I’m being sarcastic, of course.)

Other people think of the QA team like a group of external auditors. You don’t know when they’re testing or what they’re testing. They’re just here to catch you screwing up. They have to be extremely thorough and cover all the bases to make sure that nothing gets through, regardless of whether the development team has written any automated tests.

I would much rather work together with QA people. I would rather come up with the test plans together so that we can make sure that I automate most of their tests for them and build the right thing. I would rather have QA people involved up front so that they can help me think about how something should be tested. They also are very good are finding holes in requirements that no one else though of, which is very valuable to have up front before we right any code.

The hard part in all of this is getting people to work together who typically don’t work together. Usually developers and QA have different managers, and developers and QA people might not even be working on the same projects at the same time. You might need to get your management to work together to get people on the same teams working on the same projects at the same time.

We’ve been doing all of this on our current project and we’re really starting to see some exciting things. Much more on this to come!

I spent the last year or so working on a Ruby on Rails project and now I’m back in the .NET realm again. I’ve been asked to write about what that year working on a new platform taught me and how I’m applying it to .NET, so here goes.

I love the Ruby language

I really really like Ruby as a language. You can write good code in Ruby and you can write good code in .NET. But I can write much cleaner, succinct code in Ruby because the language has fewer restrictions. I can do all of the same things in .NET, but it might require factories, dependency injection, code generators, etc. The code ends up getting the job done, but there is a lot more code and it’s more complex. The best example I can think of is a set of factories that create objects for unit tests. I’ve seen many implementations of this in .NET, but none have approached the simplicity of factory_girl in Ruby.

UNIX command line

UNIX is very command-line driven and it’s designed to be that way, so you can do a lot from the command line. You can do a lot with the Windows command line too (certainly with Powershell), but for the first time I really mastered the command line, and I really liked it. Now when I’m in Windows I pretty much use the bash shell that gets installed with Git for almost everything.

On switching from .NET to Rails

I really like Rails, but Rails is different from .NET in a lot of ways. I had no trouble coming into an existing Rails team and picking things up quickly. There are a lot of similarities between Rails and ASP.NET MVC. But if you want to take an existing .NET team and all start doing Rails, you definitely are going to want to bring someone with Rails experience to help you. You have to learn a whole new stack (because Rails runs on UNIX). The patterns and techniques are the same, but learning a new toolset will take time.

This doesn’t mean that teams shouldn’t consider switching to Rails. I’m just saying that while that might be a worthwhile idea, it’s going to take some work. But now that I’ve gone through the exercise, if I had to start a new project and was either working on my own or could choose a team to work with me, I would go with Rails because I feel it’s easier to do things.

Ever changing frameworks

Rails is open source, and there literally is a gem for everything. The problem is that all of it is constantly being updated. So if you decide to use the latest version of Rails, there is a chance that all gems won’t work in the new version. The same problem happens when you try to upgrade to a newer version of Rails – now certain gems won’t work, so you upgrade those, and now other gems don’t work. It’s not a showstopper, but it gets annoying at times. At the same time, I’d rather have this problem than having to write more things by hand myself.

Your process will determine your effectiveness, not your language

It may be true that it’s faster to develop in Rails than .NET. But what has much more impact is how you develop software. You can write good code in .NET and Rails and you can write bad code in .NET and Rails. If you have shoddy requirements, if you are relying solely on manual testing, if your business users can’t tell you what they want, if your team is not writing high quality code, or if there are other impediments that keep you from getting things done, your effectiveness will be limited. Regardless of what platform you’re on, working on improving your development process because that is ultimately what will determine your success.

If you set out to build something, you need to know what it is that you need to build. That’s just common sense, right?

Unfortunately a lot of companies struggle with this. It usually starts with requirements that don’t have the level of detail that they need in order to cover all of the edge cases. That leads to developers getting frustrated, guessing at the requirements, and low morale, among other things. In my opinion, this is not that difficult of a problem to solve. Here are some steps that might help:

Define the scenarios

As a developer, don’t start working on a feature until you can specify all of the testing scenarios in the Given/When/Then format.

Given I am a logged in user
When I go to the new order screen
And I try and purchase an iPhone
Then I should see a message saying that I’m eligible to buy a phone at the promotional price
And I should see a date when the phone is expected to ship

There are multiple reasons to do this. First, someone is going to have to test the feature at some point. You might as well define all of the test cases before you write the code. Otherwise you will have to guess what it is that you’re supposed to build since the QA team is going to define what “done” means. Figure out what “done” means ahead of time, and then you should have all the information you need to build the functionality with no bugs. Not only that, the QA team will be able to complete testing on your item in very little time (they’ve already written the test cases, and they won’t find a lot of bugs).

Second, do it for your own benefit. If you have Given/When/Then scenarios written out, you can easily turn that into unit tests. You can easily break the work down into smaller tasks. It also forces you to think about edge cases, design, and testing at the beginning. Now you have a good idea of what steps you need to take to build the functionality, it will be easier to write tests for everything, and you’ll know when you’re done (and how close you are to being done). You won’t get to the end and say, “I hope I thought of everything.” Sure, you might still miss something, but you’ll be a lot more confident that you didn’t.

It’s amazing how much longer it takes to develop something when you don’t have things broken down like this. It’s like you have to keep track of more things in your head, so you don’t think as fast. It’s much easier to take Given/When/Then scenarios and make them work one at a time.

Take time to design

A common misconception about Agile methodologies is that Agile does not place any importance on planning. Most Agile methodologies don’t approve of documentation for documentation’s sake. People therefore associate “design document” with “ZOMG WATERFALL RUN FOR YOUR LIVES!!!”. On my last project, my team lead had me write a design document for a feature I was going to work on and then we were going to discuss it together. The purpose of the document was not to check off a box or fill up a binder with stale technical details, the purpose was to help me think about the design. I was amazed, as I wrote everything out, I thought of all kinds of things that I hadn’t thought of before. It was an extremely valuable experience.

Agile says that we aren’t going to do big design up front, but that by no means implies that we should start working on a feature without having it defined! You may not have all of the details about what you’re going to build next week, but you definitely have to define what it is that you’re building right now. Agile does not encourage spotty requirements, in fact, it’s just the opposite. We want to have the requirements defined so that we can all agree on what the business needs and then write code with automated tests and no defects. Planning and design are not optional.

Hold your ground

If you have bad requirements, I think the buck needs to stop with the developers. The fact is that you can’t build something if you don’t know what it is that you need to build. If you know 90% of what you need to build, you can build 90% of it, but you can’t complete the feature. When this happens, you start getting a lot of bugs because no one (yourself included) thought of everything that needed to be considered.

So next time you have requirements that aren’t complete, don’t just start developing. Work with the BAs, QAs, business people, or whoever else needs to be involved to get everything defined. Once you start working on it and they see work getting done, people will assume that everything is OK when it’s not really OK. If you focus on getting all of the questions answered first, people might be more focused on getting everything defined because they’ll know that you’re blocked.

Sometimes you might have enough of the requirements that you can start developing. This is fine if you only have minor questions unanswered (“What should this error message say?”). You just don’t want to get in a situation where you’re getting stuck, you’re having to guess, or you’re having requirements changed on you because people are still thinking about the design.

Use your card wall

If you have swim lanes on your card wall, create columns for “In Analysis” and “Ready for Development” (or some similar wording). Don’t put anything in “Ready for Development” until the requirements are complete. Do the same thing in your work item tracker. We want people to be aware that there are still things to be done to define the requirements. If BAs see that, they will want to do what they need to do to get the feature out of that status and into “Ready for Development”. It also gives developers a visible way to say, “No, I need more definition before I can start developing.”

Use some tact

Please, please don’t go blasting your BAs, users, product owners, and everyone else who is not a developer. These people are trying their best (usually), but as a developer you have a different perspective on things. Your perspective is important, but so is theirs. Quit treating your users like “stupid users” and try to understand where they’re coming from, and help them understand where you’re coming from.

I’ve written plenty of requirements and it doesn’t feel good when a developer mocks the requirements that I just spent the last two days defining. Sure, I missed stuff. But no one appreciates getting put down when they’re working hard. Work with them to fix the problem, but use plenty of tact.

Be a coach

Writing code might be your primary job function, but you can also be unofficial coaches and help the rest of your team define good requirements in a way that will enable you to succeed. It’s in everyone’s best interest (yours included) if you try to collaborate more with people on your team. We like things in Given/When/Then format because we can easily write code against deterministic scenarios like this. It’s good for us if we have the test cases defined up front because it helps us know what to build. So if we can teach BAs how to write requirements this way and we can teach QAs to work with us to help define test cases before we write code, then everyone will win.

In my last post, I talked about the kinds of metrics that I don’t like. But sometimes even good metrics can go wrong.

When I worked for a previous employer, we used “load sheets” on our Agile card wall. These were pieces of paper divided into 10 blocks (10 days in a 2 week iteration) and then we would cut out cards for the features that were sized to take up as many blocks as the estimate (so a 3 day estimate card would take up 3 blocks). We would use different colored dot stickers to indicate when we had discussed the requirements, discussed the design, completed the development, and when QA was complete. Each developer on the team would have one of these sheets on the wall, so you could see who was working on what and where we were pretty easily.

I didn’t come up with the system, but I’m guessing that they designed it for at least two reasons (probably more than that):

• Anyone can come and see what we’re working on and what the status is of a particular feature
• We would meet with the project sponsor every other week and they would pick out features for the next two weeks, and the differently-sized cards gave a good visual representation of the cost associated with each feature

This system did an excellent job of both of those things. The problem is that the development team interpreted it in a completely different way.

When the developers looked at the sheets, these are some of the things that they thought:

• The most important thing is for me to get my features to QA in the estimated time
• Completing my tasks in the estimated time is important (more important than things like writing tests or helping other developers, because there are no metrics for those)
• Completing my tasks this iteration is more important than helping others complete their tasks (even if helping someone else would be better for the team). This indirectly discouraged pairing on tasks.

As a result, the following things actually happened (I’m not making this stuff up):

• One developer segregated himself from the team and focused on completing as many features as he possibly could. He did a good job of staying focused and he did get a lot done, but there was little collaboration or design discussion and virtually no unit tests. He used his productivity metric to ask for a raise (because he was completing twice as much work).
• Developers would work on features, and as soon as the estimated time passed and they weren’t done, they got openly flustered and complained about the estimates being wrong (which was correct), and focused on getting it done instead of getting it done right (which led to technical debt).
• Developers would get the work most of the way done and then say it was done, saying, “It’s far enough along that QA can take a look at it and let me know what’s wrong.” (That way they could move on to the next task.)

Whoa, what happened?!? I’m sure this wasn’t what the people who came up with this system intended. But that’s the problem — while the system provided a lot of positive benefits, it also indirectly encouraged individualistic behavior and cutting corners and discouraged collaboration because of implied metrics. I was leading the team, and I wasn’t going into TFS and spitting out reports to compare developers, and I wasn’t tracking who was completing tasks within the estimated time, because it didn’t matter at all. It didn’t matter what I was or wasn’t doing — the data was being tracked, so developers assumed that something was (or could) be done with it. (I’m not using this example to criticize the people who came up with the system, because no system is perfect, and there were many very successful projects completed using this approach.)

What could we have done differently? We could figure out what message we want our card wall to convey to the developers and structure it that way. For example:

• I care much more about how much the team accomplishes in an iteration than how much each individual developer gets done, so don’t organize the cards by team member (if you want to write developers’ names on cards, that’s fine, just don’t organize them in a way that it’s easy to compare developers).
• I care much more about a feature being done and ready to be deployed than I care about when a developer hands it over to QA, so instead of measuring how long it takes developers to complete their first pass at development, I’ll measure how long it takes from the time we start working on a feature to the time that it’s ready to be deployed. We need to break down the traditional silos of development and have BAs, QAs, and developers work together to achieve one goal.
• I value communication and collaboration, so when I’m talking to the team, I’ll emphasize working together, being willing to help each other out, pairing, and things like that. I don’t want developers to think that they should be smart enough to figure something out when they’re stuck, I want them to ask for help and I want people to solve each other’s problems.

Every team, company, and IT department wants to collect metrics these days. Sometimes metrics can be used for good purposes (e.g. are we on schedule), and some can be used for bad (e.g. let’s come up with some way that we can attempt to quantify how good our teams are so that we can compare them).

Let’s just get this out of the way — I really dislike metrics when they are used incorrectly. I think metrics are a good way of measuring your own progress internally. For example, I want to know if I’m on schedule to meet a target date. If the team is estimating work, I want to know how the actual time spent on the features compares to the estimates so that we can get better at estimating. I want to know how much time team members are spending on different activities (e.g. requirements gathering, development, production support) so that I can make future plans and staff the team accordingly. I might want to measure cycle time (the amount of time from when we start working on a feature to the time when the feature is deployed or ready for deployment). In all of these cases, two things are true: I’m not publicizing the metrics outside our team, and all of the metrics are measuring the performance of the team, not the performance of individuals.

I may use the metrics in order to know what message to send to a project sponsor. For example, if I can determine from our metrics that we’re ahead or behind, I would let the project sponsor know how ahead or behind we are. I might use cycle time to come up with a date when we think we can have a feature completed.

What I don’t want to do as a team lead is share any of the raw data with the people above me (unless I can trust them). Why? Because I don’t want to give them an opportunity to misinterpret the metrics and manage my team for me. If I’m leading a team, it’s my job to lead the team and it’s the team’s job to deliver. Too often, the higher-ups will use metrics in the wrong way.

This is what happens when your manager comes to you and says that you have to cram in some extra scope and cut out testing. They saw a metric (time for a developer to complete a feature) and made a decision based on it. They essentially are saying that “development time” is the most important metric, when in reality, what’s more important is the time to do all of the work (requirements, development, and testing). They are stepping in and managing the team and choosing a metric that you gave them (a development estimate).

This is why you have to choose your metrics wisely. What if you gave estimates to your project sponsor in terms of how many person-hours it takes? Let’s say that feature X will take 4 hours of BA work, 2 days of development, and 1 day of testing. In the end, that means that 3.5 days of people’s time will be needed. You probably know how much available BA and QA capacity you will have just like you know how much development capacity you will have. So why not portray it as one big bucket of capacity? Maybe you still break down the time and give that estimate by role. You run the risk of the sponsor trying to lop off the testing, at which point you have to earn your salary and explain to them why you need that much testing time (we wouldn’t say that we needed it if we didn’t need it, right?). If they don’t make QA people available to you, then use developers or BAs to do the QA. Either way, you need 3.5 hours of people’s time to do it.

Notice what I did differently — I gave a whole-team estimate. I didn’t just say how long it takes to do the development. That opened the door for your project sponsor (who probably doesn’t know how to manage your team) to staff the BA and QA team for you.

To me, the kinds of metrics I want to expose outside my team are things like features delivered, money saved/earned for the company, and things that show business value. Ultimately, this should be what matters to the business. These aren’t always easily quantifiable (which makes it difficult), but this should be what project sponsors and executives should ultimately care about. In fact, I would keep a list of achievements that you know have business value and report that up. Your project sponsor/manager would love that because they’ll turn around and report those same things to their boss. Now you’re speaking in the language that they should be caring about (cost savings, business value), and you’re free to manage the team the way that you know how.

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.