Tuesday, September 29, 2009
She's a brickhouse ...
I'm digging the idea of Sitebricks and plan to take it for a test drive this weekend. Maybe it'll reinvigorate my energy for web frameworks that has been exhausted by plethora of offerings out there, most of which seem pretty darn similar despite all their claims for uniqueness. Even if I love it, though, it's unlikely I'll see it much in the enterprise (where I tend to spend my daytime hours). Also, it would have to be pretty amazing - and different - for me to get over my anger a them for developing yet another web framework. My bookshelves are getting heavy (even my virtual bookshelves have a weight limit, measured more in the strain on my eyes and frontal lobe than mass).
Monday, September 21, 2009
Passive-Agressive Developer Personalities - which one are you?
If you don't follow Ted Zuiba's blog, I recommend you check it out. I love his sardonic sense of humor. He can be pretty brutal with this commentary. But, really, that's what's great about it. Also, he's got some pretty cogent advice.
As per usual, there's some interesting work afoot on the Agile Web Operations blog. The latest is a great one on development team motivation. Or rather, the supposition that development teams don't need motivation (they're already motivated when they come onboard, that's why they accepted the job offer). We simply need to actively stop de-motivating them. You might say this is just arguing semantics, but I think the difference in perspective is illuminating on many fronts. At its heart is the notion of developer as thinking individual who takes an active interesting in learning new things and advancing their capabilities. Developers who don't treat training as a 'let me just sit back and let the teacher wash this know-how over me' but rather 'this is a chance for me to learn - learning is the active verb here more so than teaching'. I think you want to weed the passive 'teach-me' types out of the organization in favor of the 'let-me-get-in-there-and-learn' sort.
But that's just me. If you disagree, perhaps we can start a developer exchange program.
As per usual, there's some interesting work afoot on the Agile Web Operations blog. The latest is a great one on development team motivation. Or rather, the supposition that development teams don't need motivation (they're already motivated when they come onboard, that's why they accepted the job offer). We simply need to actively stop de-motivating them. You might say this is just arguing semantics, but I think the difference in perspective is illuminating on many fronts. At its heart is the notion of developer as thinking individual who takes an active interesting in learning new things and advancing their capabilities. Developers who don't treat training as a 'let me just sit back and let the teacher wash this know-how over me' but rather 'this is a chance for me to learn - learning is the active verb here more so than teaching'. I think you want to weed the passive 'teach-me' types out of the organization in favor of the 'let-me-get-in-there-and-learn' sort.
But that's just me. If you disagree, perhaps we can start a developer exchange program.
Friday, September 4, 2009
The Spinning Continuous
Martin has posted another interesting musing on Feature Branching. It's particularly enlightening on its coverage of the thorny problems related to this practice with large scale concurrent (and sometimes conflicting) development - the Fear of the Big Merge - and how Continuous Integration can help.
Martin points out that the more recent Distributed Version Control Systems (DVCS) such as Git have largely solved the visibility and understanding of syntactical or textual differences when merging but they can't solve the semantic differences. And they aren't any help when refactorings have renamed, reshaped and morphed classes, methods, etc. The pain of the Big Merge make folks reluctant to do the refactoring necessary to keep the code clean and relatively free of technical debt.
Martin's answer: a variant on the old joke 'Doctor, it hurts when I do this.' 'So don't do that!'
If the Big Merge is painful, don't do the Big Merge. Do a continuous small merge and then when there are semantic uncertainties, communicate with the developer(s) working in that area. Use CI to do the small merges and use your voice and brain to do the communication part.
Simple, perhaps obvious advice - but the best kind usually is and it never hurts to hear it regularly.
Martin points out that the more recent Distributed Version Control Systems (DVCS) such as Git have largely solved the visibility and understanding of syntactical or textual differences when merging but they can't solve the semantic differences. And they aren't any help when refactorings have renamed, reshaped and morphed classes, methods, etc. The pain of the Big Merge make folks reluctant to do the refactoring necessary to keep the code clean and relatively free of technical debt.
Martin's answer: a variant on the old joke 'Doctor, it hurts when I do this.' 'So don't do that!'
If the Big Merge is painful, don't do the Big Merge. Do a continuous small merge and then when there are semantic uncertainties, communicate with the developer(s) working in that area. Use CI to do the small merges and use your voice and brain to do the communication part.
Simple, perhaps obvious advice - but the best kind usually is and it never hurts to hear it regularly.
It's not innocuous as it might seem but neither as competent as some might fear
Walmart's announcement that they are opening up their e-commerce platform to third party retailers with Walmart Marketplace seems a logical move, just given their ginormous operational capabilities. They'll likely not compete with Amazon in the cloud computing game any time soon (they're too much an old school brick and mortar outfit for that. But Retail as a Service (or the more general Process as a Service as some are calling it) is perhaps a much more lucrative biz and the old boys in Arkansas (or at least the young turks who have the old boys ear) are coming to understand this.
It's kind of scary but should be interesting to watch.
I guess I'm not as nervous as perhaps I should be simply because I'm guessing they have enough folks in the big seats in the executive bathrooms who are clueless when it comes to a business/technology marriage. And, more importantly, another group in the slightly smaller stalls with the slight less puffy TP who have just enough of a clue that they'll stumble around a good while before acquiring solid footing in this brave new world.
It's kind of scary but should be interesting to watch.
I guess I'm not as nervous as perhaps I should be simply because I'm guessing they have enough folks in the big seats in the executive bathrooms who are clueless when it comes to a business/technology marriage. And, more importantly, another group in the slightly smaller stalls with the slight less puffy TP who have just enough of a clue that they'll stumble around a good while before acquiring solid footing in this brave new world.
Subscribe to:
Posts (Atom)