- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
“Build half a product, not a half-assed product” - tips on clarity and focus from Jason Fried of 37Signals
Jason Fried from 37Signals spoke yesterday at the ITA "Speaking of Success" event, about the history of 37Signals, their philosophy and culture, and the critical business decisions they've made to get them where they are today.
The software biz is fundamentally broken. Too many products fail because of the obsession of adding more and more, and trying to do too much.
Jason went on to say that the approach of adding more and more only works for companies that have lots of money and lots of time, but that for the average company the main goal should be to build something that is "good enough," get it out to the users, and improve the design based on their feedback. The challenge of which features to include, and which to say "No" to, is covered well in the "The Innovator's Dilemma," which he said "everyone in this room should have read." The book resonates the core philosophy of 37Signals, which is evident from their blogs, their book "Getting Real," and the design of the Rails framework. As an example of the "Good Enough" philosophy, Jason used his laptop and its basic webcam to stream the Q&A session out over justin.tv and send out a text to the 37signals Twitter group. "The quality probably isn't that great, but its good enough," and with that quick setup he had now broadened the audience by 1,000 users or so. (I searched for the video archive at justin.tv, but didn't find it yet.)
jQuery + Rails + Agile: PlantCollections database project now live
After just three weeks of frantic work, my team today released the first public version of PlantCollections, a joint venture of the Chicago Botanic Garden and 29 academic and corporate partners.
Our app serves as the consumer-facing front end for a Google Base collection of plant specimen data compiled by scientists and gardeners all over the world. This project represents my first experience with Ruby on Rails and Pathfinder's first experience progressively enhancing a Rails app with jQuery. Although this is still little more than a prototype, with lots of additional functionality to come, we're pleased that this first release is already out in the wild. Go, agile, go!
To learn more about PlantCollections and our involvement in the project, check out the press release. Otherwise, just head straight to the application itself.
Testing
Well, actually, the Design Team disguised as the QA Team.
The little frustrations, system and function failures result in a lot of dog-kicking, huge antacid and alcohol intake and a lot of whining. I begin to understand how little-person tossing may have started down under a few years ago. Obviously QA Teams at the pub got this trend started.
The academics have broken testing up into five or six TLAs (Three Letter Abbreviations designed by Consultants so they can charge more and use more buzzwords than normal people). You got your UAT (User Acceptance Test), your Unit Test, your Sanity Check, your boundary test, your Automated Regressive and Non-automated Regressive series (this means high school kids who click and chew gum while re-Ghosting machines) and on and on.
These labels are obviously created by people who don't do testing.
Us testers use language you shouldn't put on a blog.
This blog started because I had to do a complicated test three times today before I got the dang thing right.
I wrote the test script, had to change it four times because it wasn't really testing what I wanted it to test when I was writing it yesterday. Funny thing. I had the developer who created the function look it over for me. He said it was fine.
But each of those rewrites was one to three new database entries.
When I had it right and came to the end of the second phase of the three part test... the application didn't do what I wanted it to do. Totally unrelated to the test. ARGH!
I know.
You've been there, done that and have the tee-shirt.
Come to think about it, Our PM owes me a tee-shirt. 3XL, Ron, I've lost 45 pounds since 4/4.
Before I threw my laptop at the wall, I calmed myself by repeating the Tester's Mantra: If I didn't find it, the Client would.
The thing is, I don't mind writing Test Cases or even test scripts. I find writing them an interesting challenge. I also find doing them drudgery, akin to the constitutional prohibition against cruel and unusual punishment.
I wish I could get into the spirit of a real QA guy who thinks about these tests creatively and with wild abandon. You know, the fellow or gal who can think like a crazed end user ready to pounce on my poor application with abandon and relish.
Such folks are a treasure.
But with a small team, the lack budget for QA resources and the need to test major functionalities of a complex application, we Business Analysts, Information Architects, Project Managers and Receptionists will continue to click, type, spell check and screen capture.
And moan, groan and whine.
But it's gotta get done.
Oh, for the days when the BA and QA Lead managed the process and others did the work...
Topics: agile, Pair Programming, process Web/Tech, Requirements
Another Way to Pair Program: Generating Requirements
The CTO (Chief Technical Officer) tells the BA (Business Analyst- me) and the IA (Information Architect) to pair program.
He's our boss' boss.
He's our Agile ubermensch (mensch is a Yiddish-Middle German word meaning, in this context, expert, coach, guide, all around super star; I don't know if it is in Modern German, but our CTO will tell me, he's fluent in German. I took Latin and Spanish).
We gotta do what he says.
I whine that I write faster than the IA.
The IA complains I can't do wireframes as fast as he does (true, VISIO isn't as easy as it looks, kids).
We are despondent and snarl at each other. Pitiful.
An idea.
How about we split the requirements in half. I pull the ones I wanna do, the IA grabs the more visually oriented ones. We write 'em up, do the wireframes and then have the other edit and comment on the other's work while we collaborate on the items we need to.
It allowed me to spit out the bug repairs like a machine gun and freed our IA into drafting wireframes and workflows he needed to do without slowing me down. While we edit the other fellow's stuff, we find small errors, ask some questions and significantly improve the requirements without turning them into novels.
The benefit was to the Developers who had very spiffy, concrete, succinct and directed requirements before the iteration started. They had time to read them, ask questions and begin their design work. The client was able to read them and sign off early making the sprint kick-off run smoothly.
The CTO gave his blessing.
And yeah, I started numbering the dang Business Rules to help the Developers, even though everything I ever learned about writing tells me non-hierarchal/unrelated lists should be bulleted. But it helps the developers refer to specific rules and my sense of technical writing dos and don'ts can suffer this arrow of outrageous fortune.
The Developers were not impressed. They like numbers. Especially ones with decimal points.
Turns out the PM (Project Manager) even likes the IBM-concentric deep diving numbering schemes of the 1970s. There's no accounting for taste, is there?
But I don't have to like it, do I?
Topics: agile, Pair Programming, process Web/Tech, Requirements
About Pathfinder
Recent
- Making GWT JSON not Quite so Painful
- IDEA - preconference workshop 06 Oct 08
- HTML5, Ajax history management, and The Ajax Experience 2008 Boston
- A Look Back At Past Posts
- Flash Player on iPhone gossip
- Microsoft to Jump on Board EC2
- TAE Boston 2008: The Unsexy Presentations
- The Ajax Experience 2008: Hope to see you in Beantown
- TankEngine: New plugin for Rails iPhone Development
- Symphony of Ruby on Rails and Flex through RubyAMF
Archives
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006


