Hands-on Software Design and Other Things…

by Jerome Carter on April 14, 2014 · 0 comments

I took last week off so that I could catch up on programming projects and try my hand at gardening/landscaping.   Mastering object-oriented programming has been a key goal since I began blogging.   Like any skill, practice makes perfect, so last week I began a new project to test my OOP design and programming skills.   In past blogs, I spoke of choosing a development framework, and settled on Yii (though Laravel is coming up fast on the inside).   Frameworks are great; however, they hide the complexity of development. Of course, if one is trying to turn out a product or complete a project, using a framework makes sense.  My problem is that I learned programming back in the 80s when you had to roll your own everything–using a framework feels like cheating on so many levels.

I have written a B+ tree-based data store using Prolog, an algebraic expression parser using Pascal, and fought with pointers until I could build data structures from scratch.  There is no way I could simply use a framework without trying it the hard way.    Thus, last week I took a product idea and went through the exercise of defining use cases, determining features, and outlining a minimal viable product.  Next, I started building class diagrams for the required objects, and then tried my hand at applying design patterns to the project.

Hands-on is fun, though always a little frustrating.  For example, there is always at least one instance where I pass something by value instead of by reference and then spend an hour trying to figure out what is wrong.  As I said, frustrating and fun…

Not infrequently, people ask me why I bother with programming when it is possible to hire programmers.  Here is the best way I know to explain it.   Writing software, testing algorithms, investigating data structures, and determining how best to represent a clinical concept are creative acts.    If all one wants is a system with fairly straightforward requirements, such as an employee-leave tracking application that stores data in an SQL Server database, then hiring programmers makes sense.  However, if one wants to build a classification application based on the immune system, which requires exploring algorithms, data structures, immunology, etc., then adding programmers doesn’t necessarily help.   Programmers need requirements to create systems, and the “bright idea” that just popped into mind does not come with a shiny new set of requirements.

EHR design, like artificial immune systems, requires the exploration of many concepts–workflow, usability, clinical concept representation, data structures, and algorithms (see Exploring EHR Design with Python).   Improving today’s EHR systems requires bright ideas that must be tested and rendered as requirements before being added to production EHR systems.  Playing with bright ideas is fun. However, when bright ideas give way to actionable requirements, I’ll happily call in professional coders.

Theories and such
Speaking of bright ideas… The work on a formal theory of clinical systems continues apace.    A major goal of this work is providing a framework for building production systems.   As such, a major challenge is determining how, in specific steps, one can move from theory to system design.   Thus, one challenge is deciding how to tie theories to models and models to designs that can be rendered in code.  Here, the research of van der Aalst and others on workflow theory, especially patterns, has been very encouraging.   The steps from graph theory, to Petri nets, to workflow nets, to workflow patterns and colored nets, provide a clear and practical example of moving from theory to practice.  My goal is to replicate this for clinical systems.    While the basic workflow/process ideas translate fairly easily to clinical systems, which is a good thing, clinical systems consist of more than workflows and processes.  Those other issues must be addressed as well, and they should be addressed holistically.

Workflow, usability, concept representation, user interfaces, algorithms—all the parts—should be understood as different aspects of the same underlying reality.  Until this thinking takes hold and is accompanied by a formal theory of clinical systems, the innovations being demanded of EHR systems will remain piecemeal and local to specific products.    Imagine what would happen if every school of architecture in the country had its own set of rules for edifice designs and kept its discoveries of architectural principles secret (sort of like the master builders of the middle ages).   How would architecture as a field progress?  This is the main issue EHR design is facing today.

As for my efforts, the major problem I am wrestling with now is what should be included in a model.  More to the point, what is essential to all systems, and, therefore, must be accounted for in every model?   For example, processes and data must be accounted for by every theory, model and system. But what aspects of a component, such as the user interface, are essential? That is, must any aspect of the UI be accounted for by a theory and/or model as opposed to being accounted for only in the actual system?

Internet startup…
It’s coming along.  For this, I will be hiring programmers once I see that the concept is viable as a product.   However, I have run into a new problem; the target audience is no longer obvious.   Last year the target audience seemed so obvious that it did not make sense to even consider the issue.  This issue does not affect the current design (at least not in any way that I can see—I know, I know…). However, it does affect marketing.   Hopefully, this will be worked out no later than July…

Well, that is what I have been up to.  Overall, things are going well.  Now it’s time to delve into the world of shade-loving plants and trim the gardenia bush that was damaged by the colder-than-usual weather we had this winter.

See you next week…


Leave a Comment

{ 0 comments… add one now }

Previous post:

Next post: