Artful Verification

Sometimes despite your desires to remain logical and analytical (you did after all choose to be a system design professional) you will find yourself in a position that requires you to pass judgment on others. This is never more true than when you are selecting a software package vendor. You have to be friendly but still cynical; vendors send you salespeople who know how to read your desires and make promises that cater to them. As a buyer you need to keep a critical eye toward what you know to be the facts.

Back in the early 1980s, when personal computers had 5 1/4 inch floppy disks and still went zyg zyg beep to start up, when ten megabyte hard disks were all the rage, I had the opportunity to review software vendors to provide hard disk security systems. The concern back then was that somebody could boot up from a floppy, switch to the C drive, and read all your data.

I was impressed by one vendor claiming that they not only could provide complete security, but actually prevent an unauthorized person from accessing the hard disk at all. As I had already reviewed the bios code and was familiar with how a computer loaded its bootstrap, I found their claim to be, eh, interesting. I asked to see a demo and they arranged for a salesman to drop by.

He gave a fairly nice demo, showing how their software could be configured so that only specific people could see certain files. at the end of the demo I commented "gee nice. Hey I was wondering about this item I read here about total protection." I told him that I seriously doubted their software could prevent somebody from destroying all the data on the C drive. He adamantly assured me that it would. Well then, was he confident enough that he would let me have a crack at his demo computer? Without a flinch he said sure!

I carried up a boot disk with the old DOS debug program on it, turned off his computer, put the disk in, and turned the computer on again. Zyg zyg beep! At the DOS prompt I typed debug and then used a command to write all zeroes to the boot sector on the hard disk. "Well uh, I think I just wiped your C drive," I shrugged. The salesperson didn't believe me. I removed my floppy disk and watched in a pitying amusement as he tried to restart his computer. Naturally the C drive was no longer readable at all (now he would have to reformat it). Needless to say we didn't purchase their software. Moral of the story: when you are buying software, trust... but verify.

Artistic Communication

Technical documentation is one of the least appreciated aspects of software development -- not the written words themselves, but the process of creating them is deeply undervalued. Effective technical documentation is like a Hail Mary pass from the developer in the present to the developer in the future with the intervening crosswinds of bug fixes and changes to the business rules complicating the reception.

The developer is usually the best person to author technical documentation: he understands the implicit trail of bread crumbs that he has already left in the code for somebody else to follow. If he was involved in the project from the start then he can also relate to the politics and priorities that the team faced from the design and implementation stages.

A technical document should begin with a Background section that describes the rationale behind the project and the challenges that sufaced during design and implementation. This should alert future developers to any political or technical potholes that they should avoid.

Next an Architecture section should briefly describe data flows, timing constraints, and security layout. Next some Entity Relationship diagrams: not the whole thing but just the key tables and their relationships. Then a high-level UML and quick use-case diagram, focusing on how employee responsibilities overlap with components of the system. Finally, reference the design specifications that can, at this point, direct the developer to the whole ball of wax.

Good technical documentation isn't extraordinarily deep or complicated provided that you focus on its main intent. Sure you understand the system (because you created it), but standing at the other end of the football field a future developer can easily get buried in minutiae. Wipe away those confounding crosswinds and throw that future developer a touchdown.

More Artful Testing

In the software development world we have a whole cabinet full of testing tasks that can contribute to quality work; here is a list of those most commonly used, in an approximate order of where they happen along the development cycle:

Impact Analysis
Usability testing
Code Review
Risk assessment
Stress testing
Test bed preparation
Test case creation
Test driver development
Functional testing
Regression testing
Boundary Value Analysis
Branch coverage
Error seeding
System Test
Parallel testing
Documentation Review
Integration testing
Acceptance testing
Post implementation validation

Therefore all of our software should be perfect and bug free. Right? In the real world our ability to spend time and money on software testing gets constrained however by the dynamics of staffing, skills, and delivery schedules. So much as I described in this earlier post about appropriate balance, we must carefully choose which test tools to remove from our cabinet to apply to each project. And that my friend, is why software still has bugs.