The Kudzu Project – My First Year in the Dungeon

by Joel Kozikowski
January 2, 2006

It’s no secret that my conspicuous absence from Club Lighthouse for the last year is due to my re-assignment to full time Kudzu development. But what have I been doing all that time? When will the program be finished? Good questions!

The initial phase of development required a fresh look at the current state of information technology: where it is and where it’s going. When PracticeWorks development began in February 1993, most of the dentists who were already computerized lived in a character-based world (DOS, UNIX, etc.). This was in spite of the fact that Microsoft Windows 3.0 (the first release considered “usable” by most) was 2 1/2 years old. The only Windows dental software "widely available" (Dentrix) was not well-known at all. SOFTDENT (DOS) was the 800 pound gorilla. The move to Windows based dental software was one of those “paradigm shifts” the talking heads like to talk about. Programs that truly exploited the advantages of a Graphical User Interface ("GUI"), like PracticeWorks and its “based on the appointment book” design, seemed to rise out of nowhere to claim impressive sales numbers. Programs that didn’t make the GUI transition well or at all (dozens of them) fell behind. Many eventually disappeared.

One of the big advantages PracticeWorks had over its well-established competitors was that it was conceived AFTER the technology disruption event that was Microsoft Windows. Every bit of its functionality and usability had to consider only “what can Windows do.” I actually had zero dental industry experience (other than having my teeth cleaned), so I had no pre-conceived notions about how dental software worked. This was a distinct advantage over a company with an entrenched way of doing things that ultimately handicapped the developers and users of non-Windows programs.

This history is all relevant to Kudzu in that another major “paradigm shift” has occurred: the advent of the Internet. Every currently available major dental program was conceived BEFORE the idea of a ubiquitous network existed. While features can be retrofitted to deal with the Internet, they will always be similar to a pretty GUI face put over a DOS program. The Internet is much more than e-mail and web browsers; it’s a communications infrastructure that ties devices like desktop computers to wireless tablet PCs to cell phones to television set-top boxes to digital cameras to you name it. And more important, it can tie people together, like patients to doctors to specialists to suppliers to third party payors, etc. Complicating matters is the fact that new technology is appearing almost daily, with changes happening faster now than at any time in the history of technology. Finally, just as any large city has its dark allies and “bad parts of town”, the Internet is a public network where anyone, including those with less than honorable intentions, can be lurking in the shadows, so security is critical.

Rapid change in computer technology has not been limited to computers and networking devices. There have been huge changes in the way software is written, and how it operates. Some of those changes have been good, some bad. The “Internet Gold Rush” of the late 1990’s saw software developers abandoning the desktop GUI for web-based software. Indeed, one of the fuels that InfoCure, Inc. used to feed the fire that consumed so many practice management programs was the acquisition of a web browser-based practice management program. The subsequent Internet bust (and your “InfoCure had a web-based practice management program?” question) shows how successful that initial attempt was. While appropriate for certain types of applications (like catalog shopping), the level of interactivity one gets with a web browser just isn’t what’s needed in, say, a charting program. Recently, however, techniques that have improved web browser interactivity have started to appear. One of the more popular examples is Google Maps: check out maps.google.com and "take a tour" to see how interactive it is!

Where does all this leave the Kudzu Project? Certainly, if we’re going to take the time to re-write an application from the ground up, we might as well do it right and take into account all the significant changes that have occurred on both the technology and business sides of the equation. We need to go well beyond “PracticeWorks’ treatment planning system is like this, and a better way to do it is like that.” Our goal is NOT to simply re-write PracticeWorks, making incremental improvements over the way the features behave. This is not to say that most things in a program like PracticeWorks are obsolete. There are key concepts that we think are critical to a successful new product: things like user defined forms, automatic document generation, and user defined automation. There are also a lot of things in PracticeWorks that we think we got right (for the most part) from the very beginning, such as a highly interactive appointment book.

A new product, to really have an impact on a market, needs to be more than just a re-write of an old one. It needs to be appropriate for the technology environment in which it’s going to live. It needs to be highly adaptable to rapid changes in technology. Finally, what prompted Lighthouse to create Kudzu in the first place is the desire to continue to work as effectively as possible in partnership with our Club members. To that end, Kudzu needs to be more than just a product – it needs to be a platform which we can all build on in the future. It needs to be a platform that gives us the flexibility to quickly respond to changing business and technology needs, and to accommodate everyone's very different opinions on what those needs really are.

I used to joke with Brian that if version 1.0 of PracticeWorks had had all the automation features of 4.5 (the Automation Expert, User Defined Forms and Notes, and the Document system), most of the programming done in 1.0, 2.0 and 3.0 wouldn’t have been necessary. I was only partially joking: the success that Lighthouse has had in creating enhancements for PracticeWorks based entirely on the Automation Expert certainly supports that theory. If the automation system could be significantly improved, perhaps that theory could become a reality. Kudzu will test that approach.

The first several months of The Kudzu Project were spent simply looking at and experimenting with current ways of developing software. This included both the resulting programs, as well as the development technologies and methodologies used to WRITE the programs. Careful consideration was given to the robustness of to each “ology”: its capabilities, ease of use, and more important, its longevity. The longevity factor is particularly tricky, since things are changing so rapidly. If a technology needed to be replaced down the road, how easy would it be? As new technologies are developed, how easy would they be to integrate? The last thing we want to do is select a technology that’s integral to the system only to get stuck in the “dark ages” (witness the PracticeWorks Document system “word processor”). The first several months were both exciting and frustrating. There is a LOT of new stuff out there in the software development world. Some is good. Some is bad. Some is ho-hum. Some is “almost there, but not quite.” Some very promising technologies are “not quite there” due to their newness, but have the potential to become significant if they’re more widely adopted. While we can’t use them yet, it would be foolish to not be able to accommodate them in the future.

In parallel with our technology evaluation, we continued to discuss business strategy, developing a business model that would be “win-win-win” for Lighthouse, our Club members, and our future business partners. As the year progressed, the business model came into sharper focus, and the technologies that would enable it became clearer. In some instances, the business model selected the technology. In many cases, however, a promising technology influenced the business model.

The second phase of The Kudzu Project (which we are currently in the middle of) is what we are calling the Kudzu Operations Runtime Engine (KORE). The KORE is a combination of server and workstation software that is responsible for data collection and storage, document rendering, and workflow execution (for “workflow”, think Automation Expert on steroids). It also handles low level services like user authentication and authorization, secure communications over a public network, and transaction processing (for “transaction processing,” know that PracticeWorks’s lack of transaction processing is the reason the Data Integrity Checker is necessary).

The KORE is also capable of hosting software components that can be “plugged in” to work seamlessly with the rest of the system. This will enable integration the way it should always have been. No more “one way” and “two way” bridges. You, the end user, should not be able to tell the difference between modules that are “native” to the KORE, and those that were added later. This “pluggable component” architecture will also enable a particular module to be replaced with a different one without affecting the rest of the system. “Different” can mean “improved”, or simply “more appropriate for my type of usage.” For example, let’s assume that Kudzu’s periodontal charting module ends up similar to that of PracticeWorks’. For most, that will be fine. However, periodontists will probably want more. The “pluggable architecture” will allow for Lighthouse (or any third party) to create a replacement module. Using it would be entirely at your option. This architecture will give you, the end user, the ability to select a “best of breed” module, without having to throw out any of the rest of the system.

So, the question I’m sure you’re asking now is, after 1 year, when will Kudzu be done? As the project evolved, it has become more ambitious than first anticipated. However, we expect some of the innovations of the KORE to pay dividends in significantly shorter development cycles as the project progresses. Interestingly, the KORE looks nothing like a dental practice management program. It’s a general purpose business engine. It won’t be until the first module is added to the KORE that it will start moving away from general purpose and closer to “dental practice management.” Also, the creation of the first KORE add-on module will surely spawn improvements in the KORE itself. We anticipate the creation of the second or third KORE module to give us a clear idea of how long the rest of the development process will take. The big bet on our part is that the development time of individual KORE modules will be very short compared to traditional programming techniques. It’s also our hope that our adoption of some new programming methodologies will result in shorter beta test cycles. In particular, “Test driven design” (which results in every component created having an associated automated “unit test”) should provide for higher overall software quality from the very beginning.

It was our desire to complete the KORE itself by the end of 2005. That date has slipped somewhat as various issues (most recently with the security system) have been worked through. We do anticipate the KORE to be fully operational soon, however. Once it’s completed, work will begin on those first few modules. It will only be after the completion of those first few modules that we should be able to “show” something in the form of screen shots or other types of demonstrations.

The completion of the KORE and the start of module development is also when we will start getting back to writing “dental specific software”, which is where Club Lighthouse comes in...