![]() |
Articles Feed |
Categories
Archives
- February 2010 (2)
- January 2010 (1)
- December 2009 (1)
- October 2009 (4)
- September 2009 (2)
- August 2009 (2)
- July 2009 (5)
- June 2009 (2)
- May 2009 (2)
- April 2009 (8)
- March 2009 (7)
- January 2009 (2)
- December 2008 (3)
- November 2008 (5)
- October 2008 (4)
- September 2008 (6)
- August 2008 (4)
- July 2008 (5)
- June 2008 (5)
- May 2008 (4)
- April 2008 (2)
- February 2008 (4)
- January 2008 (2)
- December 2007 (2)
- November 2007 (2)
- October 2007 (2)
- September 2007 (1)
- August 2007 (3)
- July 2007 (1)
- June 2007 (4)
- May 2007 (7)
- April 2007 (2)
- February 2007 (3)
- January 2007 (3)
- November 2006 (3)
- October 2006 (3)
- September 2006 (17)
- November 2004 (1)
Got Real?
by: | October 23rd, 2006 | 0 comments »
I heard about the Getting Real workshop from a good friend who is a web designer/developer. We used to talk some time ago about using the UI as a tool to drive the development and he told me I should go to the workshop if I could. I have to be honest, I didn’t know that much about 37signals and (you’re welcome to laugh) I didn’t know that one of the speakers was actually the creator of RubyOnRails.
A bit skeptic, I read a blog from somebody that participated in one of the workshops last year and my interest kept growing and growing. I told one of the company’s partners to give it a try and to my surprise he registered everybody for it. “The workshop better be good!” I said to myself.
So there we were, sitting down and waiting to see what these 37signals guys had to say. Right at the beginning of the presentation I learned that a businessman (Jason), a programmer (David) and a UI designer (Ryan) would be the speakers. It sounded like a success formula to me: it would not be about some nerds talking about adding the digit 2 in the 0-1 binary language; it would be about REAL-world professionals talking about REAL web/product development approached from diverse angles beyond the plain and traditional “bit-and-bytes” speech I am used to hear in that kind of activities.
What a way to start!
The speakers did a good job on keeping people interested while sharing without any hesitation the fruits of several years of pragmatic experience. Their advice was rich and wide: from how to integrate organically the layout and usability design with the programming endeavor using the application itself as a real “wireframe”; to business-oriented tips like how to hire the right people effectively. As an architect (on the traditional sense - building design!) it was refreshing to see Christopher Alexander “in-action” on some of their slides while talking about design patterns; and to hear about 37signals’ approach to Mies Van Der Rohe’s aphorism “less is more” applied to all aspects of the product development.
The workshop was great, definitely worth the time and investment and I have no hesitation recommending it to everyone that wants a more “holistic” and practical exposition to what software development should really be (if you want to Get Real!). A sincere “thank you” to the 37signals guys and to everyone there that helped to enrich the workshop with questions and comments.
Getting Real Review
by: micah | October 13th, 2006 | 1 comments »
This Monday my colleagues and I went to 37 Signals’ Getting Real workshop. Overall I give the workshop a thumbs up. They seem to be a good groups of guys.

from left to right: DHH, Gilberto Medrano, Paul Pagel, Jason Fried, Me
I’ll summarize by saying that the workshop is about how 37 Signals works. How they make decisions, how they build software, how they design software, and how they sell it. They were very candid about everything and that was refreshing.
At the end of it all, my colleagues and I begged the question: what did we learn? We all agreed that we didn’t really learn anything except that our philosophy is very similar theirs. However, there were a few points of contentions.
37 Signals builds their own software and they have a system that suits their purpose perfectly. 8th Light develops software for clients and that means we have to do things differently. One difference was acceptance tests. During the workshop, Gilberto asked what 37 Signals’ opinion was on FIT and acceptance tests. David (DHH) responded by saying that they don’t use or need acceptance tests because acceptance tests can’t capture the design and usability aspects of their software. I actually had this conversation with DHH a year back or so at a Ruby gathering in Chicago and he was of the same opinion. I agreed with him then and agree with him now. If I was building my own software and was essentially my own customer, I wouldn’t use acceptance tests either. But when building software for clients, acceptance tests become a critical tools for communication. Clients have expectations and no matter how many words they use or gestures they make, their intent does not become concrete until you put it down in an executable format. I would not dare to engage in a contract development arrangement with out acceptance tests.
There were a few other strategies that work for 37 Signals but wont work for 8th Light, such as hiring strategies and distributed workforce. Mostly this is based on 8th Light’s apprenticeship model.
If you get the chance to go to their workshop, check it out. And keep your eye on these guys. Their tools are pretty sharp and I trust they’ll impress us plenty more.
Craftsmen are like Babelfish
by: micah | October 2nd, 2006 | 2 comments »
Show me a software craftsmen and I’ll show you someone who can program in any language if they had to.
From time to time I meet developers who define themselves by the one and only programming language they know…. “I’m a Java developer”, “I’m a .NET developer”. It’s deplorable. I suspect such people don’t care much for their career.
Better are developers who can whip up code in multiple languages. Web developers, for example, often have to code in javascript in addition to the primary language whether it be Ruby, Java, or .NET. That’s respectable. Yet, many of these developers are intimidated by the notion of programming in some other language like C or C++. It’s a shame. There’s lot’s to learn from unfamiliar languages.
A Craftsman will not shy away from using the right language for the job. They understand that the act of programming is fundamentally the same despite the language being used. A craftsman is not intimidated by unfamiliar languages. When they’re confronted with a new language, they’ll learn it. After all, new programming languages are easy to learn.
#