I saw this in a job posting the other day, describing the work environment at the company:

We pair a lot, but not all the time. We test a lot, but not all the time. The key is being able to explain your practices with rational argument.

I love this. There are practices like testing that I hold in high regard, but nothing should be done all the time. As the posting says, “the key is being able to explain your practices with rational argument.”

Can you explain why you do something like TDD? That’s probably easy for you. But can you explain when you shouldn’t use that practice? That’s a little harder to do, and maybe because you’re holding onto some ideal that says you should test all the time or have 100% test coverage.

For every idea or practice that you find valuable, you should also be able to explain when it doesn’t apply. If you can’t explain when not to do it, I would say that you don’t really understand when and why you should use it.

What do you do when you get stuck on something at work? Do you ask for help? Or are you too afraid to bother someone else with your problem?

This is one of my pet peeves. When you’re writing software, gathering requirements, testing, or whatever you are doing, at some point you are going to get stuck on something. You spend a little time trying to figure it out, but you can’t solve the problem.

At this point, many people are afraid to ask for help. I don’t think that it’s because they’re too proud or lazy to do so, they just don’t want to inconvenience me because I “look like I’m busy” or they “don’t want to bother me”.

I may actually be busy and I maybe I even don’t want to be bothered, but if I can spend one minute answering someone’s question and save them 20 minutes of figuring it out (and the headaches that come with it), I’m going to do take the time to do it. Even though it’s an interruption, that time spent helping someone else is a good investment that will pay off because hopefully that person will no longer be stuck. If I really am so busy that I can’t help, I’ll just tell people that and they usually understand, and then I’ll try and follow up with them later.

I feel that in general we are so afraid of inconveniencing other people, even our good friends. I have good friends who have young kids like I do and they will go multiple years without going on a date without the kids. I’ve offered several times to watch their kids for them (which is not that hard to do since their kids will occupy my kids), yet to this day no one has ever taken me up on it. We’re talking about people that we are good friends with. Yet they are so afraid of inconveniencing us (even though we were the ones to offer to babysit) that they won’t do it.

I don’t really know where this comes from, but it’s frustrating. Several people working together are going to be more efficient that individuals working on their own, and that’s because we can work together to achieve something that we couldn’t achieve on our own. But that won’t happen if we aren’t willing to bother someone else with our problems.

I frequently try and tell people on my team that it’s totally OK for them to bother me. I think my business analyst interrupted me at least 10 times the other day to ask me questions. This made me excited because she wasn’t afraid to inconvenience me with her questions, and as a result she probably got a lot more done today than if she had just tried to struggle through it herself.

Software development is a very collaborative activity, and we will be way more efficient if we ask others for help. So ignore that little voice in your head and go ask someone for help, and don’t feel bad about it.

This is the best response I’ve ever seen to this question, and I’m glad to see such pragmatism from an industry leader like Kent Beck.

These days, there is a certification for everything. Almost every discipline in software development has several different certifications that you can get if you attend a training class and then take a test that verifies that you understand the book definition of a process or language. This totally misses the point.

In some industries, certification matters. I’m glad that my doctor has to go through 12 years of school and thousands of dollars in student loans in order to get his M.D. If someone can make it through that, I have confidence that they know what they’re doing.

The bar for software certifications is much lower. All you have to do is pay a few thousand dollars for a training class and then take a test that shows that you paid attention in class and understand the basic concepts.

What do we think we get out of these certifications? A basic understanding of the principles, maybe. The problem is that those things are the easy part of software development.

Here are some of the things that I actually look for when hiring people:

• Ability to listen to users
• Understanding your team members
• Motivation and purpose
• Attitude
• Passion
• Ability to think outside the box (as opposed to being certified that you know that you how to think inside the box)
• Learning ability
• Problem solving skills

I feel that one of my greatest strengths is the ability to make it up as I go. Sure, I might have my Agile bag of tricks, but every project and environment is so different. When we inevitably encounter a problem, the hard part is finding the right solution for it, and no formula or certification is going to tell you the right solution to every problem.

Certifications aren’t all bad, if you spend a week learning learn how to be a “certified Scrum developer”, you’ll learn TDD and good OO practices and other things that will help you succeed. We can argue about whether it’s worth the money, but you are going to learn some good stuff.

The point of all this is that (in my opinion) some of them most important qualities in a team member are less quantifiable things like attitude, passion, and the ability to think outside the box. These are the things that I want to strive for, and the only “certification” that you can get for this is experience.

If you’re a developer, do you have your own personal development database that you can recreate at the touch of a button?

If you said no, you’re not alone. In fact, I’ve been in that situation on many projects, where the entire team shares one big development database that is a backup of production, and all schema changes need to be coordinated with the other developers on the team. Usually things are this way because back in the day someone didn’t create a way to have local databases.

We were in the situation and we made the investment to have someone spend a week or two taking a copy of production, deleting all of the data from tables that weren’t lookup tables, and then creating a way to run all of the new SQL scripts against the small baseline copy. Now I can recreate my development database at the touch of a button.

The benefits of this are obvious, but since many people haven’t made this investment yet, let me list them anyway:

• I can hack up my database and not worry about affecting other developers
• I can hack up my database and then start over if I screw something up (as opposed to piece things back together so that the rest of the team can keep working)
• Automated tests that run against the database run MUCH faster
• No more confusion when someone else on the team changes some important piece of data without telling you
• I can check out any revision of the code and create the database that existed at that point in time

If you don’t have a local, recreateable database yet, make the investment. You will reap the benefits many times over and you’ll be so glad you did.

One of my favorite tricks around changing how a team does something is to get other people to drive the change for you.

This especially applies if you’re coming into an organization as an outsider. Most people are initially somewhat skeptical of outsiders and you need to earn their trust. This sometimes takes a long time, and you might want to change some things before you’ve built up the political capital to drive it yourself.

When I started on my current project, all of the QA testing was done manually, and QA people weren’t involved in the process at all until after the code had been written. As a result, they would get features to test and not have any idea of what they had to test, and many times they couldn’t trust that the requirements were even up to date.

The solution that I was hoping for was to get QA people to meet with developers and BAs before the code was written so that they could come up with a test strategy and acceptance criteria. That way they would have input up front, and developers could automate all or most of the acceptance tests, which would save QA a lot of time. But I didn’t want to bring it up myself.

So I would ask questions in meetings. We all agreed there was a problem, so I would ask everyone what ideas they had to fix it. Eventually someone would give the answer I was looking for. “That’s a great idea!”, I’d say, “How do you think we should do that?” Now it wasn’t my solution, it was someone else’s. That person feels good because they came up with a good idea (that eventually ended up working), and since that person is actually on the team and doing the work, they might have more credibility than an outsider like me.

I would much rather have someone else get the credit for coming up with the ideas, because I think that it gives the idea a better chance of success, and when it works, it encourages people to try and think of more ways to improve things. If one person comes in and tries to drive and enforce all of the change, it’s very easy for people to discredit that person (maybe even just in their mind) and try and fight the change. But when the ideas are coming from multiple different people on the team, now you have more and more people buying in because they’re the ones coming up with the ideas!

When I think of a “coach”, I think of someone who helps other people find the path to success. You can try to push them in that direction and they might turn around and fight you instead. Or you can help them use their own ideas and expertise that they already have to find their own way.

If you’re a developer, you probably aren’t extensively involved with requirements gathering, but they affect you dramatically because you have to read requirements and turn them into code. So how would you like to have requirements written so that you have all the details that you need to implement the feature and easily write acceptance tests (hopefully automated)?

I have ideas but only some answers, which is why we’re talking about this on Thursday at the Columbus ATDD Developers Group. We’ll be talking about questions like these, among other things:

• How can we structure our requirements to help us come up with our acceptance criteria?
• What requirements should we have other than our acceptance criteria?
• What can we do to help BAs make sure that they have all of the details that we need to write tests and write the code?

It’s a fishbowl discussion so we all get to figure it out together. I think it will be fun. I feel like there are some dots that I’m having trouble connecting when it comes to requirements gathering so hopefully we’ll turn on some light bulbs.

The meeting will be Thursday, August 2 from 11:30-12:30 at the Quick Solutions office, 440 Polaris Pkwy., Suite 500 in Westerville. Please RSVP so that we know how many people are coming.

If you want to change something in your organization, that must mean that there is some problem that needs to be fixed and a solution to fix the problem. That’s obvious, right?

Maybe it’s obvious to you. But is it obvious to others?

If other people on the team don’t see that there’s a problem or if they’re OK with the status quo, it’s going to be very difficult to get them to change. For example, let’s say that your team does not do automated testing and you want to get developers to start writing unit tests. The problem is that you have lots of bugs and it’s scary when you have to refactor the code.

But wait a minute, do other people think it’s a problem? More than that, do they think that your solution will be better than the status quo? That’s a completely different question! Maybe the developers on the team have all been getting good reviews from their manager. They might not like the bugs and the scary refactoring, but they might not think that introducing TDD will fix the problem, or they might think that it’ll be more work to learn TDD than just deal with the code without tests.

You need them to both see the problem and buy into the solution (man, this is getting hard). So maybe you go and write unit tests around some part of the system. Then later when another developer needs to change the code, you show them how easy it is to run the tests and see that the code is still working. Now maybe they’re more open to your solution because they can see the benefits of it and see that maybe it won’t be as hard to implement as they previously thought.

Until you can get people to see that there is a problem and that your solution is viable, you’re probably not going to have a lot of success getting them to change.

If you want someone to change, you have to not only give them time to change, but you need to show them that you will be there to support them when they need help. They might be worried that they’ll starting learning the new way and then you’ll leave them out to dry without any help to get them the rest of the way.

The other day I was making a change to a part of an application that I don’t deal with much using a framework that I’m not an expert in. It wasn’t very hard to figure out, but I didn’t really enjoy it. I hate feeling like something is taking me way longer than it’s supposed to just because I’m not the expert in the application or technology. I’m sure you all can relate to this.

Now think about having to do something completely foreign to you, like a new language, platform, or technique that you’re really not good at. Or maybe you’re trying to change the way that your business analysts write requirements or your QA people test software. We can criticize people for being fearful of change, but we’ve all been there are some time.

If you’re the one who knows what they’re doing when it comes to the new whatever you’re doing, look really hard for opportunities to help people. Most people are reluctant to ask for help (maybe they have egos, they think you’re too busy, or they just don’t want to get up out of their chair). Instead, ask people how they’re doing today. When they mention that they’re struggling with something, go help them with it, and then offer to help them again if they need it.

Some people are definitely more adverse to change. If you’re the one proposing the change, chances are you are not as adverse to change as others. You have to try and put yourself in their shoes. They have good, logical reasons in their mind to not do what you want them to do. If you can empathize with them (or at least attempt to), you’ll be more in tune with their fears and what you can do to help them through it.

There are many people on software development teams that are trying to change the way that their team works, whether it’s a new process, a new technique, or new way of development software. Yet so many of them never see lasting change come about.

You can try to drive change or encourage people to change, but the people on your team have to feel like they have some room in order to try and make the change. If they feel that there is a risk of failure because changing the way they work will lead to poor results, then they won’t take the chance.

Stop the fire fighting

I’ve seen many teams that feel like they’re in endless fire drill mode. When you’re in these situations, you have very short term thinking because you feel like you’re always solving short term problems. Sometimes there are fires, but ultimately what we want is more long term thinking. But in order to get that long term thinking, you have to give people some stability and peace in their day to consciously think about doing things the right way instead of doing whatever it takes in order to fix the problem at hand.

This is easier said than done. It takes someone awhile to switch from short term fire fighting mode to a long term mindset. For me, someone may say that the fire fighting is over, but until I can go a week or so with some stability, I’m not really going to believe that I’m going to have space in order to think differently.

This requires you to rethink how you plan your capacity. It probably means that you need to either do less work and get more people to help get the work done. Either way, you need to stop lying to yourself and saying that you can do as much as you’re doing with the team that you have.

This is where making the workload visible is important. Put everything, and I mean everything, up on a board. People should see what you’re working on now, what’s next, and what’s in the backlog. Put technical debt and refactoring tickets on the board too. When someone asks why those are there, explain how doing those tasks will allow you to provide more value and be more productive. If someone asks why you’re not getting as much done as they would like, you can show them exactly why.

It may take discipline, but if you slow down just a little bit to think about what you’re doing and how you can best do it, you can turn things around.