My new Agile Architect article, “Agile Humor: 5 Radio Ads and Announcements We’ll Never Hear” is online at ADT Magazine at http://adtmag.com/articles/2012/07/24/agile-humor.aspx
You can read all of my Agile Architect columns at http://adtmag.com/Articles/List/Agile-Architect.aspx
Through my various experiences as a Developer, Technical Lead, Test Driven Development Mentor and Agile Coach, I have paired with more than 100 different Developers over the course of 10 years. As you can imagine, I’ve seen just about everything, the worst of the worst and the best of the best. Most of the people I have paired with were proficient programmers and nice people. However, pair programming can be tough, even for the best developers, and can be downright daunting if you haven’t done it before, are introverted or unsure of yourself. For those of you that want to improve your pair programming fu, I offer you my 7 Habits of Highly Effective Pair Programmers.
Proficiency with the language and proficiency with the IDE are paramount to working as an effective pair partner. When you program with a pair partner you have nowhere to hide. All of your skills and abilities, along with your fears and shortcomings, will be on display for everyone on the team to see. This often scares people away from pair programming. To overcome these fears you must first accept that there will always be someone out there that knows more than you do. Second, you should work to improve yourself in the areas where you feel weak or unsure. Block out 30 to 60 minutes per day for self improvement for a few weeks. You’ll be surprised by the results.
Finally, you must master your IDE. There’s nothing more frustrating than watching your pair partner wade through a series of dropdown menus to perform “Extract Method” when Ctrl+Alt+M is quick and easy to remember. Almost all modern IDEs have a wide range of shortcut keys for the most commonly used actions and commands. Find a reference card for your IDE on the internet and highlight the ones you think will be most useful to you. Then memorize the shortcuts and start using them everyday. Your pair partner will appreciate your mastery of the IDE and you will improve your efficiency.
In any relationship, communication is key. When you are pairing you are essentially in a very intense, but short, relationship. You are two people working collaboratively towards a shared goal. You must communicate well. Before you dive into a task spend a few minutes discussing the task and identifying an approach to implement a solution. You can write some given/when/then statements or actually use Cucumber or another Behavior Driven Development tool to document and clearly define your success criteria. Doing so will ensure that you and your pair partner agree on what to do and how to do it.
When it’s your turn at the keyboard keep your pair partner informed. You need to verbalize your thought process to let your pair partner know where you are heading and why. I try to use a verbal stream of consciousness to let my pair partner know what I am thinking and what I am doing to keep me from wondering off course and let my pair partner know where that course is leading. I also try to ask my pair partner questions to help keep my pair partner engaged and to solicit feedback and advice. For instance, after passing a test, I will often say, “What do you think?” and offer the keyboard. This is chance for my pair partner to improve, refactor or write another failing test.
When you are confident in yourself and your abilities you feel comfortable offering and receiving constructive criticism. Having this self confidence allows you to focus on making the criticism that you give constructive rather than using the opportunity to belittle your pair partner in order to inflate your own ego. Self awareness of your strengths and weaknesses, coupled with a confidence that you “can do this” allows you to relax and focus on your work rather than on your shortcomings. Additionally, you will be able to open yourself up to constructive criticism and you will have the perspective necessary to determine if the criticism is relevant and actionable.
With self confidence you will find that you are more willingly to ask questions and try out new ideas. Your self confidence can inspire better communication on the team by setting the example that you are willing to admit that you don’t know everything and are willing to ask for and accept help. When you’re self confident you don’t worry about what others are thinking about you or your productivity so you are more willing to take chances and try innovative solutions. Doesn’t this sound like someone that you would like on your team?
When we were children we learned the basics of self control. We learned to take turns, to finish our homework before playing outside and to go to bed at our bedtime. But sometimes our self control lapses when we are bored, tired or frustrated. Let’s face it, our world is full of distractions: email, smart phone, internet, mobile gaming, social networks, hallway conversations, the list goes on and on. The discipline of software development requires a significant amount of mental effort and focus. So anything that distracts your attention can be a potential productivity killer.
The high functioning teams that I have witnessed leverage their “team norms” or “ground rules” to help them reduce the number of potential distractions. For instance, one team made a rule that they would only use their cell phones outside their team area (see the example “ground rules” later for more ideas). You can also leverage good agile principles to stay focused. Use spikes to investigate new ideas and techniques. Add a “time allowance” to your spike story to keep you from going down an endless “rabbit hole”. When you’re working on an agile team you’re responsible for you and for everyone else on the team. That’s what we mean by the “whole team approach”. If you’re having trouble focusing you should be able to rely on your pair partner and your team to help get you back on task. Just the same, if you notice that someone else is having a hard time staying focused you need to be willing to step up and help them get back on track. Remember, you will succeed or fail as a team.
I think by now we have clearly established that writing code with a pair partner is much different than hacking by yourself all day. Your patience, or lack thereof, doesn’t usually affect others when you’re working alone. If you’ve spent your whole career as a solo “keyboard jockey”, pair programming will put your patience to the test. As a pair partner you won’t always have control of the keyboard and mouse and it is considered bad form to rip the mouse out of your partners hands. Some people have a hard time with this and have to use extreme measures, such as sitting on their hands, to keep themselves from grabbing for the keyboard or mouse. So when you get the urge to grab, take a deep breath exercise your self control and then use your best manners to ask, “May I?”
Once you get control of the keyboard and mouse, you should be willing to relinquish control without a fight. Liberal keyboard passing helps keep both pair partners engaged and motivated. Some of the best athletes in team sports are the ones willing to sacrifice a small personal victory and make a pass to a teammate in order to achieve a larger team “goal”.
Manners in the workplace seem to have gone the way of chivalry, yet manners are a crucial part of human interaction. Programmers often forget this because they don’t have to thank their shell script for grep’ing through a log file or ask politely for their laptop to launch their favorite IDE. However, when pairing, good manners are expected and poor manners are not easily forgiven.
I find it useful to start off a new pairing session by setting a few simple ground rules. If you prefer to formalize these ground rules you can work with your team to create a set of team ground rules for pairing. Some groups like the formality of a team set of rules while others prefer to play it loose and make the rules up as they go. Whichever way you go, just remember that it is necessary to have a shared understanding of how you will work together as a pair before starting to avoid confusion and hurt feelings. You might be surprised to learn the things that distract or bother your co-workers.
Here’s a few example ground rules:
That addresses the technical aspects of the pairing session. Don’t forget to use general good manners otherwise. The following is a list of ways to improve your manners:
If you work to improve your manners I think you will find that you will have more enjoyable pairing sessions and will become one of the most sought after people to pair with on the team.
This should really go without saying. It really should. Unfortunately, I have to say it, because too many people ignore the use of basic hygiene in the office, and it’s better that you hear it from me now, than suffer the embarrassment it could cause later. So consider this a quick “Health Class for Programmers”.
Here is a simple list of things you can do to improve your hygiene. You should shower every morning, brush your teeth and use deodorant. Throughout the day you need to be mindful of your breath. Some people are very sensitive to coffee breath and onion breath. If you like to drink coffee and/or eat onions or garlic (or other strong smelling foods) consider following those up with a mint or breath freshening gum. If you smoke, you should always wash your hands and freshen your breath before returning to your workspace. If you cough or sneeze, be sure to cover your cough/sneeze using the inside of your elbow as a shield and sound muffler. Always keep hand sanitizer nearby to keep your hands clean and sanitary throughout the day.
If you work in a bullpen or agile room, it’s important to remember to clean up after yourself. Throw away your empty soda cans, disposable water bottles, snack bags, gum wrappers, etc. Its not fair to the pair that will come behind you to have to clean up after you before they can get started working. Try to keep some disposable cleaning wipes on hand. These work great to sanitize the workspace to help keep everyone healthy and to keep the cruft from building up on the mice, keyboards and desktops.
Let me close by telling you that I have probably violated every principle of every habit in this article and this is part of what has made it possible for me to compile these habits. But thanks to my years of experience and with help from my teammates and coaches I have gained a level of self awareness that allows me to make the necessary adjustments to become a more effective pair programmer. By no means have I completed this journey, but I am a better pair programmer today than I was yesterday. It is for this reason that I define success, not as the attainment of a static goal, but rather as the continual attainment of small goals on a path toward perfection, with the full awareness that my journey as a pair programmer will end well before achieving perfection.
Let’s face it you can never have enough money and your tests never run fast enough. I can’t help you with your money, but if you follow the steps in this post I can help you speed up your Cucumber tests.
The improvement process that I’ll walk you through is known commonly as DMAIC (Define, Measure, Analyze, Improve, Control). For those not familiar with DMAIC, Google can tell you everything you need to know. But, basically DMAIC is an improvement cycle commonly used in Six Sigma to improve and optimise business processes. We’ll use DMAIC in this post to improve the speed of your Cucumber tests.
You’ve probably already defined the problem, your tests are too slow. What you haven’t done is define success. You will define success in terms of execution time. For instance, if your Cukes are taking 30 mins you might define success as, “Make all Cukes run in 20 mins or less”, others might define success as, “Cukes running in 5 mins or less”. This is up to you and your team to decide. Just remember, the amount of time it takes to run your tests will be inversely proportional to number of times you will run them. So the faster they are the more often you will run them.
You know how long it takes to run the suite. You might even know how long it takes to run each scenario or sets of scenarios. What you need to know now is how long it takes each step to run. Wait! Before you go diving back into your steps to instrument them with timers and such, let’s see what Cucumber can do to help us.
Fortunately for us Cucumber offers a number of helpful options for formatting the output of our test runs. One of those options is --format usage. Using the ‘usage’ format will show us which steps take the longest to run, how many times each step executed and if any steps are unused. I’ve slightly modified some of the example feature files provided with the Cucumber source to generate the following output.
Cucumber Output using --format usage
With our new data in hand we can begin to zero in on the trouble spots. The usage report displays the steps ordered from slowest to fastest. The report also shows the number of times each step executed. Your slowest step might not be the biggest problem. You should focus on the steps that run the slowest and the most often. Also, consider why the step executed so often. If you wrote the scenarios following a behavior driven development (BDD) cycle then the scenario was written to define behavior in the system. As a result you may find many scenarios exercising the same part of the system in only slightly different ways. Viewing the scenarios in hindsight you should consider if you can consolidate or eliminate some of the scenarios.
Now that we know where to focus our efforts it’s time to make our improvements.
In the ‘Analyze’ phase you considered if you could remove or consolidate scenarios. Now is the time to do that work. Deleting scenarios is fun and easy. Consolidating scenarios takes more effort and thought. Look for recurring patterns such as screen navigation and data setup. If you notice that you repeatedly setup the same data to run different scenarios, it’s a good bet that those scenarios are ripe for consolidation. From the regression testing perspective, you want to maximize the amount of testing performed while minimizing the amount of work you have to do in the system to prepare for the testing while maintaining the ability to independently execute the scenario.
One of the most common causes of slow downs in cukes is ‘sleep’ing. People often use sleep to wait for AJAX activity to complete. This is the most unpredictable and wasteful way to control test execution. Imagine that an AJAX action normally takes between .5 and 2 seconds to complete. If we sleep to wait for the action to complete how long should we sleep? Let’s say we decide to sleep for 3 seconds. If that action ever takes more than 3 seconds the test fails. Also, every time the action takes less than 3 seconds the difference is wasted doing nothing and if this is one of your most executed steps those seconds quickly turn into minutes.
Instead of sleeping you must learn to ‘wait’. The Selenium client includes a number of ‘wait_for’ methods that will improve the predictability of your steps and will remove the waste caused by sleeping.
wait_for_text(value) — Simply waits for the text you specify to appear in the DOM. Should this value already exist, execution will continue without waiting, so carefully select a value that you know won’t exist until the AJAX action completes.wait_for_element(xpathLocator) — Allows you to specify an exact xpath locator to wait for before continuing.wait_for_no_element(xpathLocator) and wait_for_no_text(value)– Allows you to wait for the removal of an xpath locator or text value from the DOM before continuing.Once you’ve ‘picked’ all the ‘low hanging fruit’, you’re left with your software engineering skills and training to profile, tune and tweak the last bits of improvement from your steps.
Cucumber provides a simple yet powerful ability to add tags to scenarios using the @tagname. If you’ve made all the improvements that you can reasonably make but your tests still aren’t fast enough, then you can use tags to define a subset of scenarios to execute. For instance, you could tag the scenarios with @smokeTest tag and run them by specifying ‘ –tag @smokeTest’ at the end of your cucumber command. Don’t forget to run your full suite of Cukes nightly, or better yet schedule them to run more frequently via your continuous integration server. Checkout the Tags page on the Cucumber wiki for more details on tags, https://github.com/cucumber/cucumber/wiki/Tags
Congratulations. Give yourself a pat on the back. Hopefully you’ve met and surpassed your success criteria. Wait a second though, we’re not done. You need to keep an eye on things. Don’t let your test times creep up. That’s what the ‘Control’ phase is all about and it goes on for as long as you care about the amount of time required to run the scenarios. Make the ‘care and feeding’ of your cukes a regular part of your development cycle and they will provide your application with benefits for years to come.
At Asynchrony, we like to give back. We like to support causes and support each other. Danny Shoemaker, a member of our Business Development team, is on a mission to climb Mount Kilimanjaro this summer in honor of his loved ones who have dealt with cancer and to support the mission of LIVESTRONG. There are very few of us who haven’t been touched by cancer in one way or another. For more information about how you can support Danny and to learn more about the participants and their goals, follow the links below.
LIVESTRONG.org blog: http://bit.ly/zwK2AQ
Danny’s Survivor Summit page: http://bit.ly/wiev8B
My new Agile Architect article, “Agile Deadline Ahead: Will Your Team Make It?” is online at ADT Magazine at http://adtmag.com/articles/2012/02/16/agile-deadline-ahead.aspx
You can read all of my Agile Architect columns at http://adtmag.com/Articles/List/Agile-Architect.aspx
Well, maybe not my life, but my project’s life. A bit reading and patience will allow me to explain. But first, a definition of the word: Kanban.
kanban |ˈkänˌbän| – noun
a Japanese manufacturing system in which the supply of components is regulated through the use of a card displaying a sequence of specifications and instructions, sent along the production line.
“Now wait. We are not in Japan, and we are definitely not a production line.” Understood, however we can take this system and apply it to our practice.
Kanban in practical terms is best described with a picture.
We have multiple queues drawn by string, or marker on a whiteboard, or imaginary (it depends on the project). Each queue represents a phase of our development process. A new project, for example, may have the following queues: Waiting, Code In Process, Code Complete, Acceptance Testing In process, Acceptance Testing Complete, Ready for Customer Review, Ready for Production.
As requirements, from our client or customer, are recorded, they are written onto story cards and placed into the Waiting queue. When someone begins working, that person picks up the first card and moves it over to the next queue to begin Coding. When the story has been completely coded, it goes to Code Complete so that the person who provides acceptance testing can pick it up and begin working on that story. This process continues to happen until it reaches the end.
Stories get worked on from the right side first, so that it can reach completion as fast as possible. This provides the most efficient and focused flow of progress.
Kanban provides a ton of invaluable assets, as a system, to your project. Such as: efficiency, focus, communication, limit work in process, prioritization, visibility on status.
We also limit work in process (WIP), because work in process is considered waste. It is considered waste because it, at the state of being work in process, is unusable code. If at any point in time the customer says “Let’s change priorities completely” or if for some reason the project finished prematurely, the incomplete code is wasted.
We apply WIP limits by restricting the number of stories that can be in a particular queue. If you can’t move a queue forward because the WIP limit is already full, you are forced to either clear the queue ahead or find someone who can. This is very important because it prevents the project from consuming a block in flow of progress.
Our primary Kanban consists of the following queues. Feel free to use the exact same queues for your project but beware that every project is different and requires a different kanban. Pay attention to the pain of your project, start simple and adjust based on that pain.
a Japanese manufacturing system in which the supply of components is regulated through the use of a card displaying a sequence of specifications and instructions, sent along the production line.
Your project’s development cycle is a production line. In order to get the most quality and the most work completed think about work in process, notice where stories have the longest cycle time (time a story spends in a given queue), which queue fills up too fast (perhaps you need more resources to satisfy that queue, or you need a greater WIP limit).
If you are developing cars, you want as many completed, high quality cars as you can build. You don’t want 500 windows, 200 doors, 6 handles, 3 mirrors and 1 car. Same goes for developing an application. You don’t want 10 features in process and 1 feature completed; you aren’t guaranteed time to finish the work in process.
I hope this post was useful to you. I would love to get some feedback.
This post is the first in a series I plan on publishing about how Kanban changed my life. Check in to see the additional posts. I will also update this post with links.
Be careful what the client wishes for.
Myles Bogner, Ph.D, VP Research and Development
with Special Asynchrony Guest Jason Carter, President of Aegis Strategies
As organizations embark on improving their Enterprise Architecture, Portfolio Management, and Enterprise Governance efforts, a frequent question tends to be, where are we now? Below we offer a set of questions to guide the creation of an “as-is” assessment around these three areas. We’ve categorized these questions into seven broad categories.
Governance
Information
Business
Performance
Enterprise Initiatives and Enabling IT Systems
Service
Once an enterprise establishes its baseline, these same set of questions can be prioritized and utilized by the organization as a spring-board to implementing a robust enterprise architecture and portfolio management practice.
If you’re wondering what a software architect does in an agile development environment, you’re not alone. Asynchrony’s Vice President of Architecture, Mark J. Balbes, Ph.D., shares what he does and how it all comes together in better code in an article published in Application Development Trends. To read the article, click here.
Curious about how UX design works in an agile world? Check out our latest article at UX Magazine to find out: Change on a Dime: Agile Design