Specs: the Short way

When I was writing my FORTH editor (a rite-de-passage for FORTH programmers) I decided against extending the editor so it could hold words longer than the 40-character by 25-line surface of the Commodore 64 screen. It would have been trivial enough to do, and I decided that what I liked most about FORTH, the immediate testability (because each FORTH word gets its data from the stack, which is immediately accessible from the command prompt) of each FORTH word, was enhanced by being able to see all of the FORTH "word" at once. Scrolling or paging was a good feature for those blessed with wonderful memories, and knowing my limitations ("a man has to know his limitations"), I decided against that feature.

I have the same perspective on specifications: each specification should be visible on one screen, without scrolling. From a content perspective, I like specifications to have 3 parts: the Problem/Challenge being address; a description of the Solution (this is the actually specification); and a set of Tests which will determine whether the Solution has been implemented. Notice there is nothing about implementation in the specification (although I will leave technical notes in there, as idea-starters, very subject to change at implementation). Below is a spec I wrote recently. What about large challenges? Think a Tree structure, with nested specs.

***************


Problem: we have to babysit the updates because if it craps out, it is not restoring and letting us know.

Solution: make the update restore everything to where it was, and let us know, if it craps out.
Elements of the solution:

• Collection and notification of warnings and errors, by email, or if that fails, notifying the user to notify support.
• Seamless rollback after errors: think "crash"
• Lots of messaging during the updates, informing and entertaining the user.
• Remove all worrisome messaging to the user

Testing:

• Warnings will be emailed.
• Errors will be emailed; if unable, will ask user to contact support.
• After errors, system will rollback to prior state.
• After a crash, next usage will rollback to prior state.
• The user will see message changes or other visual stuff happening at least every 5 seconds. (This will be the last feature to be implemented, although it is an absolutely essential part of making the automatic update work with users.)
  -- we should ship the fun stuff to be shown with the update, to keep it fresh.

Implementation Notes

Control attempts through main.ini, [UPDATER] section, with keys for LastVersionAttempted, LastTimeAttempted (timestamp), CurrentVersion, CurrentVersionInstalled (timestamp), LastInstallReport (timestamp)

Specs: Good, Good

I've been reading Joel on Software, a collection based on the blog of Joel Spolsky. Mark, my colleague and boss at Dataworks (Matty's graphics are pretty cool, eh?), following up a link to Joel's blog, thought the book was good enough to get copies for Jeff ("gamer") Ference and myself.

Of course I only give links to Mark that agree with what I think <g>, so to some extent it's like reading myself, except much more entertainingly written. And there is some stuff I didn't know, e.g., the role of program managers at Microsoft (Joel was the program manager for what become VBA for Excel, when he was at MS).

It turns out that Program Managers write the specifications; but have no control, other than persuasion, over implementation. It sounds haphazard, but it also puts the responsibility right on the programmer, rather than leaving it sitting somewhere between the worker bee and the manager bee, where it would surely languish from inattention. It also puts a big emphasis on the specification, since the programmers aren't creating the feature list on the fly. Joel describes a specification that ran 500 pages. Ouch.

It's not that I haven't been in favor of specifications. My ideal has been, and is, that software should be specified as to functionality in such a way that a tester can determine whether it works correctly. This was before TDD (Test Driven Development) was an acronym, fwiw (at my age, at lot of stuff was so before it was an acronym <s>). My next entry on this blog will show you how I like to write specs.

Range of Convenience

There's somewhat of a brouhaha running in the .Net world regarding the amount of complexity required in frameworks: http://weblogs.asp.net/bsimser/archive/2007/05/22/reusability-vs-ryo.aspx. One side says "keep it simple," the other side says, "make it complete."

The simple side will win; but the complex side will be able to prove it is theoretically correct, and so will delay the simple side winning. Theory wins in the short run, because lacking data we really like pretty ideas; reality wins in the end.

What this is really about, is Range of Convenience, but let me fill in the background for you.

A few years ago, I was emailing with a well-known developer, letting him know that his product really needed a GUI. He didn't see much need: he could do what he needed from the command line, more quickly than he could from a GUI. I pointed out to him that most developers do not have encyclopedic memories: they may have other qualities that make them terrific business software developers (such as the ability to imagine the cognitive experience of customers who don't have encyclopedic memories), but they do not resemble, in their pattern of cognitive strengths and weaknesses, him or his peers.

This developer, like the proponents of complexity pointed to in the blog link above, highlights the difference among people in what one cognitive theorist called "range of convenience," which has grown to mean the ways of thinking that are most comfortable, and most effective, for a given person. This mismatch in range of convenience has been a constant issue in .Net development: the growth of dynamic languages in .Net is proof, in a way that counts more than theory, that the original focus of .Net was off the mark for most business software developers. *

So neither way (the comprehensive, cover-all-your-bases way, vs. the focus-on-what's-needed) is wrong; each has a different range of convenience. And each is likely to appeal to a different segment of the software development population. Given the history (or at least the last 20 years of same) of business software development, from the rise of xBase in the mid-80's to the resurrection of dynamic languages within .Net against all odds, my guess is that tightly-focused approaches will find greater favor within low-budget business software development efforts, and theoretically-based approaches embracing comprehensive complexity will find favor with high-budget, management-by-committee software development efforts.

Oh, and that many of the high-budget projects will fail, and most of the low-budget projects will succeed.

_______

* Just one little example: in Visual FoxPro, if I want to response to a Lostfocus (onBlur) event, I write no lines of code: just stick in my code for what I want to happen. In .Net, I have to jump through hoops declaring a handler, hooking a method to a handler, removing the handler when I'm done, etc. I'm sure I am missing some wonderful functionality in doing it the VFP way; but I haven't missed it yet. :)

Why Silverlight Will Win

Jesse Ezell's blog on Silverlight vs. Flash is compelling for one reason: Jesse has the down-and-dirty experience working with Flash that tells the real story. Those of us who worked with Flash as a development environment from back in the FireFly days (now grown into Flex) have wondered why it never grew in the ways it needed to: where are the 3rd-party data widgets that would give us the data-ui capabilities we need? The answer turns out to be in the poorly-implemented underpinnings of Flash itself. It isn't going to get better, is what Jesse demonstrates. And Silverlight (WPF/e) gets it right.

VFP to .Net RoadMap Updated Yet Again!

We have decided to simplify our transition to .Net. No more baby-step by including a COM object for data access, just straight-ahead into the fray.

It remains to be seen how eliminating the baby-steps will affect the time schedule: our preliminary evaluation is that using the Strataframe tools will allow us to stick pretty much to a release date as projected (July), but most likely as a release that doesn't have all the libraries changes and helper routines that we would like to have available.

Other than getting there faster, we had the concern that ProMatrix might take objection to a COM object built on their framework being used to power an integration with another framework. Although one could argue (and there's a lot of evidence to support the contention) that a VFP framework and a .Net framework are not competing products, our history of good relations with ProMatrix make it worth going the extra step. VPM is still a great product, and we plan to be using it for 2 to 3 more years (Visual Studio 2007 will actually make it possible to switch to .Net and not lose more than about 15% efficiency from VFP, by my estimate).

Why Vista Counts

I did get something out of the powerpoint-dominated <gasp!> developers session at the Vista Launch in Louisville, today: Vista will make a difference in the quality of user experience, if we change our ways of thinking about user interface. The ability to design interfaces that are, uh, Mac-like <s>, will make a huge difference, in a way that the Mac cannot (because it cannot reach most of the users).

All the hype aside, the difference is in the vector-drawing engine that allows us as developers, and the visual designers we have yet to hire, to create intuitive, appliance interfaces. Imagine a stack of open forms, on the desktop, turned sideways about 45-degrees, so you could pick the one you want by observing what is actually on the form as it is in that rotated position. Imagine a 1-to-many form, with grids at the bottom, where the part with the child grids folds up 45-degrees to yield screen real estate, but could still be edited in the folded up state. Imagine...

All the rest is pretty much old news. Well, metadata attached to documents, and background versioning of documents is also very cool, although both have been available in Linux for a while now. And the messaging stuff is pretty old hat, the ease of the solutions is overhyped (devil in the details, etc.), and easier solutions exist for most situations.

But the UI stuff is incredibly significant, not for now (when most machines won't be able to run it), but for the future. It will take time for us, who are in the graphic design dark ages, to adjust. So, time to check whether your video card can support Vista. Finally we get to do what Cooper et al. have been telling us for over a decade and still reach the vast majority of users. Now if only I could color within the lines...

VFP to .Net Roadmap Update

Due to a variety of factors (illness, marriage, moving two households and one office, 6 cats, a dog, etc. 1200 miles to a new home, not all of the above to the same person) Frank and I have missed our projection for delivery of xCase2VPM V2.  However, Frank arrives on Dec. 15, and his throat will be within reach of my hands for 24 full days, so we plan to make up some ground. <s>

Other than dates, the only big change is that we will be initially producing our product with, and providing support for, Strataframe (www.strataframe.net).  It now supports the Infragistics controls we will be using and supporting.  We still plan to support MM.Net (www.oakleafsd.com), in the cause of enhancing motivation through competition.

To reiterate our Roadmap:

Phase 1: xCase2VPM for VPME9.1

• Full MetaData interface, written in .Net.  xCase will be used for defining data, not metadata.
• PSP Data Dictionary: the PSP DD will be used as the target of calls from VPME9.1.  This will allow portability to the other two phases.
• Libraries will be included in a subscription price that anyone can afford (more details to come).
• VPME9 applications will run out-of-the-box due to some shenanigans in the libraries; convert your existing apps as needed.
• Projected release: well, Frank goes back Jan. 9.

Phase 2: PSP4.NET V1

• Same MetaData interface as in Phase 1.
• Uses same PSP DD as in Phase 1.
• Uses Strataframe and Infragistics controls for UI building.
• Data hits a VPME9.1 COM object.
• V1.1: View design in the PSP MetaData designer.

Phase 3: PSP4.Net V2

• Full .Net application
• Carry over PSP DD, rewriting code snippets in IronPython.
• V2.1: MM.Net support

RTFHF: Read The Fabulous Help File

If you ran into a file that was of type hexbinary, how would you go about using it in your program?

Here's what I would do:

1) open the VFP helpfile
2) click on the Search tab and enter "hexbinary" without the quotes
3) click on each of the 4 resulting topics, click on the text window, press ctrl+F, and enter "hexbinary" without the quotes

The result would be that within 90 seconds I would see that strconv() would decode that file for me.

Now isn't that better than putting a question on the Universal Thread and having to wait for an answer? What was really amusing is that the help the user go who asked the question was a list of the first 3 items that came up in the helpfile.

Teach a person to fish...

Temporary Post Used For Style Detection (e25740fd-8137-4313-81b1-9aa6a80d3dcd)

This is a temporary post that was not deleted. Please delete this manually. (73c0749a-9783-475b-8f0e-978ec865344f)