Joel Splosky produced one of my new favourite all-time quotes:
“Shipping is a feature. A really important feature. Your product must have it.”
http://www.joelonsoftware.com/items/2009/09/23.html
Like Joel, I’m also reading Coders at Work. If you are in high-tech, you need to read this book. Some of the interviews are absolutely riveting. Seeing the stark contrast of coders who make products vs researchers who create theoretical work… and then the broad mix in-between… is pretty wild.
I have had the fortunate experience to work with some great coders in my life. The best I have ever worked with was a guy named Kevin Greer who works at a company called Redknee. He is somewhat folkloric-ally famous at the university we went to for building a compiler in Lisp. Kevin was a great coder because he balanced incredible architectural vision with raw coding output. In the pre-J2EE/framework era he built an incredible, telco grade framework used across the company in all of our products. Not only did he make this framework architecturally & theoretically brilliant, but he made it quickly, made it usable for 300+ coders and made it stable enough to be deployed with tier 1 wireless carriers globally. Plus he was a lot of fun to work with. Everything you could ever want in a coder.
Another great coder I’ve worked with is a guy named Vitaly Veksler. Vitaly is our primary developer here at Peek. He runs his own dev shop based in New York, www.webalgorithm.com. They are a small group of craftsmen developers who have been working with us since day 1, spending a lot of time onsite here helping us drive our technology forward. Vitaly is another classic example of pragmatic programming intertwined with architectural vision. Things need to be ‘clean’ so the program makes sense. Things also need to be able to scale without having to re-write everything. But more important than anything, the product needs to launch, it needs to ship on-time. Complexity kills that. Vitaly and his team balance that incredibly.
What I do find though is that the most architecturally savvy coders are usually the most productive. I actually know very few purely theoretical coders who get ’stuck’ in constant architectural re-writes of perfection. Good architects = good productive coders. I’ve never worked with the lab coat, theoretical, genius architect who produced incredible architecture who couldn’t produce tons of code with it.
And I find the converse true as well – not productive coders = bad architects. The least productive coders I know often fathom themselves good architects, but tend to suck at both. There is something to doing lots of coding that makes you want to be efficient about architecture. There’s also something to learning lots about architecture by shipping lots of products with different architectural patterns. Its called learning.
And, to throw in a tangent, that is why offshoring is a risky strategy. Offshore companies I have worked with have often created poor architectures and been far less productive. Team size tended to be 3-5x larger, therefore also requiring a lot more spend on management. The architecture and underlying technology choices tended to be poorer, leading to lots of bugs & software crashes, where you ultimately end up stuck in really long maintenance periods trying to fix things. In one scenario we were stuck with layer after layer of mis-used J2EE technology. 3-4 instances of basically the same beans, 2-3 DALs/persistence layers to the same table, it was a nightmare that made everything less productive. The worst case scenario all around.
I find from my anecdotal experience that the majority of the penultimate architecturally brilliant + pragmatically productive developers have been here. I am sure there are tons in other countries I just haven’t worked with, but right now I’ve had the ability to work with 5-10 amazing, world-class developers here, and 1 abroad (in India). And therefore they have hit the most important feature most often – shipping product.
