I’m a big fan of board games, and I have invested many hours of my life playing board games. I’m not talking these “group fun games” like Cranium or Guesstures, I’m talking about games that have more strategy like Settlers of Catan, Ticket to Ride, and Dominion.
Each of these games has it’s own strategy, but I’ve found that in all of these games, the most important strategy is to have a plan for winning. Not only do I have to have a plan for winning, I need to do it fast. I’ve won many games where I came from behind because the person who was ahead got comfortable with the lead and didn’t keep pushing forward.
The same idea applies to software development. I don’t like when command-and-control managers try to push unrealistic timelines on development teams. But at the same time, every business could use everything that you’re doing for them yesterday, so we need to find a way to go faster.
This means that I need to make the best use of my time, all the time. This especially applies when things are a little slower. We’ve had times where we’ve had weeks where there was nothing pressing to be done and we decided to tackle technical debt in the code. This is one of the most important times on a project because this is your chance to come up with a way to do things better and faster.
This is when you need to have a plan for winning. You need to determine what things you can do that will help you write better software faster. You definitely don’t want to squander the opportunity, because who knows when another one like it might come along.
We are in a race against time. Any time wasted means lost revenue, lost productivity, missed market opportunities, and higher development cost. All of these things are critical to the business. Imagine that we were writing an app for your company with your money. Would you do things differently?
Everything that you do on a project should be done with a sense of urgency. Not a fear-based pressure that leads you to make bad decisions, get flustered, and cut corners, but a conscious effort to maximize the return on the investment of your time (and yes, your time is expensive). This shouldn’t have to come from your manager or some outside source, this needs to come from inside you.
In our fast paced culture, we are constantly looking ahead to the next big thing. We think about some magical someday when things will be better than they are now. Then when we get there we’re still looking ahead to something else.
I’m all for setting goals for the future and reflecting on the past. The danger in all of this is that we might just miss out on the present.
Recently I’ve been trying to live in the moment and be present in the present. I want to enjoy the people and opportunities that I have in front of me right now. I want to actually stop what I’m doing in my busy day and turn around and listen to someone who wants to talk to me. I want to spend less time looking for the next big thing and spend more time taking advantage of what’s in front of me.
You can’t take anything for granted in life because things change too fast. Never again will things be the same as they are right now. A year from now you might be working with different people, friends might move away, and your kids will be a year older. Sometimes it seems like things will always be the same, but nothing lasts forever.
So I find time to enjoy today. I’ve started to go to lunch with people more often because I want to enjoy them as much as I can. I had a great time in college, and I would give a lot to be able to have one day with those people all in the same place again doing the same things, but those days are gone. I hope that I’m saying that same thing about 2012 in a few years, and I don’t want to regret not taking advantage of it while I still had the opportunity.
While it’s wise to study the past and plan for the future, don’t forget to enjoy what you have now. Because you’ll never have another today.
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.
« Newer Posts — Older Posts »
