Services

• Software Architecture and Design
• Product Development
• Prototyping
• Human Interface Design and Specification

Software Architecture and Design

Object-Oriented Design Experience

I’ve designed the software architecture for three commercial desktop products and two Web 2.0 products. I've designed with COM objects, for simultaneous processes and multiple threads. Some projects were C#, some C++, one Java. All of them integrated third-party software and powerful SQL Server schemas.

Some of these designs began from a blank slate but more frequently a new release required underlying changes without destroying the integrity of the existing architecture. A designer must respect previous designs, whatever their flaws, they've solved the business problem and made money. They've earned their respect.

My Approach

The most important goal for an internal design is to reduce complexity [1]. The best way to reduce complexity is to maintain independence between objects[2].

I’ve seen too many design discussions bog down in a swamp of opinion. Clients often ask me to mediate discussions and resolve issues. I’ve found that when developers focus on objectives rather than techniques, they reach consensus faster. But the most important lesson I’ve learned is when to step back and let other engineers take pleasure in driving a design and making it their own. Only when engineers take ownership in a design will they agree to a tough schedule and strive to beat it.

Where my own experience shows that a design is seriously flawed, I look for solutions that eliminate the flaws without removing the personal touch of another engineer.

The result

At the end of the process, you’ll have a document containing the following pieces:

Overview

Discussion of the purpose of the software, dependencies on other modules, and references to other documentation.

Graphics

Visio drawings of the overall architecture of the module(s) and of any pieces that can benefit from a drawing. Nothing saves as much discussion and confusion as a good drawing.

Interface

The significant classes and methods.

Data Structures

Changes or additions to the database schema along with internal data representations.

Diagnostics

Description of how to test the modules

Algorithms

Discussion of any complex algorithms, with pseudo-code.

 

Product Development

Quality

Perhaps the best measure of productivity is quality. For one product that I designed and helped develop, a single company representative handled support calls for an active installed base of over 20,000 copies[4].

My Approach

Building software is a multi-step, complex process, where each step executes with speed and quality. Though a step may only require minutes, skipping it can cost days.

The result

• A steady succession of completed modules.
• A constantly up-to-date development schedule.
• A quality product delivered on time.

Prototyping

Often the fastest path in software development is to proceed from the top and the bottom simultaneously[3].  Top-down design alone can leave a project vulnerable to technical risk. Experimentation identifies problems and opportunities that might remain undiscovered until late in the project.

I highly recommend prototyping ideas and technologies as soon as the first revision of the user interface design is complete. The only time prototyping is inappropriate is when all aspects of the project are fully understood, but I’ve never known this to be the case.

For Kronos, I wrote a prototype that validated the UI design with selected customers and served as a testbed for third-party controls. This eliminated much of the risk before the full team began development, contributing to an accelerated schedule.

For PictureTel, I wrote a prototype of an event dispatcher to coordinate COM objects in different processes. Microsoft’s COM technology was identified as a serious technical risk. The prototype successfully eliminated the risk and helped train other programmers.

For Adaptiv Software, I wrote an early prototype of the graphical scheduling software which we vetted with customers before I led the development of a product that won venture capital, a patent, two awards, and shipped over 20,000 copies.

For ODAC, I wrote a prototype of an e-commerce interface that led to a specification that guided product development until the company was acquired by the leader in its industry.

I've personally seen how a good prototype can be worth millions in venture financing and customer commitment.

My Approach

The most important use of a prototype is to resolve a single issue quickly. To that extent, I always get the first working model delivered within a day or two, although a week may be required for complex prototypes. From that point, extensions and changes to the prototype can test secondary issues or refine the discussion of the primary issue.

Candidates for a prototype include:

Typically I write prototypes in C# or C++.

The result

You’ll have a workbed for testing solutions to a critical problems. The techniques used in the prototype are often applicable to a final product.

Human Interface Design

Solid Experience

I’ve designed user interfaces for two releases of the ComputerEyes video digitizer, three releases of the PeopleScheduler workforce scheduling product, and a release of the Kronos timesheet software. These products sold tens of thousands of copies for many millions of dollars. PeopleScheduler won two awards and has a patent on its user interface.

At ODAC, the user interface of its e-commerce product was a major factor contributing to the company's acquisition.  During due diligence, I was told the written specification was the best the Encoda technical team had ever seen.

Four Benefits of a Great Specification

I can't overemphasize the importance of a well-understood specification. If you wish, I have a separate discussion of the four major benefits of a good specification:

Reduce schedule slippage

Good specifications reduce added features that postpone delivery.

Improve Customer Satisfaction.

The beauty of your software and the crispness of your delivery won’t matter if the customer expected better. Setting customer expectations improves satisfaction.

Reduce Bugs.

A well-understood specification leads to a consistent internal design, which reduces bugs.

Deliver On Time.

Delivering on time doesn't mean delivering faster. It means delivering a useful subset as early as possible.

My Approach

You know best the features your customers require. You may already know how they should look and work. My role is to organize the features so all the displays and controls are tied together by a single conceptual model the user can readily understand. Then I can facilitate your decisions by preparing designs and prototypes that help you see how the product will look.

Most of the work is reconciling the decisions you make with the realities of the development schedule, your current products, and the available technology and standards. Within those limits, there is less flexibility than many UI designers realize.

The result

At the end of the process you’ll have a document, typically 50 to 100 pages long, that fully specifies the appearance and operation of the software. This includes:

Drawings

graphic images of all major display and control objects.

Descriptions

details of the display behavior and control operation.

Scenarios

examples and critiques of how the user accomplishes common tasks.

Features

the list of all features and how they affect the operation of each object. Features are often added or removed depending on the development schedule, so the impact of each feature must be understood.

Priorities

the relative importance of each feature

Technologies

the list of required technologies, like COM or ODBC. These may not seem to be part of a UI design, but they often constrain the design in important ways.

Issues

the list of decisions that must be made prior to development.

Risks

the requirements that represent schedule risks or customer-acceptance (quality) risks.

Footnotes

1. Booch, Grady; Object Oriented Design with Applications, Chapter 1.
2. Please see my article on C++ Notifiers published in Computer Language magazine. You can download the source code for the technique described in the article.
3. McConnell, Steve; Code Complete, pg 160, the section on Round-Trip Design.
4. A good measure of the credit for this quality, however, goes to Rick Barker, the VP of Operations. We had a great relationship, maintained by phone across 3000 miles, working together to ship a terrific product. He understood software quality assurance as well as anyone I’ve ever known.