Archives

photo credit: Felix Francier

I’ve been using Git for close to a year now, and I cannot remember what I did before it. I literally forget the process involved in doing certain things with subversion, cvs, and (shudder) vss. At first it was a bit of a struggle sure. The gui tools are somewhat lacking, but what is there is decent enough. I like Gitx a lot for what it does, but mainly I use it for partial commits, and visualization of a source tree. Being from windows land, and having used tortoise svn (a very very nice subversion client), it took me a bit to master the intricacies of the git command line interface. I still get into a little trouble from time to time. But it is all so very much worth it!

git branch my_new_toy

Seriously? That’s it? And it took less than a second? Why would I not branch ALL THE TIME. Wanna try something out? Branch it! Unsure that you’ll finish a feature in time for iteration end? Branch it! My pet project has 5 branches going right, all for little experiments and features that I’ve been slowly working on.

Feature branches have changed my workflow entirely. Every new feature I build, I create a branch for it. If it takes a while I merge from master to make sure I’m up to date.

git merge master

If we balk at the feature, or I want to go a different route with it, I can chuck it. If all goes which (which of course it always does), I merge it to master or whatever branch represents the latest greatest code.

git checkout master
git merge my_feature_branch

Once you get the hang of it you realize how simple and powerful it is. Every day I use it I’m continually amazed and thankful of how well it works and how drastically it improves my teams workflow.

Share/Bookmark

The midVentures LAUNCH event kicks off today with a day of innovation and product development workshops, followed by a full day of talks and over 50 product launches.

Pathfinder will be involved in two of those launches: Construction Punchlist, the development company’s brand new iPad app, and MORExchange, a direct to consumer mortgage aggregator built by Pathfinder for Omtelligence, LLC. The two are among the more than 50 new products to be introduced at the inaugural iteration of midVentures LAUNCH in Chicago.

Construction Punchlist brings the construction punchlist process into the digital realm by allowing architects and construction managers to carry hundreds of pages of building plans to a job site in the compact, rich media Apple iPad. Taking full advantage of the iPad’s multitouch graphic interface and its capacity to process and transmit information, this app enables users to scroll through, zoom in on and make detailed annotations directly on the digitized plans. Construction Punchlist can then send the marked up files to building owners and managers directly from the job site, saving time, energy and money.

MORExchange (www.morexchange.com), is a revolutionary web-based application whose mission is to provide the lowest cost, completely transparent mortgages for consumers. The application will allow consumers to see all available mortgage products at lender wholesale “par” interest rates (no margin or commission), and then apply for the mortgage with no application fee. The only cost to the consumer is a $750 transaction fee, which is not charged until the mortgage closes. This fee is the same for every loan no matter the size.

These two new products embody what midVentures LAUNCH is all about—innovative product development that’s happening in the Great Lakes right now. Although national luminaries from Google, Groupon, and IBM will be on hand to discuss their own success stories and today’s newest possibilities, the slant of the conference will be decidedly Midwestern.

Participation in midVentures LAUNCH reflects Pathfinder’s ongoing commitment to the region’s startup community, a community where Pathfinder has mentored and facilitated the launch of over 70 new products and companies in the last decade. As conference sponsor, exhibitor and launch participant, Pathfinder offers a view from the trenches, but it also has the unique perspective of having adapted strategies to help startups find success in both boom and lean times.

Workshops and panels at MidVentures LAUNCH reflect the same lean product strategies Pathfinder has been espousing for years, such as customer development before product development and agile software development. These are today’s pathways to success. They are also the longstanding hallmarks of Pathfinder’s approach to product development.

We hope to see you there.

Stay tuned for more new products – we’ve got six apps launching in the next month, including web and mobile apps for real estate, healthcare, and live music events.

Share/Bookmark

photo credit: the_moog

We develop digital products. Lots of them. So when I talk about things that are hard or easy to do, it’s based on hard won experience.

Two products that we’re about to help clients launch provide a perfect contrast on the two kinds of “hard” you find in software product development.

First we have a data visualization app that cranks through 72 million point datasets and cranks out 72 vector graphics surfaces, each with some 6000 curves comprised of a quarter million points. This is then displayed in real time to an expert audience of specialists via a highly responsive interface. We’ll call this one “dataviz.”

Second, we have a healthcare application that allows healthcare professionals to conduct a guided interview with a patient, both capturing information and educating them via feedback. We’ll call this one “interview.”

Share/Bookmark

Patherfinder Development’s CEO Bernhard Kappe shared one of the Tech Talks by Pivotal Labs, whose Pivotal Tracker tool is one we enjoy using. Pivotal Labs’ Ian McFarland, VP Technology, talked about the relationship between design and the agile process. In addressing “What is Enough Design?”, McFarland’s presentation raised themes often echoed in making software. Here are a few worth reinforcing:

Products are iterations
“The first draft is never the last,” as the saying goes. Even if your team is composed of prodigies, this doesn’t guarantee good results (such as episode five of the latest “Project Runway” season, in which a team comprised of the supposedly better-skilled fashion designers aimed for perfection, lost to the team marked “average”). Whether it’s called prototyping, drafting, or versioning, a product is the result of exploring different arrangements of elements, one iteration after another, until it’s judged fit by everyone who has a stake in making the product.

Bloat is counterproductive
A complement to “Iterate, iterate, iterate” is Henry David Thoreau expression, “Simplify, simplify, simplify.” It would be fascinating to see how Thoreau’s fierce lean way of living would translate to executing software. At Pathfinder Development, we strive for MVP, Minimum Viable Product. Software is additive. Think Microsoft Word, Adobe, or any on-the-shelf software, that keeps on adding features for the sake of adding them. When it comes to an initial software release—whatever the medium or platform—it’s easy to layer capability upon capability. The constant challenge: evolving the basics of why the application exists in the first place. The basics are the essential or core capabilities, not to be confused with the bell-and-whistle varietal.

Agile’s requirement is constant attention
A tenet of Ray and Charles Eames: “The details are the details. They make the design.” That’s because details defy scale. Button labeling and placement are equally important to how many lines of code are composed. Every detail participates in the experience of the product. Being “agile” is really vigilance to making the details work as well as possible at each step of the journey toward a shared destination—shared by project managers, designers, developers and the client.

These are tall themes. Before graphic designer and illustrator Milton Glaser said, “Just enough is more,” writer and aviator Antoine de Saint-Exupéry claimed, “A designer knows [she or he] has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.” Realizing “enough design” was never meant to be easy but worth pursuing and keeping at it.

Share/Bookmark

After working in ruby on rails for a number of years, I have found a number of performance related bottlenecks due to a lack of indexes on the database tables. I’ve noticed that most rails developers don’t write much SQL anymore, which is great, but also sometimes a problem. Back in the day, you really got your hands dirty in SQL, which made you really think of tuning the database. As relational databases are still around, I figured I’d give an overview on index basics.

I am going to summarize my findings here, and let those of you interested keep on reading through my empirical findings….

New Developer: When should I use an index?
Me: Any time the column appears in the WHERE, GROUP BY or ORDER BY clause.

Index Rules:
1. if you add a column for a belongs_to (like t.integer :user_id) for belongs_to :user – make sure there’s an index
2. if your column will appear in a WHERE, GROUP BY or ORDER BY clause
3. try to use composite indexes to reduce the amount of indexes needed.
4. other than that – wait until your app is up and running, and the use some performance tools to identify a need for other indexes.
5. Generally – use a full text search engine like solr or sphynx if you are getting into full text searching. Even if your database supports it, the SQL needed doesn’t work the same way on all database vendors.

Share/Bookmark

photo credit: Wootang01

The NYT had a very interesting article back on September 6th, entitled In a New Role, Teachers Move to Run Schools. I didn’t have time to blog about it, but wanted to come back to it  since it rang a lot of agile bells. The idea is that teachers, rather than principals, make decisions about how to run a school.

Hmmm, self organizing teams, continuous improvement, motivated teachers? Sound a little like agile.

From the article you’re seeing some things in this Newark school that you’d consider unlikely to happen in a more traditionally run school: longer school days, teacher crafted curriculum, teacher budget governance. Self organization leads to greater motivation and job satisfaction. As one teacher put it, “This is a fantasy. It’s six passionate people who came together and said, ‘Enough is enough.’ We’re just tired of seeing failure.”

Share/Bookmark

When starting a new project, we employ a technique we call Inception.  At a high level, the goal of Inception is to develop a shared vision for the project, come up with an initial scope (user story list), provide an updated estimate, and identify areas of risk.

A pitfall that is challenging to avoid is getting stuck in analysis paralysis.  Our customers love to dig into the details of how each story could work.  Our designers are chomping at the bit to get creative on the whole user experience.  The developers are, quite naturally, afraid to estimate with only a story phrase and discussion to go on.

So how do we balance the tension between the desire for ever increasing levels of detail and getting thru with initiating the project and onto the value-added activity of building the product?

First, we get the whole team on board with what the goals of inception are (as stated above)…and equally important, what they’re not.  The goal of inception is NOT to gather all the requirements nor is it to design the whole UI.

Next, we use the many of the same organizing practices and rituals we use during development: time-boxing, daily stand-ups, retrospectives, a backlog, etc.

I think time-boxing is probably the key to avoiding the analysis paralysis trap.  For example, let say we’re going to determine the scope of the admin portion of an application.  We might schedule one or two 1.5 hours workshops with the goal of mocking up a UI and culling a reasonably thorough story list.  With a strong, experienced facilitator, we complete the analysis in the time allotted.

It can be a bit scary and uncomfortable.  We will have missed requirements and when it comes to estimating, some of our assumptions will be correct, while other will prove to be wrong.  But we will get started building software and the customer will start to see their dreams coming to fruition…..and we all learn and adapt along the way.

Share/Bookmark

Photo by Rob Lambert

Many from Pathfinder Development, a sponsor, attended this year’s Windy City Rails conference. ROR is one of many staple development languages here. Another language is that shared by the information architects and visual designers. In contrast to the developer’s language of code and software frameworks is the designer’s language of typography and information visualization. One session that piqued my interest was by Ryan Singer, Product Manager and Lead UI Designer at 37signals. He talked about “Weaving Design and Development”. Sharing this post is fellow Product Designer Robert Walsh who will also give his thoughts on Singer’s presentation.

What were the memorable takeaways?

Nate: Singer was gracious to spend some time afterwards. Connecting to one of the points in his presentation about designer and developers starting early, at the same, I told him that seeing working software at the get-go (or should I say “git-go”) is a sensation. Making ideas for an interface, no matter the fidelity, is great. But grounding the sketches, the wireframes, and translating them into a live iterative interface that’s interactive in a browser, on a mobile device, is huge. Designers having direct access to developers, and vice versa, helps a lot. It promotes proactive feedback, even continuous feedback—As Singer put it, “Realizing that something sucks and make it better.” This way, designers and developers escape flatland, from sketch to screen, together.

Robert: An underlying theme of his presentation, that I don’t think became explicit until the question and answer session, was that Singer had entered the ongoing debate about the necessary capabilities of web designers. To him, a designer should be able to work in the view templates throughout the life of the application. Therefore, the designer should be writing the HAML or ERB, CSS or SASS, and be in Terminal constantly pulling and pushing to GIT. I also noticed that it surprised the programmers in the room when he added that a designer should be comfortable working in Rails enough to write small snippets of Ruby in a view or create a helper when necessary.

I spoke with him after the session and I get the impression that he is of the population that thinks in the next 5–10 years or so there will be a generation of designers who grew up designing for the web and these will be the strengths that they have picked up over time by just being active creative citizens of the web.

What about the presentation’s style?

Robert: I thought that his opening story—while obedient to the practice of opening with an emotionally gripping story—was long-winded. The ‘aha’ moment comes at the end of the story and I think the fact that he took so long to get there kept the energy low initially.

More so, regarding style, his content and delivery were textbook “37 Signals iconoclasm.” As a designer, he had no reservations at bluntly saying HAML was unnecessary (to which a wash of gasps covered the room) or other things that seemed to go against popular opinion. Namely, the role of the designer in the process of creating a web application.

Photo by Nate Burgos

Nate: It was refreshing to see live digital sketching (above) to illustrate Singer’s lecture. With the black backdrop serving white and red strokes, I thought they were using their iPad app Draft but turned out to be a large canvas, perhaps Photoshop. The overhead projector has become more extinct. And starting a presentation with a relevant story is always a good method to gel all the key talking points, as long as the story is relevant, and even better when it has humor as Singer did in his telling.

In closure, when it comes to language, designers and developers work their native way of making something. Their respective languages can collide but they converge toward accomplishing a shared goal: a good product to help bring a good experience to people.

Share/Bookmark

Cross-platform, the promise of internet standards. Well, sure with enough [if IE] statements!  With so many browsers and OSs around, everything needs to be tested hands on – there are no guaranties in this fast changing environment.

Like most developers, I work on a single machine and I can be at the office, at home and where ever there’s an internet connection. I find it a great hurdle to lug around additional OS images and to have to configure a new one every couple of months. I also find it a significant expense for a company to maintain all the posible VM environments just for testing.

Some good people have taken up this problem and since I found out about them I haven’t looked back.

Share/Bookmark

Brianna Sylver, Founder and President of innovation research and strategy firm Sylver Consulting, engages a lego sprint with her team. Photo by Nate Burgos

The lego blocks returned with gusto, in greater numbers and colors. This time, the participants were members of ChiPMA, the Chicago Product Managers Association. The group of thirty-three were divided into five groups. Each acted as a dedicated team responsible for developing and delivering the product, in this case, an animal with enclosure. Before going through three quick rounds of energetic lego shuffling and assembling, the group estimated and prioritized user stories and consulted with their product owners, played by members of the Pathfinder Development team.

Pathfinder’s Sr. Agile Project Manager/Coach Glenn Bernsohn led the practical session demonstrating the rhythm of an agile project. ChiPMA participants learned firsthand a number of its key concepts like Iterations, Testing, Velocity and Retrospectives.

As ChiPMA member Tim Perry put it, “Was a really fun game. Great way to meet new people and learn more about agile in a ‘non classroom’ setting.”

See the rest of the lego fun-charged pictures (slide show).

For more lego exploits, see our previous post about the game played by members of the Chicago Agile Project Management Meetup Group.

Share/Bookmark