Real Time Software Development

New PodCast - Download it here.

And now the explanation ...

Right now I have article ideas coming out of my ears, and no time to write them down. If I _try_ to write them down on index cards, then in six months I will have a bunch of unreadable index cards. If I try to write them in Microsoft word, I will end up staying up all right, writing a few of them.

No, what I need is a good way to save the context of the idea onto the stack, and perhaps retrieve it later.

To that end, Sean McMillan and I have recorded a brief (14 minute/12MB) podcast that dicusses one of those ideas - Real Time Software Development.

Please let me know what you think of this format; we view it as an experiment. If the format proves popular enough, I may record and stream other presentations on the podcast.

If you have iTunes, you can subscribe to the podcast here. If you are a regular creative chaos reader, don't worry about it; all episodes are posted right here, so you don't need iTunes to get your fix.

Also, I have switched web-hosting for www.xndev.com and related media files to GoDaddy; if you have any problems with your downloads, please let me know.

Upcoming Workshop

I will be running a small private workshop next month - about public speaking - for new speakers.

That's right; I am giving a talk on how to give a talk.

If you are interested in a pilot or peer review, shoot me an email.

Indy Trip Report

Last month I made it out to Indianapolis for a meeting of the Indianapolis QA Association and a short course on software requirements. Sadly, I tried to make the event a working vacation, which meant I had not quite enough time to spend with technologists, yet also not enough time to really spend with my family.

A couple highlights -

1) The slides from my talk on process improvement are available online. If you open the document in powerpoint, you will see detailed (if not proof-read) lecture notes in the notes window.

2) I got the chance to meet some interesting people from Liberty Mutual, including David Christiansen. Apparently, David liked my talk enough to quote me; that's always a good sign. David also runs the blog site The Tech Darkside, which has some good material on it.

All told, it was a good trip. The requirements class was a bit too big for one facilitator (33 people), and this slowed down the general pace. In the future, I will either hold the line on attendance or bring in a second facilitator.

Actual E-Mail - II

I've been carefully re-reading that email, and it is not as bad as I initially thought. Actually, it makes very few over-the-top promises. Only one sentence really sticks out at me:


The CMMI is appropriate for organizations off all sizes whether Agile or Waterfall, engineering or IT, embedded or workstation, internal or external

This pre-supposes that all companies can always benefit from a single, universal model for process improvement. This means that dotCom companies, military defense contractors, Pepsi, Apple, and medical equipment manufacturers should all be climbing the same ladder.

And, to quote Renee Bullock, I reply:

Bull Pucky.

The CMMI is a model. Like every other model, it is imperfect. In fact, the CMMI is just a big list of best practices made up of a bunch of smart guys. Here is Matt Heusser's sloppy, cheap version of CMMI 3 in a nutshell:

1) You should have a defined way of doing everything. And actually do it that way.

2) You should know what you are building before you build it. (Requirements)

3) And, since the requirements will change, have a defined way to accept change.

4) You need to have a reason for believing how long things will take before you do
them. One term for this is 'planning' -> as in, all projects should have a plan.

5) The intermediate thingees in software development - plans, designs, tests, whatever - these are work products. Everyone needs to have artifacts to show that the work was actually done.

6) All these artifacts need to be placed under Configuration Management. (This is basically version control that should be able to recall the complete work product set at a given point in time, plus some labels.)

7) Every work product needs to be reviewed and/or audited, both by technical people (peers) and by management

8) You should have a change process for your processes, that is defined, placed under version control, reviewed, and so on.

9) Metrics are good. (At the higher levels, metrics are great. At the highest levels, and we thank them for our food.)


-------> I think that's most of the philosophy behind the CMMI. Now, a good CMMI-er will point out that these things are not required; for the CMMI, you just have to point out that the GOALS for each key process area are covered. For example, level 3 requires outsource management - you could just tell the assessor "We don't outsource development, so we don't need policies to manage outsourced projects."

Or, in theory, with some of the more wild work product requirements of the CMMI, you could go back to the goals and say "We don't have the problems that this key process area is designed to address."

So yes, there are Assessor's like Hillel that will work with your team to do figure out what you really need - but that's despite of theCMMI, not because of it.

The CMMI instills a value system, and it's about comprehensive documentation. If you think I'm kidding, download it and print it out. (And that's just the MODEL; try reading the SCAMPI appraiser's manual some time.)

The Agile Manifesto has a value system, that is about working software.

Putting the two together is possible; you can ask questions like "What is the minimum about of documentation I can give to satisfy the CMMI requirements? What is just enough process, just enough documentation, just enough auditing and compliance work?"

Insisting that all companies could benefit from CMMI? From a collection of best practices made by a bunch of humans with no real statstical evidence?

Now I'm going to Quote my roomate Mike from Salisbury University:

"Whatever, Dude"

POST-SCRIPT: The CMMI doc is something like 600 pages long. My assertion is that a organization that follows my sloppy, nine-point list above could probably be rated level three. If not, it would only take a half-dozen more bullet points, at most. The _REASON_ the CMMI is 600 pages long is not because it's inherently complex - it is, actually, surprisingly naive. It's about the value system inherent in the docs.

You can call that agile, er, I guess.

Whatever, Dude.

Actual E-Mail - I

This is a forward from an actual email I got today. It's a literal email; it is a cut and paste. If you could, please, write in a few comments. I will have a short response next week ...

“The Secrets of CMMI for Small Companies”

As the CMMI gains popularity and acceptance across the globe, many smaller IT and Engineering organizations feel left out. Not only do they want to leverage the model for process improvement, but many of their customers are asking them to reach CMMI Maturity Level two or even level three!

There is a perception in the software industry that the Capability Maturity Model Integration is only for large scale software development in the defense, aerospace, and pharmaceutical verticals.

This just isn’t true!

The CMMI is appropriate for organizations off all sizes whether Agile or Waterfall, engineering or IT, embedded or workstation, internal or external. The key to success isn’t “what” is in the model, but “how” it is interpreted and used.

Join Jeff Dalton, President of Broadsword, SCAMPI Lead Appraiser, CMMI Instructor, author, and software engineer as he explodes the myths about CMMI (yes, it’s Agile), about process deployment (no, it doesn’t take extra time), and management sponsorship (yes, the have to change too).

Excerpted from the content of his book, “Agile CMMI,” Jeff will discuss practical real-world approaches to CMMI adoption and organizational change with ideas that you can use today to make your process initiative more successful.

A Testing Fairy Tale

I found a link to this on Pradeep Soundararajan's Blog; it is a story by Jerry Weinberg about software testing.

Here's the article - Test Trimming: A Fable About Testing

The post-script at the end is absolutely amazing.

Whew!

I just finished my first complete, pre-publication technical book review for Addison-Wesley. Ugh. Twenty-Eight chapters in a little over a week.

Well, it was certainly an adventure, and one of the bigger items on my list is now gone.

The book by Jim Brosseau has a working title of "Taking Ownership." I was particularly struck by chapter 15 - "Guidance." Specifically, in this chapter Jim discusses the benefits of norms, policies, and standards in software process.

Long time (ok, short time) fan of Creative Chaos will note that I am, well, not really a big fan of stable, repeatable processes. In fact, over the weekend I was mulling an article about the damage that the cult of repeatability is doing to our craft.

So, you can assume that when I read chapter 15, I had my red pen out, ready to slash.

Then Jim did something interesting: He made some fine points. I enjoyed the chapter, and came away with a more moderated opinion on the subject.

But enough about what I think; I am interested in what you think. So I have arranged with Jim to have that chapter available on Creative Chaos for free.

So, if you have a few moments to spare, please feel free to follow the link and take a look.

Note: I am about to switch webhosts; if you can't find the file, I'm probably working on it.

If you are really ambitious, this is your chance to tell AWL how you really feel; you can leave comments or email me. If there is enough interest, I could turn this into a short series.

Or don't. It's just a couple of pages; I thought it was interesting, wanted to share, and Jim was agreeable.

And with that off the stack, I can finally start focusing on lighting talks ...

Way Over Book-ed ...

I know, the past few months haven't provided the typical Creative Chaos output.

So, here's what I have been doing -

1) Evaluating Submissions for Lightning Talks at STAREast this year - which I hope to announce this week.
2) Preparing for a private workshop in Orlando, in May,
3) Working on a pre-publication book review for Addison-Wesley,
4) Trying to get around to doing the review of Brian Marick's Everyday Scripting with Ruby,
5) Lining up Keynote Speakers and Tutorial Speakers for GLSEC 2007. No, recruiting high-level speakers is not all glory; there is a lot of nagging and contracts involved. Though it is, mostly glory ...
6) Working on lining up sponsors for GLSEC 2007. This mostly consists of asking polietly, with the ocassional grovelling. I am sad to say, this one is not glory at all. And no, I don't make a dime on GLSEC, it, plus the local perl user's group, are my big volunteer work for the industry.
7) Trying to do any writing at all. I think the testing challenge of a few weeks back could be published, if only I would ever get off my duff.
8) www.xndev.com will lose it's web host next week. Find a new one.
9) In my free time, I need to get started on my 2008 speaking schedule

Then there's the kids, family, Church, knights of columbus, and the real work that lets me do this fun stuff. Oh, and something about colored eggs or a bunny or something.

It's been a whirl.

So, for this month, I have scaled back Creative Chaos, and, yes, this week I am scaling back my regular exercise routine to get some things knocked off that list.

Next on my to-do list: Learn to evaluate opportunities in light of what I can actually accomplish ...

Sigh.

One thing you can say about being overbooked: It ain't boring ...

Magazines?

Despite the emergence of blogging, I still like to pick up and read technology magazines now and again. This can be a bit of a challenge, as there are a lot of technology magazines, and many of them are free, advertiser supported.

Not only do you get what you pay for (some of the freebie mags are pretty bad), but it's worse - time you spent reading bad magazines could be spent on something more valuable. In other words, reading trade rags can have a real opportunity cost - you can, in effect, "lose" time and money on those freebies.

Which brings me to this: Which magazines do I read, why, and what is my technique for telling them apart?

My technique is pretty simple. I have two questions:

1) Would I actually fork over any real money to subscribe to this magazine?
2) How I know/respect the people who run these magazines?

That said, here are a few that pass the test:

A) Better Software Magazine(*)

I actually paid for this, back when it was Software Testing and Quality Engineering Lee Copeland is the editor-in-chief of BSW, and Google recently flew him out to do a tech talk on metrics and proving the value of testing - you can watch it here. In that talk, Lee openly admits that there is no truly accepted definition for testing, and describes several bogus metrics. The magazine attempts to appeal to a wide audience - testers, devs, managers - and it seems a little watered down. Still, I get quite a bit out of the editorials, and the writing is a notch or two above the typical trade rag. You can apply for a free subscription to BetterSoftware here.


B) Software Test&Performance Magazine (*)

I haven't met the principals at BZMedia, but I do enjoy ST&P. Rob Sabourin and Mike Kelly are two regular writers for ST&P, and Scott Barber had a long-running editorial series that was worth my time in and of itself. You can apply for a free subscription here. The editorial coverage seems to be moving toward developers, developer-tools, and Java/jUnit, but I still see something interesting in every issue.


C) Inc. Magazine

The magazine for small business. Even though it's not really a technology magazine, I find that I devour every issue of Inc. The magazine is inspiring, and the writing, my goodness, the writing is excellent. If only requirements docs and specifications were written this well - people would actually read them!

Seriously, good writing gets into you. Half of my strategy for improving your personal writing skill is to surround yourself with good writing. (The other half is to write. A Lot.) I pay about $10 per year for Inc., and have for the past three or four years. If you have ever considered going independent, or even starting your own micro-business, I would seriously recommend Inc. Plus, these guys walk the walk - Inc. is a magazine about small business that runs as an independent business unit of around 100 people. Inc. even has a trial subscription offer, if you are interested.

Nobody paid me anything for these suggestions. I just got a copy of Inc. yesterday and felt like sharing.

If you would like to know what trade rags I do *not* recommend, email me privately. :-)


Regards,

--heusser
(*) - Fair Warning: I work with this publisher, or have appeared previously in the magazine