If you're an ambitious new Rails developer in Chicago who wants to work along side Dr. Noel and our other sage Rails developers, check out our Rails Internship.

Related posts:

1. Why Chicago is Rails-town, USA
2. Summer Software Development Internship
3. Selling colleagues on progressive enhancement

Vu360, the latest Pathfinder product, was launched by our client the Blue Book of Construction earlier last month.

It’s an Internet-tethered desktop application that enables easy viewing, markup and takeoff of PDF and TIFF documents for the architecture, engineering and construction industry. Some of the features include:

• Blueprints for projects seeking bids can be downloaded and annotated from the online plan room.
• Once a contractor is done annotating and marking up a blueprint, the file is easily saved back to the online plan room for viewing by the developer, general contractor or architect.
• While work is underway, the blueprint is saved on a users local computer. The tool does not require a persistent Internet connection to function.
• The tool includes a multitude of notations and graphing unique to the construction industry.
• The tool makes it easy to perform item counts and calculate length, perimeter, area and volume simply by drawing a square, line, cube or irregular, ad-hoc polygon directly on the blueprint.
• Sub-contractors can search BPM Select, Blue Book's repository of contracting supplies and products within the tool. When quoting installation of flooring, for example, a sub-contractor can link to a product sheet for the specific type of wood flooring they propose to use.

So far it’s been getting rave reviews from customers, including this one:

"VU360 is an incredible tool, and it’s sooooo easy to use. I cut back on my “job” estimate by at least 80% actual time. That would have been enough to impress me but, on top of that, I was able to export the figures to Excel."

We like those kinds of reviews. They tell us we’re doing something right when we design and develop software.

Vu360 is free, so if you’d like to download it and play with it, just go to the Blue Book and check it out. We’d love to get your feedback, so let us know what you think of it.

You can also check out the case study in our showcase for more project details and agile development goodness.

Our client, the Blue Book of Building and Construction also has a 40 minute tutorial for Vu360.

Related Services: PDF Application Development, .Net Application Development, Custom Software Development, User Experience Design

Related posts:

1. Launched: Rapid Reporting Employment Chek
2. Down with HTML + Code Markup!
3. The Desktop Application is Dead…Almost

So, the question is: How to determine if your project/organization has that collective code ownership culture. And what team members (including managers ) can do to create/encourage it.

Does your project have collective code ownership?
Here are few things you may want to ask yourself to determine if your organization/project has collective ownership culture.

• Are tools like continuous integration and testing, code coverage and code metrics considered nice to have but not necessary?
• Is the project release schedule determined and then enforced with little or no involvement from developers?
• Is failure to slip on iteration stories viewed as failure on developer's part?
• Does your velocity seem to decrease with time?
• Do developers talk about my module, your module instead of our module?
• Do members aspire to leave your project and join other project?

If answers to these questions are mostly in the "yes" range, you may have a code ownership problem.

What's a developer to do?
Be a good citizen, strive to write good code. Leave any codebase cleaner than how you found it. Developer need to tame their tendency to guard their masterpiece code from other people's changes, infact welcome those. If you really really hate some design, try to pair with the person who concieved it and influence his thought process. This might be slow and furstrating but it will be better in the long term. If you rip out everything you don't like, you will end up owning everything. Remembership, it is a collective ownership. Code is very fluid, which means when coding, you can always take short-cuts to get stuff you are responsible for, done. Or you can take ownership and fix the general code quality (even if it take a little longer). These are all things that a developer is in control.

However, there are stuff that are beyond developer's control. It is hard to continue to be a good citzen when other members don't feel the same way and when your boss is holding your neck against a timeline. This is where managers can play a role.

Why do manager care about code ownership?
A manager cares about the quality of deliverable, team morale, attrition and deadline. An agile project manager can remote obstacles that prevent such culture from growing. Managers need to cultivate a culture where developers are not hard pressed to deliver on timeline at the cost of quality, atleast not often. Managers need to develop a culture of trust where developers are free to over-estimate stuff (atleast from their point of view). Hire team players overs smart but solo players.

What's a Architect to do?
Managers can't judge the quality of code and hence success of code ownership culture. Yes, there are code metrics like code coverage that attempt to quantify the code quality but those are not precise measures. Here is where architects can make a different. By architect, I mean anybody how has the direct or indirect authority to influence other developers and modify their behavior. Install tools like continuous integration, testing, code coverage and various other metrics. Encourage pair programming to reduce bus number and prevent knowledge silos (the bad side of code-ownership).

In summary, it could be a good thing when a team feels responsible when the project when in it and proud that they were part of a project that completed successfully. They owned the outcome of it, good or bad.

Related Services: Agile Development, Custom Software Development

Related posts:

1. What makes a good requirement document for an agile project
2. Data Driven Design and the Culture at Google
3. Code Coverage – Why?

Rails Test Prescriptions, the eBook put out by Noel Rappin, Director of Rails Development at Pathfinder, has been picked up by Pragmatic.

Congratulations to Noel - he's done a great job of furthering testing best practices in rails, and this is a great reward. As he said "I’m very excited by this. I’ve wanted to work with Pragmatic for as long as they’ve been publishing books, and I’m thrilled that this particular project will be able to get wider distribution and access to Pragmatic’s editorial expertise and skill."

* The current free “Getting Started with Rails Testing” ebook will continue to be available. If, at some time in the future, there’s a better Getting Started tutorial in the Pragmatic book, it may be offered as a replacement.

* The update site for current Rails Test Prescription owners will continue to be available for the foreseeable future.

* There will be one more official update to the current Rails Test Prescriptions, probably around the end of August. This will wrap up the chapter or two I’m working on, and tie up some other loose ends.

* After that, errata and information about changes to test tools will most likely be handled via this blog and an errata page on the rails test prescriptions site.

This is Noel's 4th book with a major publisher, following Professional Ruby on Rails, wxPython in Action and Jython Essentials. We're happy for Noel and happy to have him at Pathfinder.

Related Services: Ruby on Rails Development, Custom Software Development

Related posts:

1. More Kudos for Rails Prescriptions
2. Rails Test Prescriptions is now on sale
3. Announcing Rails Prescriptions

When OS X 10.5 (Leopard) was released back in late 2007, I told a colleague at the time that Leopard was, by far, the worst release Apple ever put out. You can pardon a bit of hyperbole there, but after a healthy string of solid releases of OS X that just "worked", the problems produced by Leopard were numerous (one might counter that this is all relative-- four to five issues might not sound as numerous to users of other operating systems, but for OS X, these were a pretty big deal, and kept me from switching for months).

By comparison, Snow Leopard marks a great return to the kind of releases the Mac community came to expect. Yes we still have a month left to wait for its release, and yes there might always be small glitches, but as one long-time Mac user the answer to the question of "is it really all that?" the answer is pretty clear to me at least: "Yes, yes it totally is."

There are two ways of looking at an operating system: the underpinnings of the platform (in the technical sense), or, in the popular sense, the body of applications surrounding and defining a baseline of functionality all users can expect each other to have. The great thing about Snow Leopard is, without getting into details itself, that there are enough improvements in both areas to make this a must-have upgrade. And as a footnote, the number of issues I have had with the betas so far have been relatively minor in comparison with 10.5. There really is no contest. Whereas the initial release of 10.5 brought some improvements to the operating system at a very large cost for early adopters, 10.6 brings a lot of improvements with much lower risk.

I'm not going to rehash what's new in Snow Leopard, but suffice to say that it proves out the wisdom of Apple's strategy to focus on improving the internals 'under the hood' for this release. Since the release of 10.5, Mac users have been fortunate enough to see improvements with other technologies on the platform (Safari 4 comes to mind), and hardware that continues to improve both in features and price. OS X by itself does not need to draw people to the platform-- the iPhone and Mac hardware will do that. So it seems to me that, thanks to these other factors, the keys to the OS have been given back a bit to the engineers-- and if my instincts are right, it's going to be a great release.

Related posts:

1. Making a good choice when using Flex components
2. Corners of the Rubyverse: RVM and MacRuby
3. Blogging from the GWT Conference: GWT as a Replacement for Java Swing Apps

Pathfinder and Rapid Reporting just launched EmploymentChek, the first employment verification tool that captures employment information from individual employers as well as automated subscription services.

Employment income is usually the primary means for an individual to repay a personal loan. Industry analysts estimate that 64% of all mortgage fraud is income- or identity-related, and that 21% of borrower applications have employment misrepresentations.

EmploymentChek is an addition to Rapid Reporting's existing web portal developed in Ruby on Rails.
Working within Rapid Reporting’s existing Rails environment, Pathfinder’s team delivered this highly-robust, first-of-breed solution in just over four months. EmploymentChek enforces anti-fraud best practices, and delivers extremely detailed reports including: extended public records findings and risk flags, responses to each interview question, interviewer’s subjective impressions, and detailed logging of unsuccessful interview attempts.

During development of EmploymentChek, the mortgage industry went through a period of downturn, which shifted priorities for the application. Pathfinder’s use of the Agile development process, which allows on-the-fly prioritization and reimagination of scope and features, allowed us the flexibility to meet the client’s changing needs in a volatile economic climate.

In addition, EmploymentChek’s service-oriented architecture allows for data vendors to be easily swapped out. This modular framework maximizes flexibility and eliminates the need for retooling the application when switching vendors, which saves time and money.

Take a look at the case study for more details.

Related posts:

1. Separating Reporting Environments In Production
2. Launched: Vu360 PDF Annotation and Markup Application
3. Touch Screen Kiosk in Adobe Air

I have been on about 10 different agile projects in last 2 years. As a hands on developer, the one area that is of special interest to me is what constitutes an iteration, what deliverables and progress metrics it contains? Sure they all contain a set of stories to be delivered and a working software in the end. However, the risk for over promising and under delivering or vice-versa always exists.

The goal is to promise enough (not under) and deliver on it while still taking on a few unknown. Or put it another way, minimize risk somehow. A quick search on internet couldn't deliver a convincing set of traits that would do the same and I believe this area can use some refinement.

Here are a couple of things that, in my experience, constitutes a good mix of deliverables that minimizes risk and strives to deliver enough for a given iteration:

Deliverable user stories with varying estimates:
With experience, it is evident that delivering 5 stories worth 2 story-points (2+2+2+2+2=10) is very different from delivering 5+5=10. While 5 is usually broken into sub-stories, the crux here is to have a varying degree of complexity for stories in iteration. This allows for showing progress with long hanging fruits while dedicating more attention to relatively complex story. It also allows for shuffling items and pairs based to developers' schedule during iteration.

Targeted research items or spikes:
Yes, the obvious here is to not take on too many research tasks. Such tasks have no promised outcomes and are hard to estimate. Here at pathfinder, we make strive to make such tasks as concrete as possible in terms of what approaches are planned and how much time we decide to dedicate for all the effort needed. The story point for such task depend on how much %age of iteration (in terms of time) such task is going to cost. A research task that takes 1 full day in a 2 week iteration will be worth 2 story points if iteration has 10 story points (assuming 10 working days in iteration). In short, identify concrete approaches and time-box such stories. And each iteration should have not more than one or two such stories.

Bug-fix and Refactoring items:
These are good low-cost items, meaning relatively more predictable in outcome. Refactoring stories are relatively easier to estimate accurately and act as filler tasks that can be performed while your pair is unavailable. Or you are sick working from home. Or can be postponed until end of iteration if things seem slipping into next iteration. Having a healthy supply of refactoring stories is not a bad thing, they can be picked up if iteration seems to be under-filled since they don't require specifications or requirements and are targetted at improving quality of code.

Mid iteration demo and re-balancing:
Mid iteration demos are optional but we find those very helpful in showing on going progress. While scrums allow teams to be current about ongoing changes, mid-iteration demo is more for client update and re-balancing with clients. Showing progress with demo also helps with re-balancing of tasks with clients for the rest of the iteration.

Again the goal is to strive to be as concrete as possible in approach given the unknowns and minimize risk. What are some of the things in your experience that work?

Photo Credit: http://www.flickr.com/photos/27620885@N02/3018033419/

Related posts:

1. You Shall Know Our Velocity!
2. Bullseye Diagram
3. Teamicide

We just published a case study on a Hedge Fund Analytics application developed in Flex. It's an extensible Flex based platform for real time analysis of hedge fund performance data, with dynamically updating charts, graphs and sophisticated filters for cumulative performance, return distribution, alpha, beta and correlations, commissions and fees, credit and sector exposure.

The system is designed as a modular platform which can consume data services from multiple sources, and can integrate multiple custom components. Custom components were designed to conform to a standard API. Components expose standard flex component properties and events so that properties and method references could be passed. This allowed individual dashboard applications to be built, fed data and customized at run time. Take a look at a video demo or read the longer case study on the Pathfinder site.

Hedge Fund Analytics

Related posts:

1. Flex Camp Chicago ‘09 Community Showcase Presentation Summary
2. Pathfinder Launches Beer Hunter, A New Flex + Ruby RIA
3. Google Analytics Tracking Component for Flash Platform

In an earlier post about the benefits of Agile and Scrum, I made a statement that bugs by their nature are not the same as normal features, and I wanted to take a moment to try and make my point a little clearer. Bugs and estimation have been a hot topic with us lately, but interestingly we are all working on different projects and actually have a slightly different take on the subject.

My definition of a bug is: A feature that was specified, and you attempted to deliver, but is not working according to your intentions. (ie. "I thought it WAS saving to the database")

Not a bug: A feature or variation that you hadn't intended to create in the first place. ("Oh, I didn't know it was supposed to do that when you clicked the back button")

And with that understanding I say "Bugs can't be estimated"

The reason I make the distinction that way is because I think there are a lot of things that should be considered 'Missed Requirements' or 'New Requirements' that often get classified as bugs, when they are not. Both of those things should be as easy to estimate as any other feature work. I try to keep them separate from bugs because they are not bugs in software, but rather 'bugs' in communication. Perhaps the requirements criteria weren't clear, the acceptance test cases insufficient, or the developer just skimmed past a clearly defined and well-stated requirement. Either way, these things can be estimated, and should, and the estimates and actuals should be accounted for in your normal velocity calculation.

True bugs, however are things that aren't working the way you expected them to, and you aren't sure why, and you most likely aren't sure how long its going to take to fix it. When I've seen people give estimates for bug fixes in the past its either a complete guess that will be drastically over or under, or the more common is that they spend some untracked amount of time figuring out what the issue is, and then produce their 'estimate', but I contend that its the 'figuring out what the issue is' that needs to be tracked and accounted for, and is the un-estimatable component that can throw your iteration off.

I try to make this point in such black and white terms to defend against some common anit-patterns I see.

1. Missed requirements get called bugs, and the team doesn't measure the time it actually takes to resolve them, or adjust their velocity and relative point scale accordingly. (Imagine someone estimates it will take 2 days to complete feature X, and feature Y looks pretty similar, so they estimate 2 days for it as well. After 2 days feature X is 'done', but then there are several missed requirements and 'bugs' that take an additional 3 days to fix. Its critical to make sure that the estimate for feature Y is updated accordingly)

2. New Requirements get called bugs, which most of the time is just an honest misunderstanding, or it could be a more insidious attempt to cover up a communication problem, but when they are called bugs, they are often not treated in the same manner as other requirements (UI design, analysis, acceptance test definition, etc).

One my worst experiences with this was on a project where both the BA and QA resources had significant domain expertise, but disagreed on some implementation details. The QA person was unable to make their case during the requirements review, so they just waited until testing to say that there were several bugs, but in fact these bugs were variations on functionality that were not originally specified. On that project, only certain people could define and approve new functionality, but any bugs opened by the QA team were assumed to be top priority and didn't need to be reviewed or approved. (an extreme example I know, but it just points out the importance of making sure that you treat bugs as bugs, and requirements as requirements)

3. Planning to take care of 'all outstanding bugs' in the 'bug-fix iteration' as the final iteration at the end of the release. Here's where I'm really saying "you can't estimate bugs", and that it might be very dangerous to set the expectation that you can fix all of the issues in that iteration. What if it takes twice as long? What if fixing the bug causes more bugs?

You can't be so sure of these things, which is why I say you should plan for them differently.
1. Requirements disguised as bugs should be put in the backlog and prioritized and estimated as normal features (and figure out why they were missed)
2. Allocate a 'bucket' of time within each iteration to tackle bugs.
3. The stakeholders prioritize and define the expected behavior for bugs
4. The burndown chart for the bug fixing reflects the amount of time remaining in the bucket, and the amount of bugs left
5. When the time is all used up, the product owner has to make a decision for how best to utilize resources, either pull someone off of a feature to continue working on the bug, or hold off on the bug until the next iteration.

Now it might seem odd to stop working on a bug, but the reality is you have a fixed amount of time each iteration, and you have to leverage it as effectively as possible. The goal is to have fully testable and hopefully releaseable software at the end of the iteration so you can't leave a feature half-done. One way or the other you have to find a way to get it done. When you don't track the amount of time spent on bugs, you can end up short-changing your other features, which in turn can lead to more bugs.

Do you track time spent on bugs? (do you relate it back to the original estimate for that story?)
How do you estimate and plan for how long it will take to fix bugs?

(slightly unrelated) The recent client project I was on had 'Urgent' bugs that went back more than 90 days. Who is in charge of cleaning up bugs on your team? (are there any bugs more than 30 days old, and why?)

Bonus question: What would it take for your team to have a 'zero bug' policy? If at the end of every iteration there were no outstanding bugs?

Related posts:

1. Scrum defined in under 10 minutes
2. 800 on Your Math SAT, Software Development and Bugs
3. Estimating Bugs and the Complex Behavior of Simple Systems

There's more information in the case study on the Pathfinder web site, Sasha has written a related post on RubyAMF and Flex from the Flex perspective , and Justin has written one on Rails, AMF and Flex from the Rails perspective.

Related posts:

1. Flex Camp Chicago ‘09 Community Showcase Presentation Summary
2. Rails, AMF and Flex
3. Pathfinder releases version 1 of its Flash Platform microsite (codename Mica)

We recently launched a new Touch Screen Kiosk deployed in both Adobe Air and Flex. Touch Screen Kiosks pose some interesting usability challenges, some of which overlap with those for the iPhone. Take a look at a video demo or read the longer case study on the Pathfinder site.

Touch Screen Kiosk Demo

Related posts:

1. Adobe “Open Screen” is not “Open Source”
2. the iPhone and Touch screen technology
3. Hedge Fund Analytics in Flex

I've been spending some time with our internal sales and marketing team to hash out some of our goals for the year, and it became quite clear to me that non-developers are on their computers all day long facing some of the same technical challenges we do.

Some of the tasks they have to do:

• "take the data out of the spreadsheet for last quarter and compare it to this quarter"
• "gather the bounced emails from our newsletter posting, and update our list, pulling out duplicates"
• "replace all the names and addresses from our NDA agreement each time it is sent to a new client"
• "slice and dice google ad-words and google analytics data"

So I've resolved to take some time each week to 'Adopt a non-techie', and help them spend less time 'screwing around with the computer' and more time on the most valuable tasks they do.

In the same way that developers need to be as efficient as possible with the tools they use, so do the rest of the people at your company. At Pathfinder a good number of us have attended Neal Ford's Productive Programmer talks at the NofluffJustStuff conference, which covers a series of strategies for becoming extremely efficient as a developer. For those on our team that haven't attended the presentations, they pick up the best tricks through pairing and internal developer brownbags, but now I suggest we take the same approach with our business team.

While the benefits of having two developers pair on a technical task has been covered a million times, I would say it also applies to pairing with your UI designer, QA and BA resources as well. Whenever they need to take lots of text and reformat it, search/replace, etc, they might be tackling that problem manually, when you could help them solve it with a quick script or finding the plugin they need.

A few areas you might be able to help them with:

1. Forms and mail merge in word
2. Advanced searching and replacing in word
3. Google docs now has more powerful regular expression capabilities for searching and replacing (Actually, I could do a whole post on the benefits of getting your team to use GoogleDocs, would anyone be interested in that?)
4. Building a quick survey with google forms or surveymonkey
5. General text manipulation
6. Searching through all of their emails or local documents for anything related to the 'Jelly Belly vs. M&Ms' case
7. Excel spreadsheet manipulation, charts, etc.
8. Web searching and data extraction
9. Managing and sharing bookmarks and research data with others
10. Even tools like Selenium or iMacros could help your Business team automate repetitive form filling, web searching or web site testing.

Goals (First do no harm!):

1. Find the right problem. Just like we see in Product development, sometimes the most difficult problem is also the rarest, and not the best use of your time. In fact, the greatest area of efficiency is more likely to come from something they know how to do, but could be doing faster. (Instead of saving them 30mins off of a task they do twice a year, you might find something that saves 15mins every day!)
2. Don't expect them to become a developer. The goal is to reduce the time these things get in their way, so they can focus on the higher value stuff.
3. Make it easy for them to repeat the process (let them document it in their words, or even make a screencast while you're doing it)
4. Share your successes with the rest of the team (notes and screenshots/videos up on the wiki)

Use the right tools for the job!

While its best if you can help them to become more efficient with the tools they use everyday, you may find that they are just not using the right tool for the job, or if its a one-time thing, and you need to bring your toolkit with you.  For that I recommend a usb drive with your favorite PortableApps (notepad++ is great for text editing), or my new favorite PortableUbuntu (which lets you run linux off the usb drive, while accessing the files on the windows system)

What gets in your way?

To the business folks out there, what are some of the tasks you do to manipulate data? What frustrates you or eats up a lot of your time?

Reach out to your nearest techie, I bet they can help, or post your problem here and we'll make some recommendations.

Related posts:

1. Can your Selenium do that? Testing flash/flex and silverlight in web apps with iMacros
2. Stick with ERB or move to Haml
3. Does your project have Code Ownership Culture?

It's at 3pm, location and other information is available at their meetup.com site.

Looking forward to it -- see you there!

Related posts:

1. Why Chicago is Rails-town, USA
2. The Testing Interviews
3. Testing various roles in ruby on rails

Related posts:

1. The Blogs Have Moved
2. PureMVC, Spanning the Platform Spectrum?
3. Touch Screen Kiosk in Adobe Air