Agile

Stimulating Creativity for an Agile Team

I’ve always noticed that my creativity level drops when my routine becomes predictable. Suddenly my mind moves into cruise control. I find it difficult to come up with creative ideas and innovative approaches. I write fewer blog postings, my software solutions are more brute force, and I’m less likely to come up with fun new games to entertain my kids.

There is some science behind this as discussed in the Fast Company article, 7 Ways to Stimulate Your Capacity for Creativity. Essentially the article discusses how context violations spur creativity.

The idea is that our minds need exposure to a variety of contexts to keep us innovative:

Your most creative insights are almost always the result of taking an idea that works in one domain and applying it to another. Every “new” idea you have, personally, is based on some combination of previous concepts in your own mind, even if you combined these concepts subconsciously.

Studies in neurology have also shown that forcing our mind to think through new scenarios and differing contexts creates new neural pathways.

While the article focuses on stimulating creativity for an individual, a similar list of ideas can be applied to Agile teams. Try these ideas to boost creativity within your team:

  • Change the team environment. Have meetings in unusual locations and try switching seating arrangements regularly. How’s the weather? Have a meeting outside if the corporate campus is suitable.
  • Brainstorm different ways to use a common tool (grep, ls, ftp, whatever your team uses regularly). This may not only stimulate creativity, but can lead to new useful ways that the team uses tools you’re already familiar with.
  • Spend 30 minutes a day for two or three weeks learning a new programming language. Make it a story to be addressed during a sprint and set aside time. You may even decide the language is useful for product development.
  • Have the team talk with one new product user every week. This forces developers to socialize and it has the advantage of creating opportunities for learning. Each product user likely has a different take on the system and what they find useful.
  • Play Agile games. Ever been to TastyCupcakes.org? Other than the creepy clown picture on the front page (think It, Stephen King), this is a great site for finding games that allow a team to learn more about Agile while spurring innovation.
  • Take on a story for innovation time. It works for Google, could it work for your team? Try bringing in a story during your next sprint focusing time on innovation (this should be only a few story points). Make sure you set acceptance criteria so the team can demonstrate their effort.
  • Try a daily 10 minute break for exercise. One of my clients is a wellness company and they take 10 minutes a day to leave the cubicle farm to get some brief exercise. Walk the stairs, jog in place, do some situps, change it up daily. Not only will it change the daily routine, it promotes good health!

Do you have ideas of your own? Leave them in the comments.

By |Agile|Comments Off on Stimulating Creativity for an Agile Team

You can’t afford to ignore DevOps

DevOps is a huge movement in IT at the moment. It applies lean practices across an IT organization. While Agile has promoted lean practices in the development of software for years, DevOps is a more recent movement. The movement recognized the interdependence of the delivery of software with the infrastructure that the software relies on.

Enabling Agility with DevOps

Lean practices recognize that software is only providing business value once it is released. Any time that feature is awaiting a deployment is wasted money. If we can release features as soon as they are complete, we can achieve the maximum business value from each feature that we implement.

In an Agile environment our measure of success is the release of working software and DevOps is a cornerstone to that achievement. An Agile team can achieve amazing velocity while developing the software itself, but without infrastructure and deployment, releasing is impossible. By automating QA tasks, deployment tasks, and configuration of infrastructure, we increase the speed the delivery of software.

While there are a number of organizations that have shown amazing success with DevOps (Flickr, Etsy, Amazon, Facebook, DropBox just to name a few), this approach doesn’t only apply to startups. Large organizations must begin to take on these tactics in order to stay competitive. I’ve seen vast improvements in productivity for organizations that take even the smallest steps toward a DevOps approach.

Getting started with DevOps

A great book that provides a good primer to DevOps through lean practices is Lean Startup. I also highly recommend the DevOps Zone at DZone. There are great articles there to keep up to date with the world of DevOps.

If you are just ready to get started and are looking for tools to fully automate your infrastructure, take a look at Puppet and Chef. These are the industry leading tools for infrastructure automation and both provide a great alternative.

If you haven’t started looking at DevOps in your organization, I highly recommend you do. Not only will it keep you competitive, but it may be the key factor to differentiating your organization from the rest of the market.

Getting out of Technical Debt

Do you have a technical debt problem? Just like having too much personal debt can lead to financial ruin, technical debt can ruin a project. In my last post, I discussed the criteria I would like to see out of a solution to tracking technical debt. Now we’ll have a look at some common solutions to the problem with their drawbacks as well as the recommended solution.

Tracking technical debt in TODOs

This type of tracking involves placing a TODO in a comment above the offending code:

// TODO this is a major hack only for the short-term, need to fix this
public void hackyMethod() {
  // ... ...
}

This is a somewhat effective solution, as it consolidates the tracking in the code base, keeps the tracking close to the code, and points out broken windows. But, it creates issues with visibility. When planning time comes for a new iteration, the developers begin the discussion as new features come up. “Feature XYZ huh? I remember looking at the code there, and there’s no way with the complexity there we are going to handle that. We’ll have to refactor quite a bit first, then we can start on that feature.”

Unfortunately from the perspective of the business owner, it’s like going in for routine maintenance and finding out the last person who fixed your car just duct taped the leak in your air conditioner. You’re not going to be happy. If you know up front that there is still an issue that needs to be addressed, you feel much less inclined to throw a tantrum.

In addition, TODOs don’t provide any metrics about the problem. How do I know the complexity of the issue? Is it really that important to address?

Tracking technical debt on a board

This involves dedicating a board with stickies or cards attached that represent technical debt. You will often see axis on the board representing complexity versus value. This solution is generally more effective than TODOs as it provides visibility to the issues as well as metrics. It also allows developers to explain why there is benefit to solving the issue.

The main problem with this solution is its separation from the code. This approach, by itself, doesn’t point out broken windows in the code and it doesn’t identify the exact location of the issues in the code base. You can combine this approach with TODOs, but we then have a consolidation problem and the two tend to get out of sync.

So what’s the alternative?

The Task Scanner Plugin for Jenkins provides the best traits of both of these solutions. This plugin allows you to scan for open tasks in the code base and generate a report that is visible to the entire team after each build.

For example, we could define the following task tags for use in the code base:

  • TECHDEBT_1 – high priority technical debt
  • TECHDEBT_2 – normal priority technical debt
  • TECHDEBT_3 – low priority technical debt

The priorities should first be assigned by the development team and can be revised after discussion with the product owner. These task tags are then defined in the code similar to TODOs. The description should place an emphasis on describing the problem and the reason it should be addressed:

// TECHDEBT_2 this method contains a temporary hack to support HR 
// requirements going into effect on 7/15/2012.  This will affect our 
// ability to make changes to the employee retrieval service in the 
// future.  Story points:  2
public void retrieveEmployee(Long employeeId) {
  // ... ...
}

The Task Scanner Plugin scans the code base for these tags on every build. It then generates a nice report as well as statistics regarding the task tags you have configured. The statistics gathered include:

  • the number of technical debt instances
  • the priority of each technical debt instance
  • the description of the technical debt
  • highlighted code related to the technical debt
  • graphs describing the trends of technical debt
  • and more…

This makes the technical debt visible to the entire team after each build. The build can even be set to become unstable or fail depending on the number of task tags found.

This approach addresses the criteria for dealing with technical debt, but requires discipline among the development team. It relies on appropriate tagging of technical debt as well as quality descriptions of the problem. So let’s evaluate this solution in terms of the criteria we have defined:

  • Consolidate the Debt – technical debt tracking is consolidated in the code base
  • Eliminate Broken Windows – by notating the technical debt clearly in the code base, it’s obvious where the broken windows are
  • Make it obvious to everyone – the report generated by the build is available to the entire team and nothing is more noticeable than a build failure
  • Tell me why there is benefit – the report also contains the comment provided by the developer which provides the reasoning
  • Keep it close to the code – as with TODOs, we have the information about the technical debt directly in the code base
  • Track metrics about the problem – the priority system of the task tags gives a priority for backlog handling. In addition, charts are generated over time showing how much technical debt exists versus what has been addressed

If you have any additional suggestions for the solution or additional solutions you’ve tried that meet the criteria, please leave them in the comments.

Consolidate your Technical Debt!

Do you have a technical debt problem? Just like having too much personal debt can lead to financial ruin, technical debt can ruin a project. Ward Cunningham created the metaphor of technical debt to put a concept around coding cruft that need to be addressed.

The problem I come across in most projects is that the technical debt is scattered. It may be in the heads of the developers, in TODOs through the code base, on a backlog, in JIRA, on a special board devoted to technical debt. The problem becomes that it’s scattered and disorganized. Worse, it’s often invisible or indecipherable to the business owner making the decisions.

This leads to the technical debt piling up over time and rarely being addressed. So what would my perfect solution involve?

Consolidate the debt

First off, track all technical debt in a single location. Tracking it in multiple places only leads to confusion and makes it more difficult to address the problem. In addition, it’s hard to see the relationships between technical debt when the problems are noted in multiple places. Just like an Agile project has a backlog where all work to be done is tracked, technical debt should be tracked in the same way.

Eliminate Broken Windows

Broken window theory was first related to software development in the Pragmatic Programmer. Essentially, we don’t want people thinking sloppy code is the norm, it triggers bad behavior. Just like no one would consider littering in a beautiful, pristine park, developers avoid adding undesirable code to a clean code base. Notating technical debt should look appealing and should call out code that is undesirable to show that it is an exception, rather than the rule.

Make it obvious to everyone

Technical debt should be obvious to the developers, to the agile coach, to the business owner(s), essentially all those involved in the project. Without this, it is difficult to know what needs to be done and get it prioritized appropriately. If you are strictly following a prioritized backlog, not making technical debt obvious means it may never get resolved.

Tell me why there is benefit

When looking at technical debt, everyone should understand why there is benefit to addressing it. This could mean that we give a description of why it is beneficial, or we call out the reasons why not addressing it would be harmful to the project. The key is having everyone understand the reason the problem should be dealt with.

Keep it close to the code

This makes it easier to pinpoint exactly what code is causing the issue. Without this, there may be confusion as developers move on and off of a project as to where the issue was and how it can be addressed. Simply saying, “Address performance issues in the retrieve employee query” may lead me on a chase through the code to determine which employee query we are referring to. This also helps alleviate the broken windows issue discussed previously.

Track metrics about the problem

Metrics are critical to understanding a problem. How can we determine ROI if we don’t understand how difficult the problem is? At the very least we should provide some metrics describing the complexity of the problem and the value of solving it. These numbers may change over time, but at least they give us some quantifiable information about the problem.

So this is what I would like to see out of a solution to the technical debt problem. If you have any additional ideas, please leave them in the comments section. In the next post, I will give the advantages and disadvantages of the approaches I’ve seen to addressing the problem. In addition, I’ll provide an alternative solution that addresses all of these concerns, so stay tuned.

Is this Experimentation or SOS?

Experimentation. It certainly provides value, but must be watched closely. Wait, there’s a new WordPress plugin! I’ll come back to this… Constantly trying new ideas and never landing on a consistent approach becomes a cancer for a project. If left untreated, it creates project delays, technical debt, and reduces velocity.

Experimenting is critical to the success of a project. It ensures that we find the best technology, the best approach, and the best design for the product. Constantly searching for new technologies, new approaches, and new designs becomes Shiny Object Syndrome (SOS). There are ways to combat Shiny Object Syndrome without squashing experimentation.

Experiment in the right context

Is this a one-off solution or something that affects the larger scope the project? Always ask yourself this question prior to experimenting. One-off solutions should be implemented as just that, a one-off solution. Don’t spend excessive time experimenting as the R&D costs will never pay off. In these cases, find a solution and run with it. At the same time when experimenting with a solution, make sure you are not building a Rube Goldberg machine to feed the dog.

Always time-box experimentation

When you have a problem that impacts the larger scope of the project, put a time-box around the time you spend searching for a solution. Spending 2 weeks may be acceptable within the context of a project, but spending 2 months is likely excessive. Pick a time-frame that makes sense within the larger scope of the project. In agile terms this is often called a spike and allows time for a team to wrap their arms around a problem.

Experiment early on

Once a team has attained a high velocity and has a stable approach to the problem being solved, the benefit of experimentation may decrease.

I know we’re releasing next month, but I think we could benefit from changing our architectural approach to CQRS.

There are maintenance benefits to code consistency and a consistency of approach. It often makes sense to continue the same approach for the current project, but experiment on the next project.

Innovate with appropriate technologies

Innovation is critical to help companies achieve better return on investment from their software investments, but make sure your innovation isn’t misusing a technology.

I know! I’ll use the microwave to melt this aluminum.

Each technology has a sweet spot, an intended use. This is where the technology shines and increases your ability to succeed. Used the wrong way, a technology can hinder a project, or worse, create issues that are only found once the project is released.

Experimentation can make your project a shining success, but make sure you follow these tips and avoid shiny object syndrome.

By |Agile|Comments Off on Is this Experimentation or SOS?

Agile Adoption Challenges: The Four Stages of Learning

Having taken some college courses on Psychology, the subject has always been interesting. Recently while reading Introducing NLP, I came across The Four Stages of Learning. This struck a chord when thinking about the challenges encountered with organizational Agile adoption.

The The Four Stages of Learning as described in the book are:

1. Unconscious Incompetence
2. Conscious Incompetence
3. Conscious Competence
4. Unconscious Competence

These stages are best described by the example of driving. From the book,

First there is unconscious incompetence. Not only do you not know how to do something, but you don’t know you don’t know. Never having driven a car for example, you have no idea what it is like.

So you start to learn. You very soon discover your limitations. You have some lessons and consciously attend to all the instruments, steer, coordinate the clutch, and watch the road. It demands all your attention, you are not yet competent, and you keep to the back streets. This is the stage of conscious incompetence when you grind the gears, oversteer, and give cyclists heart attacks. Although this stage is uncomfortable (especially for cyclists), it is the stage when you learn the most.

This leads you to the stage of conscious competence. You can drive the car, but it takes all your concentration. You have learned the skill, but you have not yet mastered it.

Lastly, and the goal of the endeavor, is unconscious competence. All those little patterns blend into one smooth unit of behavior. Then you can listen to the radio, enjoy the scenery and hold a conversation at the same time as driving. […] If you practice something for long enough you will reach this fourth stage and form habits. […] However, the habits may not be the most effective ones for the task. Our filters may have caused us to miss some important information en route to unconscious competence.

When you think about trying to get an organization to adopt a new process, this has to be considered. Each organizational member has already stepped through each stage of learning with the existing process and developed habits. They have the unconscious competence necessary to “get their job done” while “enjoying the scenery”.

By introducing a new tool, technique, or process into the organization, you are asking them to unlearn by going from stage 4 back to stage 2. Relearning is then moving from stage 2 back to stage 4 with more choices to create more efficient patterns. Obviously there is going to be resistance to this given the existing learning investment.

There must be strong motivation for someone to go back from stage 2 to stage 4 in the learning process. When you learned to drive a car, independence was your likely motivation. When learning to code you wanted a good-paying job (or maybe you really enjoyed it). The key point is that there is strong motivation to learn.

Convincing members of an organization to relearn their approach to developing software is even more challenging. It will certainly require more than just a good argument, you will need to motivate them and keep them motivated throughout the relearning process. Keep this in mind the next time you encounter resistance to your agile methods. It may help you be a bit more patient and willing to try alternative approaches when you understand their perspective.

Coder to Consultant: 5 Steps to Build Social Awareness

Social awareness is a critical skill as a consultant. No, I’m not referring to the latest social networking technology, I’m talking about how well you navigate social interaction with others. It’s easy to fall into the habit of sitting at your desk all day long and coding. Coding is your job and hopefully you enjoy it, but coding can make us introverted (read anti-social). Humans interaction is much more complex than machine interaction. Subtle behavioral cues make up the lion share of how we communicate.

Humans instinctively provide these cues through body language, facial expressions, and tone of voice. Just imagine how many ways you can interpret the word hello. Just by changing body language, facial expressions, and tone of voice you can give a cheerful greeting, indicate surprise, or even belittle someone. A consultant must be skilled at reading these cues to be successful at selling ideas and maintaining positive client relationships, but social awareness requires practice. In this article we’ll discuss how you can make yourself more socially aware.

Socialize in the Office

It may sound cliché, but walk around the office during your breaks and take part in water cooler chat. Try to interact with people you’ve never met in the office. Open with them (i.e. initiate the conversation). If you are uncomfortable in social settings, prepare some conversation topics (e.g. simple things like the weather or a sports game). Pickup on their cues in the conversation. If they mention something that you are interested in (e.g. fitness, boxing), tell a story of your own about the topic. Try to relate to their experiences in a meaningful way. Not only does this help you build social skills, but it also increases your social network.

Pay Attention in Meetings

Not just to what others are saying, but pay attention to their behavioral cues and reactions. If there is someone who is very successful at driving meetings in his or her direction, you will likely notice that they are very adept at reading others. Learn from them and even ask for their advice. Those who are successful are often excited to share their thoughts with others.

Dress for Success

While being a coder often gives us the freedom to dress a little more casual than the rest of the business world, dressing well serves several purposes. First, it sets you apart from the coder crowd. While it may not be a fair stereotype, if you look more professional, others won’t see you as one of those “weird IT guys.” A professional look makes you more approachable. Second, looking nice can help to build your confidence (for more tips on building confidence see this previous post). If you need some style help, go to a fashionable business casual boutique and ask for help (e.g. Banana Republic). Once you have a good feel for your style you can shop less expensive stores.

Take up a Sport and/or a Social Cause

Sports and social causes are a great way to meet people and socialize. The great thing about these types of gatherings is the attitude of all those involved. In general, these people will be upbeat and in a great mood. This makes interaction much easier. In addition, opening becomes easier as you will be introduced to everyone when you start.

Work on your Emotional IQ

Be considerate of others and evaluate how your actions or words affect their emotions. The Wikipedia definition of emotional IQ:

a self-perceived ability to identify, assess, and control the emotions of oneself, of others, and of groups

Avoid being overly technical, be friendly, outgoing, and conscious of the feelings of others. This gets you far in the workplace.

Tips for Success

  • Don’t be too much of a talker. Keep your conversations as short and to the point as possible. In general, people like a brief social interaction but long winded conversation keeps them away from their work and may cause them to think of you as boring.
  • Conversation goes two ways. Give the other participant openings to add to the conversation. People generally like to talk about themselves and will have good feelings toward you if you are a good listener.
  • Don’t get discouraged. Some people are not social (hey, you may be thinking you’re not social as you read this) or may be in a hurry. If someone cuts out of a conversation quickly, don’t take it personally.
  • Beware of office gossip. Gossip is not a good conversation topic. If you are talking to someone who begins to gossip, try to exit the conversation gracefully. Those who gossip are very likely to gossip about you and what you said.

If you have other tips from experience that help to build social awareness, please post them in the comments.

Coder to Consultant: 5 Steps to Build Confidence

In a recent discussion with a colleague, we were pondering the idea of how a coder can become a consultant. When I say coder, I’m referring to someone who has become skilled at the craft of developing software. This is not a junior developer, but a developer who has the ability to solve complex software problems. When I say consultant, I mean a coder who has: confidence, social awareness, persuasiveness, and the ability to negotiate.

In more concrete terms, a consultant can code but also has the ability to sell ideas, elicit requirements, negotiate scope and cost, and maintain a positive client relationships. An initial step in this journey is building confidence. Specifically the confidence required to speak in front of groups. This article will focus on some steps you can take to help build this confidence and reduce your anxiety.

Study those with success

Anxiety-level: Low
Confidence boost: Low

A good first step is to study those who are successful consultants and try to learn from their actions and behavior. These can be colleagues or speakers at conferences. There are plenty of videos online of very skilled presenters (e.g. InfoQ is a great source). Pay attention to the way they interact with others, how they present to an audience, and how they carry themselves. You can use and practice their techniques when you follow the other steps outlined below.

Demo your code to end-users

Anxiety-level: Low
Confidence boost: Medium

A common agile practice at the close of an iteration or sprint is a demo. The demo is a time to be proud of your work as you show off your accomplishments. By walking through your code in front of the group, you can begin to overcome any fears of speaking in front of a group and positive comments from the end-users help to boost your confidence. Demos are an easy place to start speaking in front of groups thanks to their scripted nature. Your likely to feel more comfortable because you know exactly what you are going to say. If your team doesn’t follow this practice, recommend that they do.

Get involved in requirements gathering

Anxiety-level: Medium
Confidence boost: Medium

Perhaps you are already working with users to elicit requirements. Certainly direct communication is preferable between developers and end-users to gather requirements as this ensures a common understanding of the end goal. In addition, it helps you as a developer to become more skilled in social interaction as you work to gather the information necessary to implement a solution. Communicating with end-users requires the ability to build rapport and communicate effectively. The next time your team is gathering requirements for an iteration or sprint, speak up and be an active participant.

Present to your team

Anxiety-level: Medium
Confidence boost: High

Recommend that your team hold lunch-time or after hours learning sessions and volunteer to be the first speaker. Not only is this a way to build knowledge among your team and show yourself as a leader, but it will help polish your skills in speaking in front of a group. Make sure to take questions from the group and try to elicit conversation. Being comfortable and confident with thinking on your feet is a critical skill that requires practice to do it well. Practicing this skill in a comfortable setting in front of your colleagues will help to reduce anxiety.

Present to your local user group or at a conference

Anxiety-level: High
Confidence boost: High

Once you feel comfortable in front of a group, you can take it to the next level by finding a good topic and presenting at a local user group or conference. Speaking in front of a large group of strangers can initally be a nerve-racking experience but accomplishing this feet will greatly boost your confidence.

Tips for Success

  • Never focus on mistakes. If you make a mistake, simply move on or you can even joke about it. Joking about mistakes often makes a group like you even more as it shows humility.
  • Be prepared. The Boy Scout motto is actually very useful for reducing anxiety. You will always feel better if you are very knowledgeable about the subject matter you are presenting on or if you prepared questions for end-users ahead of time.
  • Find a mentor. A mentor can provide useful tips for improvement by observing you and providing guidance along the way. A mentor often has plenty of insight from personal experience that he or she can instill in you.

If you have other tips from experience that help to build confidence, please post them in the comments.

JBoss Seam: Agile RIA Development Framework

JBoss just published a white paper that describes how Seam enables rapid development of RIAs by eliminating technology hurdles and placing developer focus back on solving business problems. Specific enterprise use cases demonstrate how increasingly complex features can rapidly be introduced into a software product with Seam in an iterative fashion.

The white paper is written in a way that avoids a technical deep-dive so that regardless of technical expertise, the value of Seam can be well understood. This allows not only developers but also management understand why JBoss Seam is the right framework for an organization’s next agile RIA development project. I authored the paper in collaboration with my colleague Nirav Assar.

Learning an unfamiliar technology is like learning to drive

It seems common for developers to look for faults in established technologies when an issue is encountered.  As a developer struggling to learn an unfamiliar technology, it is easy to make mistakes.  These mistakes lead to frustration which, in turn, can lead the developer to blame the technology rather than taking the time to analyze the problem and identify the real issue.

Anyone can fall into this trap and I still feel myself being pulled by this temptation at times. When you are working with an established technology, it’s always necessary to realize that the problem is almost undoubtedly in your code, not the technology you are using. As we learn the technology and continue to increase our depth of knowledge, this temptation lessens with each problem encountered. Let’s take driving as an example.

When I was learning to drive, I was a poor driver (most teenagers are). To the frustration of my parents, I had several accidents, fortunately all were minor. After having an accident I was frustrated with myself for the mistakes I made while operating the vehicle. I didn’t have the gall to blame the vehicle, claiming faulty brakes or the steering went out… Sure, these were possibilities, but unlikely. It was much more likely that my inexperience in operating the vehicle led me to make poor driving decisions.

With this mind set I continued to drive and improve my skills through experience behind the wheel. Over time I built a kind of intuition while driving that helped me avoid those mistakes.  At some point I may realize that a different vehicle may be easier to drive, more suited to accident avoidance, safer, etc, but I can only come to that realization as an experienced driver.

So by taking this same stance when learning an unfamiliar technology, we can become better developers. Struggling through the mistakes and the frustration while gaining experience helps build the intuition of a top-notch developer. So, the next time you find yourself blaming the unfamiliar technology you are working with out of frustration, stop and think about it. Are you really frustrated by your inexperience or is the technology really to blame?

So let’s review some techniques that can help us when attempting to solve problems encountered with an unfamiliar technology.  I also covered several of the Agile practices mentioned here in my previous article, 5 steps to improving your development process.

Read the Manual

I can’t tell you how many times I have solved a problem by simply reading the portion of the manual describing the API I am attempting to use. This may seem like common sense, but unfortunately time constraints often seem to get the best of developers leading them to copy-and-paste Programming by Coincidence.

Isolate the Problem

While this may be an obvious approach to problem-solving, it may be easier said than done depending on your approach to development. TDD (Test-driven development) is a very effective technique to isolating the problem. If you know what you have already done is working as designed, you can be reasonably sure that the issue is isolated to the code just added. Now try to write a test to prove the issue with the newly added code which can drive you to the root cause of the issue.

Commit Regularly

Committing regularly to your VCS (Version Control System) is a necessity to obtain the benefits of continuous integration. This technique is also effective for allowing you to revert back to a working revision if you find yourself too far down the rabbit hole. I often use this approach to attempt various hypotheses to solving the problem. If a hypothesis proves incorrect, simply roll back and try the next hypothesis.

Logging is your Friend

I read an article recently on DZone by Bharath Ganesh that reviewed this basic principle. Look at the logs! While stack traces don’t always provide the most obvious indication of the issue, they at least give you something to search for. For an established technology, simply Google’ing the exception message will often provide at least an inkling of what the issue is related to.

Maintain a Positive Attitude

Sometimes this is easier said than done, but it is important to remain determined to solve the problem. This may require taking a break, discussing the problem with a co-worker, sleeping on it, etc.

What techniques do you recommend for problem solving with an unfamiliar technology?