We finally got around to putting up a forum a forum for BMC Performance Manager SDK (the product I work on) on BMC’s developer chat site, devcon.bmc.com.
So, if you’re a BMC Performance Manager SDK developer and you want a place to hang out, there it is: come on over with any questions, suggestions, or anything in having to do with the SDK.
Whenever you move files around in CVS, you loose the history associated with that file. People tend to get upset about this; though, on the projects I’ve worked on, we’ve moved stuff around every release, loosing history, and it’s never killed us. No one really raised a peep. For the most part, people just want to use it when they’re in that “what fucking idiot put wrote this bug!” mode at 3AM in the morning…
Nonetheless! Thanks to a recommendation from The JC, I found this helpful tidbit in Open Source Development with CVS:
I Need to Move Files around without Losing Revision History.
In the repository, copy (don’t move) the RCS files to the desired new location in the project.
They must remain in their old locations as well.Then, in a working copy, do:
yarkon$ rm oldfile1 oldfile2 ... yarkon$ cvs remove oldfile1 oldfile2 ... yarkon$ cvs commit -m "removed from here" oldfile1 oldfile2 ...
When people do updates after that, CVS correctly removes the old files and brings the new
files into the working copies just as though they had been added to the repository in the usual
way (except that they’ll be at unusually high revision numbers for supposedly new files).
So, there you have it: one of the big “CVS sucks!” bullet points resolved. I’ll see how easy that is to actually do. Anyone else ever do this?
(And yes, I know this would be easier in subversion. You know who you are!)
Kim put up some of our old, no longer fits, furniture for sale on craigslist. So, if you want a bookcase, a comfy chair, a glass table and chairs, or a swanky 1960′s cabinet stereo, check out the listing on craigslist; the stero has it’s own listing.
“Anyway, silence is just as important as organized sound. Wouldn’t you agree Señior Muñoz?”
For once, Muñoz was in agreement.”
“Absolutely,” he remarked with renewed interest. “I think it’s rather like photographic negatives. The background, which has apparently not been exposed, contains information too. Is that what happens with Bach?”
Of course. Bach uses negative spaces, silences are as eloquent as notes, tempi and syncopations. Do you cultiate the stuff of empty spaces within your logical systems?”
“Naturally. It’s like changing your point of view. Sometimes it’s like looking at a garden which, when viewed from one place, has no apparent order, but which, viewed from another perspective, is laid out with geometric regularity.”
“I’m afraid,” said Alfonso, giving them a mocking look, “it’s too early in the day for me to cope iwht such scientific talk.” He got up and walked over the bar. “A drink anyone?”
–From The Flanders Panel
I’m pretty much burned out on reading about Agile software development. I spent 2-3 years rabidly reading about it, and now that we’ve been applying it at The Day Job, I’m more interested in solutions and improvements to specific problems and processes I encounter. So the generalized stuff and platitudes you find out there gets to be repetitive and not immediately applicable.
That aside, I liked this post entitled “Application Integration and Agility (1): Understanding Agility” because it wove together Agile think very tightly with Lean think, e.g.:
[T]he core of waste in software comes from the traditional approaches to project management.
…
[As one example:] Tighter scope controls convert the “change control boards” into change prevention boards. And oftentimes teams deliver “to the scope” and not to the real business need, producing useless products that need substantial time to be augmented with functionality that is actually needed.
That is, adding extra process to slow down change can be wasteful because it produced software that (a.) the customer doesn’t want and, worse, (b.) that requires lots of work to make worthwhile.
The first items is the core of what it means to be Lean: you produce only what the customer wants. While the second is a consequence of what you might call The Grand Mistake of Agile Software Development Practitioners: the sense of immediacy and minimalism in delivering “only what the customer wants” often causes you to create software that is not flexible, nor easy to change.
That is, despite what the phrase “deliver only what the customer wants” seems to imply, you do need to think of the future: customers always want more, and they want their software to be quickly modifiable to get that more. They just don’t know they want that until it’s too late. Part of being a good software developer — or any service job — is giving the customer what they don’t know they want. Put another way: the customer is rarely 100% right or complete, where “complete” means “can give you a list of every single thing they want.”
At the moment, my cure-all for all woes of applying Agile boils down to the well-worn Agile precept: small groups of people, all jammed into one room have the best chance, out of all project management strategies, of creating great software. Really, this practice is what you might call a “theory grandchild” of my favorite project management “law,” Conway’s Law, the conclusions of which point towards having as little hierarchy and lines of communication as possible…assuming you want to produce simple, elegant software. (As an aside, those two things are easy to loose track of when you focus on the naive understanding of “deliver only what the customer wants.”)
Sadly, the legacy world of plan-driven, people-heavy, product-based/shrink-wrap software we exist in is effectively anathema to small groups of people in one room. It’s an odd thing that.
As an industry, our prime hope is that The People Who Decide start looking to Google as a successful, new way of doing software development. If old GOOG can stay in the $100′s long enough, it just might stick. Otherwise, it’ll just be a flash in the pan, and we’ll stick with the boring, wasteful ways of developing software. Customers will continue to be “happy” because nothing better exists. The bears will dance!
(With Yahoo!’s last few acquisitions and partnerships with small software development shops, the old Y! might be a beacon of project management hope as well. We’ll have to see.)
So, yes, check the post, it has a refreshing interlacing of Lean and Agile.
And if you figure out how to disrupt the boring, legacy way of doing things, drop us a comment below.
Since I have 4 podcasts now, I thought I’d start up a page to list them all. So, here’s the list of all the podcasts.
For quite some time now, I’ve enjoyed listening to and creating podcasts. Podcasts, of course, are self-produced shows in MP3 format that you can listen to on your computer, iPod, burn to CD, or anywhere that can transmit the audio to your ears. There’s plenty more explanations of the word “podcast”out there if you’re interested. The point of this page is to simply list all the podcasts that I’m involved in. Here’s the list:
The first podcast with my friend Charles Lowell and the occasional guests. We mostly talk about programming and other dorky and tech things. But, mixed in a fine dose of little boy and geek humor.
An audio only version of the feed is available.
The (usually) weekly podcast about the software industry from RedMonk‘s view. I do this podcast with the two partners in my industry analyst firm, Steve O’Grady and James Governor.
I do several podcasts at RedMonk, including RIA Weekly and the IT Management Podcast. All are included in the RedMonk Radio feed. Also, check out the videos on RedMonkTV.
My wife Kim and I do a more or less weekly podcast on, you know, nothing in particular. We simply talk about what’s been going on recently. Occasionally, we do video versions or may do specials about things around town, like Domy books.
Each of the episodes in “Stories” are just little things I record here and there, sometime with my wife, sometimes myself, or other people.
Back in 2005, I split off some extra material to a podcast I called “Gravy.” For whatever reason, I started another one recently called “Stories.” The two are now merged. If you’d like to get the first 8 Grady episodes, they’re available in this old feed.
Tips and advice for out-of-its like myself. That is, how to be more like an adult and less like a dark-room dwelling computer dweeb.
A podcast of other podcasts and audio that I liked. When I heard a podcast I think is pretty good, I tag it in del.icio.us with podcast4u. So, if yo subscribe to this feed, you’ll get an earful of audio that I recommend.
Kim and I recorded the first episode of the Austin Nag podcast this morning. We’re going through the list of tips she wrote up last year. There’s some good ones in there for out-of-its like myself.
This week, I explain why Charles hasn’t been around for the past 3 weeks. I talk briefly about Austin Nag, our new group-blog with “daily coping tips for people who lead busy (or lazy) lives.” Also, for your listening pleasure, I recommend some other podcasts I’ve been enjoying:
And, the lovely Kim Skotak fills us in on some late breaking Charles news.
(This episode edited by Coté)
No, I’m not resigning from anything: I just had a pestering question about resignation emails. You know ‘em, the email that begins, “Finirus P. Wazdoodle has decided to move on bigger and greater things. His responsibilities will be taken over by Baron von Dishwasher. The king is dead, long live the king!”
What’s always dumb about these emails is that they never tell you where the people are going: what new job they got. I’m not quite sure why the company is reluctant to say: is it shame at loosing them? Some legal thing? Just an omission? (That last one is the “easy out” answer.)
As I’ve said several times, I’m big on transparency and open-ness as valuable process investments with big-ass pay-outs. So, “weird” things like this always pic my interest.
Need some email etiquette tips? Try Send: The Essential Guide to Email for Office and Home
