Thursday, February 23, 2006

Agile Modeling

I just received the best newsletter ever, about Agile Modeling. I've been receiving this newsletter for a long time now, but reading this issue reminded me that, though I use the technique myself, I haven't said an awful lot about it. If you don't know what agile modeling is, you should rush right over to and learn something useful. The website starts with the following definition:
Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. Simply put, Agile Modeling (AM) is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner.
Boiling it way down, it's developing in iterations; keeping your requirements for each iteration light; engaging your stakeholders throughout the development cycle; keeping each iteration short; and delivering often. If you've worked with me before you know that this is what I mean when I talk about taking care of your "major pain" first.

Another way of looking at this is that you should deliver the minimum amount of software that can reasonably be expected to work well... then flesh out the major shortcomings, then flesh out what's left, until there's nothing left worth fixing. A lot of IT managers would balk at a policy like this ("What do you mean, deliver the least we can get away with!?"), but think about it. Custom software is not commercial code. It's development should be driven by your needs, not by some imagined market pressures. Your major pain (or need, or "itch") really is dragging down your business... why would you suggest putting up with it for a day longer than necessary? Instead, you fix it quickly, efficiently, and cheaply. You engineer the cure to be flexible and extendible, but you focus your attention on the pain. Once you've fixed it, it's no longer painful, and you focus your attention on the next major pain. The end result is that at a point in development where "top down" designers would still be talking about the problems, agile stakeholders are using the solutions.

My sons' high school has a motto that describes this best:
Do your best; then do it better.
I couldn't agree more. That said, the reason that this particular newsletter was so interesting to me was that it thoroughly answers two questions I'm often asked: what is it I am... what's my title? Relax, I know the answer, it's just that I now have someplace to point people for a better explanation. Here it is. And while you're poking around, read this article for a nice continuation of getting your requirements right.

Stop the Presses

It was pointed out to me as I was drafting this that this "agile modeling" thing is flatly at odds with both the systems development methodology on my website and the concepts of Function Class Decomposition (FCD). The short answer is, NO IT ISN'T. Agile programming affects two things more than anything else: scope and documentation.

It affects scope because you're accepting that you'll solve a more limited problem two weeks from now rather than try to solve everything a year from now. Rather than a project in itself, an IT system becomes a product that is subject to versioning. But each version (iteration) is a small project, subject to the same principles of good project management as bigger ones. The big difference is that these successive smaller projects are more manageable and cheaper to produce, with more immediate impact. Whereas with larger projects "scope creep" or "feature creep" can become devastating, this iterative approach of focusing on your pain can greatly reduce creep. By the time the really significant issues have been dealt with, your stakeholders may decide that the remaining issues are just too inconsequential to deserve additional funding.

It affects documentation in that you really need to find new and more flexible ways of documentation. Heavily commented source code is good; and a good way to start with that is to pseudocode first (100% comment lines) and then flesh in the pseudocode with actual code; that way your intent and your execution are documented in the same source file. Keep meetings informal. Document issues in a shared database or discussion group. Document them in email, but cc: a Notes mail-in database. Document no more or less than is necessary. But there's one piece of documentation you cannot skimp on... your initial scope document, signed by the stakeholders. Your requirements may be refined in the face of reality, and you may have to adjust your design as you go, but you should always keep your eye on the prize: that core set of functionality you're contracted to deliver.

As for FCD, it's not affected at all. As you go through new iterations, you take the same old functional model you had at the outset, Add new functionality (it's nice to diagram these in new colors), and analyze how it fits into the existing design. You still look at your opportunities for re-use, except you now have the benefit of having actual classes to deal with. Describe any new classes that will deliver the functionality. Then you implement the functionality from the bottom up, only having to deliver those components that don't pre-exist and limited modifications to those that do.

Monday, February 20, 2006

New VIC CRM release: we have a wiki

A new release of VIC is out today... you can get it on This release fixes a number of the more annoying bugs that previously existed, and adds a very useful new feature: from an Organization or Person document -- or from any document that's linked to an Organization or Person -- you can click a hotspot to dial any of the telephone numbers associated with the record.

This uses TAPI, so for this to work, you need to have the Microsoft Phone Dialer installed, and you should have a voice/fax modem attached to your phone line.

Also, if you're reading this on (and I can't imagine where else you'd be reading it), then you may notice a new link on the navigator on the left side of this page. Click on "Wiki" and a new window (or tab) will open.

The wiki is intended as a collaborative place to document VIC CRM, TimeTool or other public projects on this site. Please take a look and contribute responsibly. (Opening up a website for public participation is a scary proposition for the webmaster, so be fair.)

BTW, this DominoWiki is the fruit of another fine project on, led by Ben Poole. My thanks to Ben and all contributors for releasing this to the Open Source community!

Tuesday, February 07, 2006

ReactOS? Hmmm... OK, I'll give it a look

As is obvious to anyone reading my posts, I'm a pragmatist when it comes to software choice; I'm certainly not against commercial software, though I certainly recommend, encourage the use of, and even provide Open Source software as an alternative.

The reasons for my pragmatism are simple: people should be allowed to make money from commercial software; as much money, in fact, as market forces will allow. I don't begrudge Bill Gates a single one of his many dimes. (nevertheless, I won't shrink from using Microsoft in this article as symbolic of all commercial developers)

On the other hand, market forces must include competition; customers should never be required to buy any particular software product. And, with the cost of software such as it is, that cost is often exhorbitant. The point here is that people pay too much for commodity software. Developers need to be fairly compensated for their direct labor, but sooner or later the economies of scale need to take over. I know, Windows still costs about the same as it ever did, but for what you can do with it, it would cost a pittance if it didn't negate Moore's Law. And since I've never seen this formally stated, I'll do it here (and if you know a "real" name for it and can prove precedence, tell me):
Leigh's Law: Software systems generally increase in complexity in inverse relationship to Moore's Law.
Thus, subjectively relative software performance remains static: the 486 running DR-DOS in my basement boots roughly as fast as the 1GHz WinXP box in my office. The computing power on my desk was out of the reach of most, if not all major governments when I started computing: thanks to Moore's Law, I cobbled it together myself from spare parts purchased for a few hundred dollars from some gypsy at a computer show. But the things an average schmuck like I can do with the software running on it, despite it's incredible complexity, are pretty similar to what I could do about 15 years ago (which is about when Leigh's Law really kicked in), and takes about as long. Granted, I can do more complex things than I could do then, but they're not necessarily better things. I can play games, but they're not necessarily better, just more detailed. I can write letters, but they're certainly not inherently better, since I'm still the one writing them. The same for accounting, or whatever. It takes me as long to compile bigger complex programs today as it did to compile smaller, functionally targeted programs on slower machines in the past. And the improvements in my online connections are more due to Moore than Microsoft.

The point here is that people pay too much for commodity software. Labor's another matter... people need to be fairly compensated for their labor. But sooner or later the economies of scale need to take over. Otherwise, people look for alternatives, and turn to Open Source, as I have. It's simply silly to believe that people should spend the megabucks necessary to fully equip a commodity computer with software; and it's simply silly to pay it if you don't have to.

So I was intrigued to learn about this: ReactOS has the goal of being a binary-compatible replacement for Microsoft Windows XP. Now, anybody who's worked on or used Linux (Unix workalike) or FreeDOS (MS-DOS workalike) knows what an amazing chore this team has taken on. It's in alpha stage now, but it seems to be working a bit, and they have screenshots on their website (which I won't re-publish because they all look just like Windows).

My knee-jerk reaction to the project is a mixture of approval and disapproval. On the one hand I have a personal liking for Linux, and I'm not thrilled about the prospect of a "new kid on the block" taking all the good press. More to the point, I'm concerned that this is a project that's chasing someone else's tail, and can never, ever catch it. To me, that's implied in the project's name. Its similarity to Windows may cause some confusion, and even some disappointment to inexperienced users who expect such features as Windows Update... though I expect this to disappear in the future as some entrepeneur picks up the product and adds this feature, as Linspire did with Linux.

On the other hand, if open-source Windows XP programs are good, then who am I to dismiss an open-source Windows XP? Just as FreeDOS exists for the people who still need DOS (and there are plenty of uses for DOS, friend!), there needs to be an OS alternative for people who want to build their own "whitebox" Windows-compatible computers on a budget. Besides, the cost of a legal copy of WinXP puts legal computing with commodity software out of many users hands. An open source operating system gives these users yet another alternative to software piracy, so Microsoft and the BSA can quit their bitchin'. The project is worthwhile, if only for that. I hope it does well.

Here's celebrating IDIC!

ReactOS Homepage

Friday, February 03, 2006

BitTorrent and Small Software

I just read this, from a columnist who shares my views about small software.
» Can great software live in 130 kilobytes? | George Ou |

He's talking about the µTorrent client here (a BitTorrent client). It's excellent software, and I gladly pass on the recommendation to you.

I always love it when I find lovely small code that does just what it's supposed to and no more. Whether it's µTorrent or my own TimeTool, I feel that software should be compact and as easy as possible to use... and unless a developer's actually coding for the operating system itself, he has precious little excuse for mucking about in the Registry and "integrating" his product. "Integrating," more often than not, means making a program inflexible, non-transportable, and bloated, whereas a nice text INI file keeps your options where they belong: with the program itself.

I'm so happy to learn that there are people who think as I do.