Carlos Leyva

Silicon Stories

Chapter 1: Dirty Little Secret

Lessons Learned

« PreviousContentsNext »

I spent the first six months of the project creating tools that were missing from my toolbox. I needed a way to bind the database to the data entry forms that I was building. I needed to transparently handle parent-child relationships. I needed consistent database search behavior. In general, I needed tight integration between the user interface library and the database. What I needed was a product like DBase IV from Ashton-Tate (later Borland). I never even considered it. There were three major reasons:

The wrong technological decisions were made at the very beginning of the project. In addition to providing the required functionality out-of-the-box, DBase IV had a large user base to network with and learn from. But even if I had been aware of the power of DBase IV for database specific applications, which is what “The DeskTop” was, I wouldn’t have used it. Why? Because who the hell wants to develop in a pussy ass language like DBase? Everyone knew ‘C’ was what real developers used. Anything else was for techno-peasants.

Our competitive advantage was the ability to quickly develop an integrated offering that would solve a known business problem for the small law firm. That competitive advantage was dealt a significant setback when I spent an inordinate amount of time integrating technologies, at the expense of getting to market.

More Lessons Learned

No one could have convinced me back in 1989 that I was making a serious mistake, technically speaking. I would have told them to fuck off. Today, prospects often try to convince me that they have all the answers, and I reply in a similar manner (yeah right).

I might have been able to recover the productivity lost building tools if I had adopted a more sensible go-to-market strategy. The DeskTop had far too many features (i.e. modules) for a 1.0 product. In addition to the three modules listed earlier (time and billing, case management, and calendaring), I added docket management and accounts payable to the must-have features list. Features are expensive propositions. Envisioning them is the easy part. Taking them through the entire life cycle can be quite daunting, especially as a project’s charm is starting to wane.

Software engineering is anything but. There is an engineering component, to be sure, but this aspect often contributes less to a successful project than you might think. In general, whether developing a commercial product, or a mission-critical internal application, it is far better to release a stable and useful 1.0 product than allow project delays because of additional features. Do a good job of engineering upfront and let the marketplace guide you the rest of the way.

The Future Happens Sooner Than You Think

The DeskTop was a part-time development effort for me during the first two years. I was working a full-time job and putting in another 30-40 hours a week banging away at the keyboard. I was determined. I was motivated. But after two years of this, I was starting to tire. I decided that if the damn thing was ever going to be ready to ship, it would require a full-time effort, and then some. I quit my job, rented an office, hired a part-time developer that was finishing his degree at the University of Houston, and got serious.

Something happened on the way to the dance. Windows 3.1 changed the computing world! This was a catastrophic event for a fledgling DOS ISV. Not only was I late to market, my stuff wasn’t even cool anymore. Talk about missing the window of opportunity!

To make a long, long, long story somewhat shorter, I finally did manage to ship. I got some good reviews, sold some copies, and lost a piece of my soul in the process. Windows 3.1 was out about six months before I threw in the towel. I shipped the fucking product out of pride. I should have cut my losses far sooner than I did. I would have been far better off.

Still More Lessons Learned

« PreviousContentsNext »