Posts tagged Development

Aligning Purpose

October 14, 2009 · Filed under Point2 - Process and People · Tagged , , , , , , , ,

In August I was fortunate enough to attend the Agile 2009 conference.  I saw two excellent sessions presented by Pollyanna Pixton.  I later found out that four other sessions (attended by Tefon) included recommendations of the book Stand Back and Deliver, authored by Pollyanna and 3 of her colleagues.  These presenters were so convincing Tefon even purchased the book while still at the conference.  It was a good read, but the chapter on the “Purpose Alignment Model” was by far my favorite.

The Purpose Alignment Model is a simple tool designed to do exactly that – facilitate an alignment of purposes.  The underlying premise is all product features or development that a company performs can be placed on two scales:  how critical and how differentiating they are to the operation or success of the company.  With everything placed on these scales, they can then be combined into a graph.

Purpose Alignment Model

Purpose Alignment Model

This simple graph can make discussion about any number of product features or work processes significantly easier and more effective.  When discussion about a feature starts by first placing it on the graph above, it is placed sharply into perspective.

What constitutes a mission critical differentiating feature?  One simple method for determining this is to ask ‘Could this feature be the center of an advertising campaign for the product?’  These features are the driving force to a product’s adoption and define the identity of the company.  If every feature gets a ‘yes’ answer to this question the model is being used wrong.  Trying to differentiate with every feature will result in little more than a mediocre product.  A select few features should be placed in the ‘Invest’ quadrant and these are the features that, naturally, should receive heavy investment.  If these features aren’t the most polished and solid in the product, get to work.

If an honest assessment of everything about a product is completed with this model, the majority of what might initially have been placed in the investment quadrant will end up falling into the parity quadrant.  The parity quadrant is interesting.  Most of a product’s features will invariably not be differentiating, so why waste resources trying to develop them?  These features are mission critical, make no mistake about it, they have to work and they have to work well.  Parity features will drive the sticking power of an application, thus it is still critical to get them right.  The key point, however, is that parity features only need to reach parity.  No wheel reinventing required.  Parity features aren’t innovative.  Look at what the market is doing.  What is the accepted best practice?  Do that and nothing more.

If a feature is differentiating but not critical to the success of the business, find a partner.  Don’t waste resources that could be spent getting parity features to parity and investing in mission critical differentiating features.  Find a partner who is investing in the feature and use them.

If a feature is not mission critical and not differentiating, who cares? If a feature in this quadrant is being worked on, ask why.

If every feature to be worked on is placed properly relative to each other on this graph the result is an amazingly powerful communication tool.  Suddenly everyone from the CEO to the developer implementing the feature can easily be on the exact same page.  With an aligned purpose across the whole team, from executive to business to development to IT, more time is spent making a profit and less time debating about how to make a profit.

By: Dustin Bartlett

Leave a comment »

What happened to building race cars?

October 5, 2009 · Filed under Point2 - Process and People · Tagged , , , , , , , , , , ,

When my older brother was a young man his fantasy was to be a part of a great team building cutting edge race cars. His passion led him to spend countless hours on his own figuring out how an internal combustion engine works, how well-tuned suspension helps keep power to the ground, and why one transmission was better than another. He got his foot in the door at the local garage and began his career as a mechanic. Today he is a very successful, respected and knowledgeable mechanic at a different local garage. I am very proud of him and the skills he has acquired over the years. But what happened to building race cars?

At his garage my brother had all the tools he needed plus skilled co-workers.  What stopped him from building his race car?  Whenever my brother wanted to work on something new, innovative, and generally cool he would have to wait until after work hours or the weekend.  Young and energetic he would complete his work day and dive into his own pursuits.  Sometimes he was even able to get co-workers to stay with him and try something he could not do alone.  This lasted for a while but as time went on he could not afford to invest the hours his creative mind was asking of him.  At the end of the day he would be exhausted and ill-suited to pour creative energy into his projects.

In the agile software development environment I currently work in I am surrounded by seasoned professionals, inexperienced raw talent, and everything in-between.  I am proud to be a part of a company that values professional development time as discussed in Hemant Naidu’s post, A Vivid Imagination Isn’t Just for Kids.  In doing this we acknowledge how important creativity and innovation is to the growth and success of our company.

In an effort to provide momentum to the professional development time the development leads have asked our developers to get together with no manager participation.  They have been tasked with using their professional development time to work together on the major hurdles affecting development across all teams.  It is our hope that leaders will rise, tribes will form, and developers will learn to work together on their own initiatives.  As a developer, expect from us the creative freedom to try, and from yourself the courage to fail.

By Logan Peters

Leave a comment »

Maven with included Dependencies

September 4, 2009 · Filed under Point2 - Technical · Tagged , , , , ,

One of the most common, and, in my opinion, valid criticism’s of Apache Maven is the way it handles dependencies.

The default way of doing dependencies in Maven is for a build to look for dependency jars in one of a specified number of places. If you don’t specify a location, it will start with your local Maven repository, then a stock set of online repositories (such as ibiblio).

What this means is that you can quickly and easily add a dependency to your project by just listing it in the POM, and Maven will frequently just go get it for you as required. For dependencies that don’t change rapidly (which is generally a bad idea for entirely separate reasons), the local copy is always used, so after the first download you don’t go get the jar again unless it changes.

The downside of this (and hence the basis for the criticism) is that your local repository is considered a cache, and is not checked in to your source control system. Maven aficionados believe that source control should be for what the name implies: source, not jars (which are an artifact, not source code). This is good, except in situations where the local repository is removed (as it’s a cache, and not “backed up” by being in source control) and you want to rebuild your project. Normally, no problem: Maven will simply go back out into the wilds of the internet and get your jars for you again. Except when it can’t, which is where the problem starts.

Let’s say your project depends on foo-1.0.jar, for the sake of discussion. Foo-1.0.jar is found in a repository at http://baz.com. No problem. Two months from now, you come back and make a change to your project, and your local repo doesn’t have foo-1.0.jar in it. Maven goes to get it for you, but baz.com has gone offline. Oops. Now you can’t build your project at all. Worse, let’s say you *do* find foo-1.0.jar, but it’s been updated. Granted, this is a gross violation of the version scheme, but as baz.com is not under your control, it *can* happen – and Murphy was an optimist.

The first level of defense against this is to have a local jar proxy that *is* backed up, like Nexus. Nexus not only provides a safe haven for the exact versions of Jars you need to build your project, but also proxies new jars automatically, when set up correctly. That way, once you use that external dependency, it’s available on the local proxy immediately forever more, in precisely the correct version.

This solution is so good, that I always consider Nexus and Maven to be two parts of one solution – as you don’t really have reliable and repeatable builds without Nexus in the mix.

Another way to go, however, is perhaps even more straightforward, and might be appropriate if you have a limited number of “internal” binary dependencies – that is, binary dependencies that you generate within your organization between projects.

This is the option I want to describe in this blog, and it takes a form very similar to the old Ant style of having a “lib” directory in your project, and checking jars into source control.

You simply create a directory (called lib or whatever you wish, but “lib” might be more standard), and put your jar dependencies in it. Then you refer to each dependency in your pom.xml file with a special syntax, like so:


    <dependency>
      <groupId>mygroup</groupId>
      <artifactId>myjar</artifactId>
      <version>1.0.0</version>
      <scope>system</scope>
      <systemPath>${basedir}/src/main/
         resources/lib/myjar-1.0.0.jar</systemPath>
    </dependency>

Now the myjar-1.0.0.jar will be on my classpath during compilation, easy as that. I can then check in that nicely versioned jar file, and have a fully self-contained project, while at the same time being able to leverage the power of Maven and it’s rich ecosystem of plugins. If you’re using the shade plugin, this is an excellent way to create a self-contained executable jar file containing all of your necessary dependencies in one shot, rather than having to worry about classpaths at runtime.

In web applications, you can do even better. By placing the dependency in the correct spot in your source tree, you can have it automatically included in the finished .war file, while at the same time finding it in your classpath during compile time, like so:


    <dependency>
      <groupId>xstream</groupId>
      <artifactId>xstream</artifactId>
      <version>1.3.1</version>
      <scope>system</scope>
      <systemPath>${basedir}/src/main/
           webapp/WEB-INF/lib/xstream-1.3.1.jar
           </systemPath>
    </dependency>

This includes the xstream jar in my webapp. Every IDE that can digest a POM file (which include my 3 main ones, IntelliJ IDEA, Eclipse IDE and Netbeans) also automagically find the dependencies.

One minor constraint here is that you must use a *versioned* jar file – e.g. it must be named according to the artifact-version.jar pattern. I consider this a feature, not a limitation, as I’m a firm believer that all artifacts should be properly versioned, so I can tell what source code originally created them. Yes, I know that can be done internally, in a manifest or such, but I like to see the label on the outside of the box, so to speak.

As one colleague put it, now you can be assured of coming back to your project months or years later, even if you don’t have internet connectivity, and be able to build the darn thing again, without going off on a wild jar chase all over the internet.

This pattern can overcome a serious and legitimate objection to Maven, and might be appropriate in many situations. Give it a try, let me know what you think!

By: Mike Nash

Leave a comment »

RYE: Repeat Yourself Enough

August 7, 2009 · Filed under Point2 - Technical · Tagged , , , , , , , ,

RYE

RYE

As is often the case, I found myself discussing the relative merits of applying the DRY principle in code, because there was some overlap between two components doing similar things. I have long held the view that you should repeat yourself as many times as you need to in order to properly understand the problem you are trying to encapsulate in your abstraction. Without this, you are destined to repeatedly revisit your abstraction.

One of my former colleagues Charles Lowell talked about this years ago and as it turns out, he blogged about it here.

By: Chris Tarttelin

Leave a comment »

Why don’t people like my ideas?!

June 9, 2009 · Filed under Point2 - Process and People · Tagged , , , , , , , , ,

frustration1 Have you found yourself asking that question?  I’m sure many developers have, although this topic applies universally to anybody in any profession (or personal life for that matter).

http://agileshoptalk.wordpress.com/2009/06/09/why-dont-people-like-my-ideas/

By: Chris Dagenais

Comments (1) »

Failing Should Be Easy

May 14, 2009 · Filed under Point2 - Process and People, Point2 - Technical · Tagged , , , ,

failSounds kind of crazy doesn’t it?  Why would you want failing to be easy?  There’s actually a pretty simple explanation.

http://agileshoptalk.wordpress.com/2009/05/14/failing-should-be-easy/

By: Chris Dagenais

Comments (2) »

An Agile Business Analyst’s Creed (Part One)

April 23, 2009 · Filed under Point2 - Technical · Tagged , , , ,

I have been working on a creed for business analysts in an agile project. The purpose of this is to help guide and give direction to the various business analysts we have working on a number of different teams in our organization. This has not been an easy process nor is it complete. I believe it is important that we follow the agile manifesto http://www.agilemanifesto.org, adapting to the individual and to the organization while still providing direction to encourage improvement.

If we look at the extreme roles from the c2.com wiki http://c2.com/cgi/wiki?ExtremeRoles there are a number of places a business analyst could fit: The Customer, The Tester, The Doomsayer and The Manager. Based on my historical knowledge a business analyst will be more than one of these roles and this should be encouraged. Pigeon holing any one person into a clearly defined role assumes that everyone has the same skill set. When creating a creed we must ensure that it does not limit the role(s) the business analyst can perform within the team.

Every company has a different model, a different set of customers and issues that prevent the “ideal” agile management and development scenario. In our organization we have a customer base rather than a customer and a large number of stakeholders each with their own areas of expertise. The business analyst acts as customer proxy and is responsible for gathering information from a number of sources and writing the users stories (though not generating them). The process that we follow is as a result very different then if we had one internal customer that sits at the next desk over. When developing a creed it must be for a specific organization.

It seems clear that the creed needs to be dependent on the organization. It should be general enough to allow the business analyst to fill the best position for them in the team while giving enough direction to guide them towards making working software.

With all that in mind I give you our creed item number one:

A business analyst must be a subject matter expert for all user stories that are in development

By: James Townley

Leave a comment »

Avoid the Jack of all Trades trap

April 12, 2009 · Filed under Point2 - Technical · Tagged , , , , , , , ,

focus

Key ingredients to success and career growth, at least the two on my mind right now, are focus and determination.  Why are these things important?  I’ll tell you why, because when most people are asked how to be successful, focus and determination will probably slip off their tongue, however if you were to actually observe them at work and in their personal life, you would most likely see a lack of one or both of these.

Lets start with determination as it seems more obvious.  Determination isn’t really something in and of itself, it’s more of a measurement of what lengths you are willing to go to in order to achieve your goals.  So being very determined to accomplish something really just means you are willing to do certain things to get there, which usually will consist of things like:

  • Practicing
  • Researching
  • Learning
  • Looking for teaching/coaching
  • Anything else that makes sense.

Many people may say they are determined to accomplish something, but what they really mean is they really wish they could just wake up tomorrow and be at their destination.  That’s an exaggeration for most people, but for many it’s somewhere between that and what’s actually required to reach their goals.

Focus on the other hand is something that most people probably don’t think about enough.  Determination by itself is not good enough.  The problem is that when your goals are to become an expert at anything, no matter how determined you are you won’t be able to accomplish that goal without focusing on it.  You’ll need to cut out distractions, and stop trying to focus on improving skills that are not related to the skill you wish to be an expert at.  There is an old saying you’ve probably heard before “Jack of all trades, master of none”.  It’s relevant in all industries, and IT trades are definitely no exception.  I’d say it may be worse in IT but that wouldn’t really be an informed opinion so i won’t make any bets on it.

So, if you take my word for it, lack of focus will result in a jack of all trades.  To be more specific, a lack of refocusing will result in a jack of all trades.  The reason for that is because at the beginning of your career you won’t know what you want to focus on besides becoming a better developer, business analyst, sys admin etc.  Sticking to the development track because it’s what I’m most familiar with, you’ll initially need to focus on how programming works, basic skills related to the industry, and probably try to get a basic level of knowledge on as many things as possible.

So now you’re done school and ready for your first job.  You start out by soaking up as much information as possible, learning everything you can.  You learn about things like object oriented design, service oriented architecture, domain driven design, database design and performance tuning etc.

Skip forward 3 or 4 years, you’re quite competent in every aspect of your job, you’re a go to guy for your team, you can become competent at a new skill in short order at the drop of a dime.  You have basically reached the epitome of most peoples career – broad competence with the ability to pick up new basic skills quickly.

Now you’re faced with the decision everybody in the industry runs up against, and most people don’t even realize it.  Do I want to keep getting better, and if so, how?  The answer to the first question is a factor of determination.  How much are you willing to do in order to keep getting better?  The answer to the second question is focus.  Up until now in your career you’ve enjoyed getting better at everything, making constant improvement in everything.  Bad news – that’s not going to last forever.  You’re going to have to pick a skill, or subset of skills and focus on improving those skills.  The side effect of this is that you’re going to have to “defocus” on all skills not related to the ones you’ve chosen to focus on.  It’s a large hurdle for most people to jump because it’s easy to understand but hard to accept and work with.

This will be a turning point in your career.  You’ll either accept the hurdle and jump over it, taking a turn down the road to becoming highly skilled in narrowly focused areas, or else you can understand the hurdle but not choose to jump it (lack of determination) and decide to take the easy path which unfortunately leads to the dead end of being average, the jack of all trades trap.

So to sum up the thought, you’re going to continue to refocus your skills throughout your career.  Every so often you will zoom in on a new area that you’ll specialize in.  Once you have reached a certain level in those skills you’ll zoom in your focus again on yet another area to become more specialized in.  Only you can decide when you’ve focused enough.  The less focused you are the more skills you’ll be able to maintain a specific skill level at, at the expense of increasing that skill level.  At some point the only way to increase skill in some area you’re interested in will be to defocus on another skill and allow your ability in that area to lapse.

Focus and determination.  How determined are you to reach your goals?  Determined enough to allow your skills in something you used to be good at to lapse?  Willing to not be the go to guy for a laundry list of skills?  How many are you willing to drop, how much are you willing to work at the ones you’re going to focus on?  Keep asking yourself this question, it will play a key role in your career development.

By: Chris Dagenais

Comments (3) »

Focused Practice

March 23, 2009 · Filed under Point2 - Technical · Tagged , , , ,

We all want to be better at what we do, right? But how do we go about improving our skills? I think the answer is the same, whether you’re an aspiring software developer, musician, martial artist, or whatever. The key is focused practice. You need to put time into developing your skill. You can’t just put time in either. It has to be focused time. This is time where you’re consciously thinking about your craft, critically analyzing your work, and looking for ways to improve it.

Some of this possible during your day-to-day life; but in my experience, you always get better results by setting aside a special block of time to work on a skill.

Code Katas

The best way I’ve found to apply this to software is through code katas. A code kata is a problem simple enough that developers of any skill-level should be able to solve them. A kata is also small enough to solve in a reasonable period of time. My learning process currently goes something like this.

  1. Pick a skill I want to improve at.
  2. Pick a kata to solve, and a language to solve it in.
  3. Solve the kata while focusing on how to apply that skill to the kata.

For example, let’s say I wanted to work on my TDD-fu. I would pick a kata that I knew reasonably well; in my case that’s the bowling problem. I would pick a language that I knew well, and had a good testing framework; that would be java and junit. I would then implement a solution while thinking about things like…

  • How much code am I writing per test? Should I be writing more? Less?
  • Is my test naming clear?
  • Am I remembering to think about refactoring every time I see a green bar?
  • Am I aware enough of what’s going on to know when I’ve made a mistake and chosen a bad test?

You can use code katas to improve your skills with just about any technique related to software development. Just to name a few, they work well for improving your pairing practices, new languages, writing good OO code, and learning new tools. You just have to pick a focus.

A Coding Dojo

There’s been lots of success stories recently about coding dojos. A dojo gives us a social context in which to work on our katas with other like-minded people. It’s a great mechanism to get feedback on your work, but the downside I’ve found is that a lot of people are intimidated by this. I think the best way to deal with it is just to work on a kata in your own time until you’re comfortable with it, and then bite the bullet and seek some feedback.

You can find more information about code katas and dojos at http://codingdojo.org. See the kata catalogue if you just want to get started. There is another list of problems I’ve found useful here.

By: Kevin Baribeau

Leave a comment »

Hard Problems

March 20, 2009 · Filed under Point2 - Technical · Tagged , , , , ,

thinking

I ran into a hard problem today at work. Here it is:

Given two strings, check that the first does not contain a sequence of 3 consecutive letters that are also contained in the second.

Look easy? It should. I don’t know of very many easier problems. After implementing it though, I can’t truthfully say that it was easy for me. But, I don’t think the lessons I learned today are easy either. As far as I can tell, I made three mistakes:

Lesson #1: Be careful when picking your test cases

It’s easy to pick a test case that’s either too hard, or too easy to implement. If you pick a test case that’s too easy, you and your pair risk getting bored. Oddly enough, this is almost never a problem unless you’re actively trying to avoid picking a test case that’s too hard.

So, if you’re bored, then your tests are too easy… how do you tell when your tests are too hard? Well, that’s another hard problem. I don’t think I’ve nailed this down completely yet, but here are some clues I’ve learned to spot:

  • It takes more than one try to get your newest test to pass
  • When you do get your test to pass, another test fails
  • Your pair doesn’t understand what you just did
  • You find yourself wanting to refactor against a red bar

My advice when you run into any of these indicators is to stop. Stop writing code. Revert to a green bar. Now you have two options: Refactor, to make things easier; or pick a different test.

Sound easy? Try it. There’s two reason why it’s not.

First it’s hard to admit when you’ve picked a test case that’s too hard to implement. We’re programmers (craftsmen if you will), it’s our job to solve hard problems. We take pride in our ability to do so. We want to make that next test case work. Taking a step backward and reverting the code you just wrote (that doesn’t work) is an admission that you’ve made a mistake. Admitting this mistake is especially hard to do when you’re working on an “easy” problem.

Second, both of these options require you to THINK. It’s tempting to think that if you tweak a conditional here or extract a method there you’ll see a green bar soon. This rarely turns out to be the case. Even the easiest problem is going to require you to stop and think about the solution; probably more than you expected to.

If you run into this, Stop. Think about the problem. Discuss it with your pair. Then, take another crack at it.

Lesson #2: Commit Often

Today, my pair and I ran into all of the clues listed above, and failed to stop. It was at this point that we got burned by lesson #2. We realized what was going on, and wanted to revert to our last green bar. We hadn’t committed in 90 minutes. We were stuck with broken code. Oops.

I don’t have a strong opinion on when you should commit. Ideally, I would say you should commit on every green bar, or after every refactor step; whichever is easiest to remember for you. Of course, some teams are cursed with long running unit tests. Since you don’t want to commit without running your tests; this makes it difficult to commit so frequently. Do what you can to keep your tests running quickly, but in the meantime, find some balance between committing often and not letting your tests slow you down.

Lesson #3: Focus on your work — No Distractions

Today, during the “embarrassing pairing session”, I had an interesting email thread zipping through my phone, which dutifully beeped at me every few minutes. Every once in a while I’d try to keep up with it, meanwhile completely losing my focus on the problem and relying on my pair to get me back up to speed when I was done.

Please, be wary of checking your email or other distractions when pairing on a problem. If you’re not at the keybaord, your job is (among other things) to help figure out the next test, watch for warning signs like the ones I listed above, and maintain code quality. You probabaly can’t (I know I can’t) do any of these things while checking your email, or carrying on a casual conversation with a friend. Also, respect your pair. If they’re working, you should be too. They’re going to resent you if you don’t pull your weight.

By: Kevin Baribeau

Comments (3) »