Archives

Quick! Think back to your most fond projects. Were they the most challenging or the most profitable? Maybe, but I bet you had a great team. I’m convinced that the most rewarding and successful projects share a common attribute, an outstanding team.

What makes a good team?

Is it a collection of rock stars that work 90 hours a week? Nope. Instead it’s people that work well together with copious amounts of respect and willingness to help other team members even if they don’t have the same role (developer helping BA, BA helping tester, etc). Good team members are:

• honest. It’s hard working with people that can’t be trusted
• good listeners. They don’t need to put forth their opinion on every topic.
• on time. You don’t have to be on time, you can be early.
• mentors. They enjoy developing junior team members
• willing to fill in gaps. Isn’t it great when a developer speeds up the build or cleans up the CSS?
• not complainers. Complaining is really contagious and has a big effect on morale.
• skilled, but always improving their craft
• respectful

Pathfinder is always looking for talented developers who thrive in team environments. If this sounds like you, please check out our available positions.

Share/Bookmark

photo credit: RickC

Many developers I talk to say they have tried Test Driven Development (TDD), but it “didn’t work for them”. Why is this so often the case? I believe that the main reasons are 1) it wasn’t done correctly 2) the effort was too quickly abandoned 3) the benefits were not obvious to the developer.

1) It wasn’t done correctly.
Doing TDD the right way is beyond the scope of this post. The best ways to learn are pairing with a TDD expert and reading some of the good books on the subject. I really like The RSpec Book and Test Driven.

2) Abandoning the effort too quickly.
At first, development time will increase until proficiency in TDD is obtained. This improvement ravine is very well documented by Martin Fowler.

3) TDD benefits
Though the TDD benefits at the micro-level are significant, the macro-benefits are outstanding! Preventing or fixing bugs early provides a huge cost benefit to the customer. The cost of fixing design or coding bugs exponentially increases with time from bug authoring.

Some argue that the same benefits can be achieved with Test After Development (TAD). In my experience, TDD is much better than TAD for the following reasons:

• Keeps you focused. At any time during the day, you should either be writing a test for a feature or writing code to make that test pass.

• Less code. TDD promotes Do The Simplest Thing That Could Possibly Work (DTSTTCPW). Let’s write code that gets the product delivered instead of frameworks that may or may not ever get used again!

• Necessarily promotes testable code

• FASTER. It’s a lot faster getting it right the first the time! It’s much faster fixing bugs as soon as they are authored

• Testing the feature before it’s implemented tests the intent of the code. When TADing, the intent could have been forgotten

• Very high code quality

• Refactor with confidence. Behavior driven tests ‘protect’ the required features, which means that refactorings should cause test failures

• Thinking of and designing for edge cases up front promotes a better and more stable design

Share/Bookmark

Is remote pair programming productive? Yes!

I have been successfully pair programming remotely almost every day for the last 3 years. It is very much like local pair programming with some minor differences…. OK. Some major differences, too.

Major

Instead of sitting down with your partner and sharing the same monitor and possibly the same keyboard, the screen will need to be shared virtually. There are many options including GNU Screen, iChat, Skype, yuuguu, yugma, and TeamViewer. Also, something like Google Talk or Skype should be used for voice chatting.

Minor

You know when you are talking on the phone that your attention is more focused on the conversation than when you are locally talking to someone? The same happens in remote pair programming. It is very intense and productive because both developers are extremely focused. You really need to remind yourself to take breaks, switch navigators, and go to lunch!

Share/Bookmark

A couple of years ago I had the benefit of seeing agile contrasted against waterfall with the same development team on the same project. The team had recently delivered the 1.1 version of a global web application. The customer then took over the project by replacing the project manager and business analysts with people who had no agile experience.

Up until after the 1.1 release our highly productive team absolutely loved coming to work in the morning. We were eating up storing points with an insatiable appetite and pressure to perform came from inside the team. Frequently our roles would cross. Developers would help out Testers and BAs as needed and the Testers and BAs worked very closely together to document proper story acceptances.

When agile was dropped for a more traditional process, things deteriorated very quickly (teamicide). I noticed major negative consequences in user stories, project planning, management, and software development.

Stories

The agile team that was together from inception through release 1.1 benefited from testable stories with high value features. Developers worked with Business Analysts to identify tasks within a story that would require significant development time so that the Product Owner could make informed decisions on whether or not a particular feature provided enough business value to warrant the cost. The BAs also enjoyed lower cost alternatives provided by developers. Only minor changes to a story were allowed after a pair of developers started on it. Significant changes required a new story.

After release 1.1, pseudo-stories were created with many nice to have, but not critical requirements with no developer input. Story requirements changed throughout the iteration including after the story delivery.

Planning

The agile team assigned points to stories during the inception. The amount of points completed during an iteration determined the team’s velocity. The average velocity over the last two iterations was used to predict release dates.

The new project manager on the post-1.1 team planned out the next four releases in Microsoft Project with no input from the developers. The releases had unrealistic delivery dates for features that were not yet defined. This is the classic “phony deadline” technique used by managers to (de)motivate developers.

Project Management

The agile project manager was deliberately inattentive to enable the team to self-organize. This resulted in very high morale because developers felt free to contribute ideas and felt a sense of project ownership. The agile project manager’s primary role was to remove obstacles that would otherwise distract the team.

The new project manager micromanaged all aspects of the project. We continued to have a stand-up every morning, but as each person gave a status, the PM would ask further questions like “how much longer until the story is completed?”.

Development

Pre-teamicide, pairing time was protected, the velocity was high, the code quality was good. Pressure to perform came from other developers. All of this was achieved a sustainable pace with little or no overtime.

Post-teamicide, development time was highly fragmented through frequent meetings, phone calls, and IMs. The velocity was very low and pressure to perform came from the project manager who had set unreasonable deadlines. Large amounts of overtime were required, which led to many more bugs in design and code.

Conclusion

This project thoroughly convinced me of the effectiveness of the agile methodology. It was a great learning experience, but I hope it is not repeated!

Share/Bookmark

I recently published the mort_calc gem at gemcutter.org. The code can be found at http://github.com/perry3819/mort_calc/.

The gem calculates the APR and monthly payment for a mortgage in the United States.

Calculating the monthly payment is straight forward.

C = Loan amount

E = Extra costs

r = monthly interest rate = interest rate / 1200

N = amortization term in months

An iterative approach is needed to find the APR. The equation for the APR follows.

Share/Bookmark